This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Dear Community,

What does the error mean? 

The error was introduced after a:  brew cask upgrade

The tools got updated from 7 to 9 -> arm-none-eabi-objdump --version

GNU objdump (GNU Tools for Arm Embedded Processors 9-2019-q4-major)  

2.33.1.20191025

lib-h3 % arm-none-eabi-objdump -D lib_h3/libh3.a  | 

arm-none-eabi-c++filt > lib_h3/lib.list

arm-none-eabi-objdump: error: lib_h3/libh3.a(h3_codec.o)(.bss) section size (0x800c bytes) is larger than file size (0xde8 bytes)

arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

arm-none-eabi-objdump: error: lib_h3/libh3.a(udp.o)(.bss) section size (0x19934 bytes) is larger than file size (0xcfc bytes)

arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

lib-h3 % echo $?                                                                         

0

lib-h3 % ls -al build_h3/src/h3_codec.o                                             

-rwx------  1 arjanvanvught  staff  3560  7 apr 17:50 build_h3/src/h3_codec.o

The file size of the object file is 3560 bytes which is the (0xde8 bytes) as mentioned in the error. Why would there be an error or even better; why would there be any relationship between the allocated bytes in .bss and the object file size? 

Many thanks in advance, Arjan

Parents Reply Children
  • 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

    >>> 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.

    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.

    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.