Linetable

Linetable

[Sp3cial K]

Hi, can someone please explain how symtab->linetable is constructed?

The linetable sometimes contain consecutive entry of the same line number 
but a different pc (only a few bits different).  I originally went into a 
problem when setting a breakpoint to an overloaded function.  For each of 
the functions, the linetable contains two entries with same line number and 
slightly different pc, but these entries are not in NAS.map!

I just debugged one of my images and hereÂ’s what the linetable for the 
symtab containing the overloaded function “Interface::get” looks like:

index	line	pc in dex	pc in hex
28	251	8775424	85e700
29	251	8775427	85e703
30	0	8775434	85e70a
31	255	8775434	85e70a
32	255	8775437	85e70d
33	0	8775444	85e714
34	259	8775444	85e714
35	259	8775447	85e717
36	0	8775454	85e71e
37	261	8775454	85e71e
38	261	8775457	85e721
39	0	8775464	85e728
40	264	8775464	85e728
EtcÂ…

From symbol table:
0085e700 W Interface::get(unsigned&, unsigned&, unsigned&, unsigned&, 
unsigned&)
No entry for 0085e703
0085e70a W Interface::get(unsigned char*&)
No entry for 0085e70d
0085e714 W Interface::interfaceUp()
No entry for 0085e717
0085e71e W Interface::interfaceDown()
No entry for 0085e721
0085e728 W Interface::getType()
EtcÂ…

Thanks in advance!

~K

Re: Linetable

[Jason Molenda]

On Jul 27, 2005, at 2:54 PM, Sp3cial K wrote:

> Hi, can someone please explain how symtab->linetable is constructed?

You're probably best off starting by looking at the readelf -wl  
output of your executable.


> For each of the functions, the linetable contains two entries with  
> same line number and slightly different pc, but these entries are  
> not in NAS.map!

I have no idea what NAS.map is.

Before you assume that gdb has incorrectly read the line table, you  
should start by looking at the line table information in the executable.

Jason

Re: Linetable

[Sp3cial K]

Hi Jason,

Thanks for responding so quickly.  Oops, I was referring to the symbol table 
as NAS.map.  I'm working on solving the multiple constructor/destructor bug. 
  The multiple memory location of the same constructor/destructor is found 
in the symbol table, and I'm trying to do a lookup on all the entries with 
the same line number in the linetable.

Basically, when there is a weak symbol (overloaded functions), the linetable 
contains the same line number with different pc, and then there will be an 
entry with line number=0 and a valid pc.  Only one of those pc is found in 
the symbol table.  I wanted to know where exactly in the code does GDB put 
all the pc from different version of the object files into the linetable, 
and why are there pc addresses in the linetable that are not in the symbol 
table.

~K


>From: Jason Molenda <jmolenda@apple.com>
>To: Sp3cial K <ikiwibebe@hotmail.com>
>CC: gdb@sources.redhat.com
>Subject: Re: Linetable
>Date: Wed, 27 Jul 2005 15:01:51 -0700
>
>
>On Jul 27, 2005, at 2:54 PM, Sp3cial K wrote:
>
>>Hi, can someone please explain how symtab->linetable is constructed?
>
>You're probably best off starting by looking at the readelf -wl  output of 
>your executable.
>
>
>>For each of the functions, the linetable contains two entries with  same 
>>line number and slightly different pc, but these entries are  not in 
>>NAS.map!
>
>I have no idea what NAS.map is.
>
>Before you assume that gdb has incorrectly read the line table, you  should 
>start by looking at the line table information in the executable.
>
>Jason