A question about debug symbols in asm (x86)

A question about debug symbols in asm (x86)

[George Anzinger]

I hope this is the right list for this:

I am working with kgdb and trying to get the line number stuff from an assembly
file, in this case entry.S.  Here is the compile line:
   /opt/montavista/pro/devkit/x86/pentium3/bin/pentium3-gcc
-Wp,-MD,arch/i386/kernel/.entry.o.d -nostdinc -isystem
/opt/montavista/pro/devkit/x86/pentium3/bin/../lib/gcc/i686-montavista-linux/3.4.3/include 


-D__KERNEL__ -Iinclude -Iinclude2 -I/usr/src/linux-2.6.12-rc/include
-D__ASSEMBLY__ -I/usr/src/linux-2.6.12-rc/include/asm-i386/mach-default
-Iinclude/asm-i386/mach-default -gdwarf-2 -traditional  -c -o
arch/i386/kernel/entry.o /usr/src/linux-2.6.12-rc/arch/i386/kernel/entry.S

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
arch/i386/kernel/signal.o arch/i386/kernel/entry.o arch/i386/kernel/traps.o
arch/i386/kernel/irq.o arch/i386/kernel/vm86.o arch/i386/kernel/ptrace.o
arch/i386/kernel/time.o arch/i386/kernel/ioport.o arch/i386/kernel/ldt.o
arch/i386/kernel/setup.o arch/i386/kernel/i8259.o arch/i386/kernel/sys_i386.o
arch/i386/kernel/pci-dma.o arch/i386/kernel/i386_ksyms.o arch/i386/kernel/i387.o
arch/i386/kernel/dmi_scan.o arch/i386/kernel/bootflag.o
arch/i386/kernel/doublefault.o arch/i386/kernel/quirks.o
arch/i386/kernel/cpu/built-in.o arch/i386/kernel/timers/built-in.o
arch/i386/kernel/acpi/built-in.o arch/i386/kernel/reboot.o
arch/i386/kernel/kgdb_stub.o arch/i386/kernel/smp.o arch/i386/kernel/smpboot.o
arch/i386/kernel/trampoline.o arch/i386/kernel/mpparse.o arch/i386/kernel/apic.o
arch/i386/kernel/nmi.o arch/i386/kernel/io_apic.o arch/i386/kernel/module.o
arch/i386/kernel/sysenter.o arch/i386/kernel/vsyscall.o
arch/i386/kernel/early_printk.o

to build built-in.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?
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

Re: A question about debug symbols in asm (x86)

[Nick Clifton]

Hi George,

> I hope this is the right list for this:

It is.


> 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).

Cheers
   Nick

Re: A question about debug symbols in asm (x86)

[Nick Clifton]

Hi Qunying,

> $ 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

> Any advise? 

Yes - this was a bug that wqas recently fixed.  Please try
building a version of nm using the latest binutils sources
on the mainline of the binutils CVS repository.

Cheers
   Nick

Re: A question about debug symbols in asm (x86)

[nora pan]

>>    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/