help-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bob Proulx
Subject: Re: arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted
Date: Tue, 7 Apr 2020 15:34:47 -0600

Arjan van Vught wrote:
> > Bob Proulx het volgende geschreven:
> >> 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.
> > 
> > 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

objdump is part of the GNU binutils package.  Therefore I deduce from
this that you must be upgrading binutils from 7 to 9.  HOWEVER!  The
latest version of binutils appears to be 2.34 and therefore that does
not make sense.

  $ objdump --version
  GNU objdump (GNU Binutils for Debian) 2.34
  Copyright (C) 2020 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.

What is it exactly that you are trying to upgrade from 7 to 9?

Whatever that *thing* is that is where you should be directing your
questions.  But version 7 and version 9 do not match up with any
available version of binutils.

I have no idea what "brew cask" might possibly be.  Must be some Apple
thing?  Perhaps you should be discussing this problem with the people
behind that project?

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

I have no idea.

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

I have no idea.

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

Or at least the program did not report an error.

> 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 all depends upon what else is running consuming memory at the same
time.  The program is reporting it is out of memory.  That's all I can
tell from the error message.

> It seems to be that there is somehow a bug introduced within
> objdump.
> 
> Would it be good to open a bug report with objdump? 

Generally these things tend not to be bugs in the upstream project
like binutils.  Since binutils is used by almost everything.
Typically I would expect to find this as a bug in the Apple Mac side
of things.  But that is just my experience.  I would go to the Apple
Mac side of things and open a discussion there about the problem.

However if you want to open a discussion with the binutils project
people then I would go to their project page.  I would see that they
list several resources for these things.

  https://www.gnu.org/software/binutils/

  Bug reports
  There is a bug-tracking system at http://sourceware.org/bugzilla/.

  Mailing lists
  There are three binutils mailing lists:

  bug-binutils@gnu.org
    For reporting bugs.

  binutils@sourceware.org
    For discussing binutils issues.

I would start by discussion.  Therefore I would send a mail message to
their sourceware address.  That is where the documentation is
directing people to go for discussion.  That is the place to start.  I
think it is unlikely to be a bug in binutils.

When doing this I would find the version of the software on your
system by running the utility with the --version option as I did
above.  Report that version information.

  $ objdump --version

Good luck!
Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]