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

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.

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.