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

> Op 7 apr. 2020, om 02:41 heeft Bob Proulx <[email protected]> het =
volgende geschreven:
>=20
> This mailing list has very little activity.  I don't know and would
> normally comment but I hate to see people post questions and then not
> get any response at all.  Therefore I will comment here in the hope
> that I might be able to get you to a better place to ask your =
question.
Hi Bob, thank you working on this issue with me. Much appreciated.

>=20
> Arjan van Vught wrote:
>> What does the error mean? Is it just that the .list file is not
>> generated completely?  This error got introduced when upgrading from
>> version 7 to 9.
>=20
> Upgrading what from version 7 to what version 9?  What is being
> upgraded?
With the brew cask upgrade the GNU 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
>=20
>> 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)
>=20
> The BSS section is normally used to store static data.  In a C program
> if one is defining a variable with initialized data then this will go
> into the BSS section.
>=20
>  int iii =3D 42;
>=20
> It makes no sense if the BSS segment is larger than the file size.  It
> makes me thing there is a data corruption problem.  Or perhaps the
> file system is full and part of the file could not be written.  Or
> potentially other problem of which this is only a down stream cascade
> failure with a different root cause.

arjanvanvught@MacBook-Air 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

arjanvanvught@MacBook-Air lib-h3 % echo $?                               =
                                           =20
0

arjanvanvught@MacBook-Air lib-h3 % ls -al build_h3/src/h3_codec.o        =
                                           =20
-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?=20

objdump is just displaying information from object files. This looks to =
me as an internal error for objdump.

The objdump exit code is 0. Therefore the command is completing =
correctly.=20

>=20
> Reference:
>=20
>  https://en.wikipedia.org/wiki/.bss
>=20
>> arm-none-eabi-objdump: Reading section .bss failed because: memory =
exhausted
>=20
> Memory exhausted indicates that the program tried to allocate memory
> or tried to fork and whichever action it was failed due to being out
> of virtual memory.
>=20
> I would look to see if the storage filled up.  I would look to see if
> whatever you are doing ran out of memory.
>=20
> Since this is ARM I assume some type of NAND flash file system.  In
> which case I would look for a failure of the storage such as due to
> worn out storage cells.  If it is an SD card I would try reading from
> every byte and verifying that the storage device is working okay.  I
> have had SD cards using NAND storage and other similar devices fail
> creating file corruption.
The cross-compilation is running on MacOS with 8GB RAM. It would be =
surprising to me when objdump, working with a relative small archive =
file, is running out memory.
It seems to be that there is somehow a bug introduced within objdump.

Would it be good to open a bug report with objdump?=20

Thanks, Arjan

>=20
> Bob