Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Bob Proulx Newsgroups: gnu.utils.help Subject: Re: arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted Date: Tue, 7 Apr 2020 15:34:47 -0600 Lines: 106 Approved: help-gnu-utils@gnu.org Message-ID: References: <58616427-9DBC-4DF7-AF74-6EAA6844492B@gmail.com> <20200406183213536211500@bob.proulx.com> <3179994E-5E74-48D5-9120-0A1AC5D4FBA1@gmail.com> <20200407151837052602133@bob.proulx.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1586295293 25884 209.51.188.17 (7 Apr 2020 21:34:53 GMT) X-Complaints-To: action@cs.stanford.edu Cc: help-gnu-utils@gnu.org To: Arjan van Vught Envelope-to: help-gnu-utils@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com; s=dkim2048; t=1586295287; bh=crmMgHDHCNU8CRrFjktVCr7aYsR88wdLqweNDLNBxwU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QIKk0QOP9eqjbhfVdwC9DuUEnhPEBHgyiXuLFVtzgrSTOgAPvnk2OejVZ+xRL27xQ 9/PdMQqU4dLAwZX3vdJIjBEZyZEMQDBgUROb6o31SVEXNNUeavWnJKryVMq1wN+7Zk 0vjGlnNEv63gyYODp4KfExnFVD1MaLn56gY0WLe08AX4rgbLg35nKhNsCxaWunGO90 Kd4aWTuonD82+Le1ZRWQtKzit4NhragvYduHFGJGvA7KI+BMLP+qWuXdJdZpFoaw42 DD48OROfnp7GhGCijn9hwmMQg5SJPszLH3Y4PPBklsqpNbWg+0UHroGXjIciE9lClG c8OWildTr8w1A== Mail-Followup-To: Arjan van Vught , help-gnu-utils@gnu.org Content-Disposition: inline In-Reply-To: <3179994E-5E74-48D5-9120-0A1AC5D4FBA1@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.88.95.61 X-BeenThere: help-gnu-utils@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU utilities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <20200407151837052602133@bob.proulx.com> X-Mailman-Original-References: <58616427-9DBC-4DF7-AF74-6EAA6844492B@gmail.com> <20200406183213536211500@bob.proulx.com> <3179994E-5E74-48D5-9120-0A1AC5D4FBA1@gmail.com> Xref: csiph.com gnu.utils.help:323 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