From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18562 invoked by alias); 6 Apr 2004 23:37:50 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 18506 invoked from network); 6 Apr 2004 23:37:45 -0000 Received: from unknown (HELO hydra.ubicom.com) (4.20.168.98) by sources.redhat.com with SMTP; 6 Apr 2004 23:37:45 -0000 Received: FROM STORK.scenix.com BY hydra.ubicom.com ; Tue Apr 06 16:37:43 2004 -0700 Received: from nkelseyxp2 ([192.168.1.204]) by STORK.scenix.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 16:37:43 -0700 Message-ID: <029a01c41c30$274a5f90$8902a8c0@scenix.com> From: "Nick Kelsey" To: Subject: Re: .bss section marked as contents, load, alloc, data Date: Tue, 06 Apr 2004 23:37:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2004 23:37:43.0902 (UTC) FILETIME=[28A35FE0:01C41C30] X-SW-Source: 2004-04/txt/msg00081.txt.bz2 Ok... found the problem... Added a printf to _bfd_elf_make_section_from_shdr and it was setting the SEC_LOAD flag because some assembler code was not using @nobits. Because it was the linker appling the flag it does not show up as a flag in the .o file. My main concern now is someone forgetting @nobits and causing the same problem again. It is working now... thanks for the advice. Nick ----- Original Message ----- From: "Jafa" To: Sent: Tuesday, April 06, 2004 2:57 PM Subject: Re: .bss section marked as contents, load, alloc, data > Yep... checked libgcc.a, libgdb.a, and every .o file in the application... > all report ALLOC. > > I guess I will have to run gdb on the linker :-( > > Nick > > On Tue, Apr 06, 2004 at 02:21:42PM -0700, Nick Kelsey wrote: > > Hi guys, > > > > I am having a problem whereby all our elf files have the .bss section > marked > > as loadable: > > > > 10 .bss 000016a4 0010158c 0010158c 0000258c 2**4 > > CONTENTS, ALLOC, LOAD, DATA > > > > I ran objdump -h on all .o files being linked and all show: > > > > 2 .bss 00000000 00000000 00000000 00000034 2**0 > > ALLOC > > > > Which looks correct. > > > > Something must be making the linker think that it is loadable... but I > have > > no idea what. > > > > Any advice as to how to trace the problem would be appreciated. > > Are you sure you checked every library, archive, or system startup file > being linked? I had a bad .sbss in crt0.o recently... > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer >