From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11779 invoked by alias); 2 Jun 2005 05:26:45 -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 11738 invoked by uid 22791); 2 Jun 2005 05:26:41 -0000 Received: from web32610.mail.mud.yahoo.com (HELO web32610.mail.mud.yahoo.com) (68.142.207.237) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Thu, 02 Jun 2005 05:26:41 +0000 Received: (qmail 74457 invoked by uid 60001); 2 Jun 2005 05:26:39 -0000 Message-ID: <20050602052639.74455.qmail@web32610.mail.mud.yahoo.com> Received: from [24.6.248.244] by web32610.mail.mud.yahoo.com via HTTP; Wed, 01 Jun 2005 22:26:39 PDT Date: Thu, 02 Jun 2005 05:26:00 -0000 From: nora pan Subject: Re: A question about debug symbols in asm (x86) To: binutils@sources.redhat.com, nickc@redhat.com, george@mvista.com, qunyingpan@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2005-06/txt/msg00024.txt.bz2 >> Note the -gdwarf-2. Running nm -l on the resultant >entry.o shows lines like: >> >> 00000acc t common_interrupt >>/usr/src/linux-2.6.12-rc/arch/i386/kernel/entry.S:441 >> >> This file is combined with a bunch of others >>thusly: >> >> >>/opt/montavista/pro/devkit/x86/pentium3/bin/pentium3-ld >>-m elf_i386 -R >>arch/i386/kernel/vsyscall-syms.o -r -o >>arch/i386/kernel/built-in.o >>arch/i386/kernel/process.o >>arch/i386/kernel/semaphore.o >> >> >> Running nm -l built-in.o|grep entry.S gives: >> >>000024cd t ldt_ss >>/usr/src/linux-2.6.12-rc/arch/i386/kernel/entry.S:300 >>00000000 a >>/usr/src/linux-2.6.12-rc/arch/i386/kernel/entry.S >> >> >> I.e all most all the symbols have gone. What is >>going on here? > > >This looks like a linker bug. >Can you create a small testcase which reproduces this >problem and which you can post to this list ? > >(I assume that you are running that latest version of >the linker, ie version 2.16 or newer. If not they >please try upgrading first, to see if that resolves >the problem). Yes, it is a ld problem. I was able to see the same problem when ld links object files that generated from c code with the latest binutils (2.16.90.0.3 20050510) The test case is as the following: (1) test files //test1.c static int test1_v1; static int test1_v2; static int test1_v3; int main(void) { return 0; } //test2.c static int test2_f1(int val) { return val; } static int test2_f2(int val) { return val; } (2) test procedure $ gcc -g -c test1.c -o test1.o $ gcc -g -c test2.c -o test2.o $ ld -r -o tt.o test2.o test1.o $ nm -l test1.o 00000000 T main /home/test/test1.c:5 00000000 b test1_v1 /home/test/test1.c:5 00000004 b test1_v2 /home/test/test1.c:5 00000008 b test1_v3 /home/test/test1.c:5 $ nm -l test2.o 00000000 t test2_f1 /home/test/test2.c:2 00000008 t test2_f2 /home/test/test2.c:7 $ nm -l tt.o 00000010 T main /home/test/test1.c:5 00000000 b test1_v1 /home/test/test2.c:2 <--wrong! 00000004 b test1_v2 /home/test/test2.c:3 <--wrong! 00000008 b test1_v3 /home/test/test2.c:7 <--wrong! 00000000 t test2_f1 /home/test/test2.c:2 00000008 t test2_f2 /home/test/test2.c:7 But if we change the object file order then we won't see the problem. $ ld -r -o tt.ok.o test1.o test2.o $nm -l tt.ok.o 00000000 T main /home/test/test1.c:5 00000000 b test1_v1 /home/test/test1.c:5 <--ok 00000004 b test1_v2 /home/test/test1.c:5 <--ok 00000008 b test1_v3 /home/test/test1.c:5 <--ok 00000018 t test2_f1 /home/test/test2.c:2 00000020 t test2_f2 /home/test/test2.c:7 The problem will also be gone if we don't have "-r" in ld command. Any advise? Thanks in advance, Qunying __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/