MacOS: objdump: Reading section .bss failed because: memory exhausted

I can reproduce it with a setup shown below. Note that the error isn't fatal to the command's execution. Is there any chance your scripts could be persuaded to use objdump -d instead of objdump -D?

/* 1.s */
.text
.global _start
_start:
	nop

.section .text2, "ax", @progbits
_func:
	nop

/* 1.ld */
ENTRY(_start)

SECTIONS
{
  .text : {*(.text);}
  .bss : {. += 0x8000;}
  .text2 : AT (LOADADDR(.text) + SIZEOF(.text)) {*(.text2);}
}

[user@mach tmp]$ as 1.s -o 1.o
[user@mach tmp]$ ld -T 1.ld 1.o
[user@mach tmp]$ objdump -D a.out

a.out:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <_start>:
   0:	90                   	nop
objdump: error: a.out(.bss) section size (0x8000 bytes) is larger than file size (0x12b0 bytes)
objdump: Reading section .bss failed because: memory exhausted

Disassembly of section .text2:

0000000000008001 <_func>:
    8001:	90                   	nop

Please note that I am doing an objdump on the archive file directly; there is no linker, hence there is no linker script.

>>> a.out:     file format elf64-x86-64 -> That is not an ARM platform.

Running the same on a Linux system with my own compiled tools set is working fine.

arm-none-eabi-ar: creating lib_h3/libh3.a
arm-none-eabi-objdump -D lib_h3/libh3.a  | arm-none-eabi-c++filt > lib_h3/lib.list
pi@nuc-i5:/development/workspace/lib-h3$ arm-none-eabi-objdump --version
GNU objdump (GNU Binutils) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

Using -d instead of -D resolves the error.

arm-none-eabi-ar: creating lib_h3/libh3.a
arm-none-eabi-objdump -d lib_h3/libh3.a  | arm-none-eabi-c++filt > lib_h3/lib.list
arjanvanvught@MacBook-Air lib-h3 % 

arm-none-eabi-ar: creating lib_h3/libh3.a
arm-none-eabi-objdump -d lib_h3/libh3.a  | arm-none-eabi-c++filt > lib_h3/lib.list

arjanvanvught@MacBook-Air lib-h3 % arm-none-eabi-objdump --version
GNU objdump (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 2.33.1.20191025
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

It looks to me that the issue with objdump got introduced with GNU Tools V2.33

Please advice. Thanks, Arjan

Arjan said:

Please note that I am doing an objdump on the archive file directly; there is no linker, hence there is no linker script.

Okay. Removed it from the repro:

/* 1.s */
.text
.global _start
_start:
	nop

.section .text2, "ax", @progbits
_func:
	nop

.bss
.fill 0x8000

[user@mach tmp]$ as 1.s -o 1.o
[user@mach tmp]$ objdump -D 1.o

1.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <_start>:
   0:	90                   	nop
objdump: error: 1.o(.bss) section size (0x8000 bytes) is larger than file size (0x338 bytes)
objdump: Reading section .bss failed because: memory exhausted

Disassembly of section .text2:

0000000000000000 <_func>:
   0:	90                   	nop

Arjan said:

>>> a.out:     file format elf64-x86-64 -> That is not an ARM platform.

The "issue" is architecture- and object-type- agnostic. I am not an Arm-employee, if that's the underlying concern.

Arjan said:

It looks to me that the issue with objdump got introduced with GNU Tools V2.33

The bug; and the fix that introduced the "issue". Note that these changes were made by the binutils' upstream project. Comparing the points-in-time of various releases, of the fix, and of backports if any, should give an idea of exactly which releases are affected.

Arjan said:

Using -d instead of -D resolves the error.

I guess that the switch -D is useful in situations where non-executable sections can contain code (for e.g. as payload, to be extracted later, or similar) which one wants to disassemble. In such a case, -d won't help, as it skips over such non-executable sections.

If one doesn't want to rely on the -D switch in such situations, perhaps because of its all-encompassing behaviour, there are a few workarounds.

For instance, create another, temporary copy of the object/binary file, where that section has its flags adjusted to be more amenable to the nature of the -d switch. Below, take the 1.o generated above, update the flags of the .bss section, and disassemble the output:

[user@mach tmp]$ objcopy \
--set-section-flags .bss=contents,alloc,load,readonly,code \
1.o 2.o

[user@mach tmp]$ objdump -j .bss --adjust-vma=0x80000 -d 2.o

2.o:     file format elf64-x86-64


Disassembly of section .bss:

0000000000080000 <.bss>:
	...

# Below, if there's already a loadable, non-executable
# section '.payload'.
[user@mach tmp]$ #objdump -j .payload -d <binary>


# Or extract that section into a file, and run
# objdump -D on it, specifying the target arch and start
# address, etc.
[user@mach tmp]$ #objcopy -O binary -j .payload <binary> output
[user@mach tmp]$ #objdump -D -b binary -m <arch> --adjust-vma=0x80000 output

The above command materializes the .bss section in its entirety, filling it with zeroes. If its allocation size is 1GB, the output file will be appropriately large.

The instructions aren't displayed; needs -z switch.

Hi,

As Arjan and a.surati mentioned this was a bug introduced upstream when adding some hardening features to BFD.

Essentially it's checking that the size in memory of a section isn't larger than it was on disk.

But this needs to exclude purely synthetic sections such as `.bss` etc.

I have fixed this in sourceware.org/.../show_bug.cgi and it was backported to 2.33 however the release was made after the fix.

The next release of the GNU toolchain will contain the fix.

Thanks,

Tamar