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