[RFC] minimal symbols on mips-irix and overlapping CUs...

[RFC] minimal symbols on mips-irix and overlapping CUs...

[Joel Brobecker]

Hello,

we have discovered a problem on mips-irix that had me wondering about
GDB's assumptions regarding the symbol table. First, the symptoms:

We have a small Ada program that uses nested procedures. The same can
be reproduced with a C program if GCC is used (GCC provides nested
procedures as an extension). Trying to get a backtrace off the nested
procedure does not work. With our example, we get something like this:

 #0  main ()
 #1  0x10013858 in main ()
 #2  0x100139d0 in gdb_no_local_symbols () at gdb_no_local_symbols.adb:37
 #3  0x10013574 in main (argc=1, argv=2147430180, envp=2147430188)
     at b~gdb_no_local_symbols.adb:204

While the expected backtrace was:

 #0  gdb_no_local_symbols.proch () at gdb_no_local_symbols.adb:28
 #1  0x10013858 in gdb_no_local_symbols.procc () at gdb_no_local_symbols.adb:32
 #2  0x100139d0 in gdb_no_local_symbols () at gdb_no_local_symbols.adb:37
 #3  0x10013574 in main (argc=1, argv=2147430180, envp=2147430188)
     at b~gdb_no_local_symbols.adb:204

The problem, in my opinion, is two-fold:

  a. The IRIX linker does not include the LOCAL symbols into the symbol
     table. They are present in the object files, but are stripped from
     the executable symbol table. This concerns at least nested
     functions, and static functions as well.

  b. A recent version of the IRIX linker has introduced an extra asm CU
     (Compilation Unit) named "__sgi_ld_generated_code" which contains
     one function before CU gdb_local_symbol.adb, and 2 after. So the
     code range of gdb_local_symbol.adb is included in the code range
     of the linker CU.

What happens after GDB stops on the breakpoint and tries to find the
associated function name is the following:

  1. In find_pc_sect_symtab(), we search all symtabs for one which
     code range includes the PC. We find the linker CU, which is the
     wrong one. But we acknowledge the fact that CUs can overlap,
     and therefore resort to find_pc_sect_psymtab() to find the correct
     CU.

  2. In find_pc_sect_psymtab():
  
     a. We first scan the minimal symbols, find "main". We did not find
        the right function because the linker did not include it into
        the symbol table.

     b. Then, we scan all the partial symtabs for the ones which code
        range include the given address. For all the qualifying ones,
        we check whether it contains a function which start address
        matches the minimal symbol address. If yes, then we have found
        the right symtab. Otherwise, we just return the first partial
        symtab we found.

So in our case, we simply end up selecting the linker CU. The GDB later
realizes that there is no function matching the given PC in the CU we
selected, it falls back to using the minimal symbol table, and therefore
ends up declaring that GDB stopped in function main().

In my opinion, (b) is not a problem, and GDB should be able to handle it
as long as the symbol table is "complete" (ie as long as (a) does not
apply). I am inclined to declare this a linker problem, but can this
really be categorized as a linker problem?

My general question is the following: Has GDB been designed to assume
that the symbol table will always be complete? This has always been my
feeling, but I'm wondering if it wasn't an unwarranted assumption.

Maybe it's just a hole in find_pc_sect_psymtab() that needs correcting.
For instance, I am contemplating the idea of tweaking GDB to
automatically add new "virtual" minimal symbols after having built
the psymbols using the following approach: Foreach non-type psymbol
we found, check whether we have a minimal symbol at the same address.
If not, then we have a missing msymbol, and I therefore add it.

Opinions?

Thanks,
-- 
Joel

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Daniel Jacobowitz]

On Mon, Nov 17, 2003 at 02:39:26PM -0800, Joel Brobecker wrote:
> Hello,
> 
> we have discovered a problem on mips-irix that had me wondering about
> GDB's assumptions regarding the symbol table. First, the symptoms:
> 
> We have a small Ada program that uses nested procedures. The same can
> be reproduced with a C program if GCC is used (GCC provides nested
> procedures as an extension). Trying to get a backtrace off the nested
> procedure does not work. With our example, we get something like this:
> 
>  #0  main ()
>  #1  0x10013858 in main ()
>  #2  0x100139d0 in gdb_no_local_symbols () at gdb_no_local_symbols.adb:37
>  #3  0x10013574 in main (argc=1, argv=2147430180, envp=2147430188)
>      at b~gdb_no_local_symbols.adb:204
> 
> While the expected backtrace was:
> 
>  #0  gdb_no_local_symbols.proch () at gdb_no_local_symbols.adb:28
>  #1  0x10013858 in gdb_no_local_symbols.procc () at gdb_no_local_symbols.adb:32
>  #2  0x100139d0 in gdb_no_local_symbols () at gdb_no_local_symbols.adb:37
>  #3  0x10013574 in main (argc=1, argv=2147430180, envp=2147430188)
>      at b~gdb_no_local_symbols.adb:204
> 
> The problem, in my opinion, is two-fold:
> 
>   a. The IRIX linker does not include the LOCAL symbols into the symbol
>      table. They are present in the object files, but are stripped from
>      the executable symbol table. This concerns at least nested
>      functions, and static functions as well.

That is a strange behavior, although I suppose it is legal from an ELF
standpoint.  The IRIX linker has... a number of oddities.

>   b. A recent version of the IRIX linker has introduced an extra asm CU
>      (Compilation Unit) named "__sgi_ld_generated_code" which contains
>      one function before CU gdb_local_symbol.adb, and 2 after. So the
>      code range of gdb_local_symbol.adb is included in the code range
>      of the linker CU.

What information does this have - does it have dwarf information or how
else are we finding its code range?

> What happens after GDB stops on the breakpoint and tries to find the
> associated function name is the following:
> 
>   1. In find_pc_sect_symtab(), we search all symtabs for one which
>      code range includes the PC. We find the linker CU, which is the
>      wrong one. But we acknowledge the fact that CUs can overlap,
>      and therefore resort to find_pc_sect_psymtab() to find the correct
>      CU.
> 
>   2. In find_pc_sect_psymtab():
>   
>      a. We first scan the minimal symbols, find "main". We did not find
>         the right function because the linker did not include it into
>         the symbol table.
> 
>      b. Then, we scan all the partial symtabs for the ones which code
>         range include the given address. For all the qualifying ones,
>         we check whether it contains a function which start address
>         matches the minimal symbol address. If yes, then we have found
>         the right symtab. Otherwise, we just return the first partial
>         symtab we found.
> 
> So in our case, we simply end up selecting the linker CU. The GDB later
> realizes that there is no function matching the given PC in the CU we
> selected, it falls back to using the minimal symbol table, and therefore
> ends up declaring that GDB stopped in function main().
> 
> In my opinion, (b) is not a problem, and GDB should be able to handle it
> as long as the symbol table is "complete" (ie as long as (a) does not
> apply). I am inclined to declare this a linker problem, but can this
> really be categorized as a linker problem?
> 
> My general question is the following: Has GDB been designed to assume
> that the symbol table will always be complete? This has always been my
> feeling, but I'm wondering if it wasn't an unwarranted assumption.
> 
> Maybe it's just a hole in find_pc_sect_psymtab() that needs correcting.
> For instance, I am contemplating the idea of tweaking GDB to
> automatically add new "virtual" minimal symbols after having built
> the psymbols using the following approach: Foreach non-type psymbol
> we found, check whether we have a minimal symbol at the same address.
> If not, then we have a missing msymbol, and I therefore add it.

Rather than mesing with the minimal symbol table, we should probably be
correcting the assumption.

Partial symbol tables include function addresses.  find_pc_sect_psymtab
assumes that everything would have a minimal symbol, but we can
probably correct that.  The loop in that function looks quite strange
to me: note that the inner loop uses the same variable, deliberately,
as the outer loop.  Here's a better version of (b):

>      b. Then, we scan all the partial symtabs for the ones which code
>         range include the given address. For all the qualifying ones,
>         we check whether it contains a function which start address
>         matches the minimal symbol address. If yes, then we have found
>         the right symtab. Otherwise, we just return the first partial
>         symtab we found.
							^^^^^^^^^^^^^^
							best match

There's already code in find_pc_sect_psymbol to do this sort of
best-match.  Something similar is needed here, but we need to be
careful of the recursion.  Probably, find_pc_sect_psymtab should build
on find_pc_sect_psymtab rather than the other way around to solve your
problem.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Andrew Cagney]

FYI, from nodebug.exp:

     # Irix5, even though it is ELF, counts as "ecoff" because it
     # encapsulates ecoff debugging info in a .mdebug section.
     # Irix6 gcc omits no debug info at all for static functions and
     # variables, so all tests involving statics fail.

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Daniel Jacobowitz]

On Mon, Nov 17, 2003 at 07:25:14PM -0500, Andrew Cagney wrote:
> FYI, from nodebug.exp:
> 
>     # Irix5, even though it is ELF, counts as "ecoff" because it
>     # encapsulates ecoff debugging info in a .mdebug section.
>     # Irix6 gcc omits no debug info at all for static functions and
>     # variables, so all tests involving statics fail.

Ok, so that's the same issue.

But Joel's case did have debugging information, I think - so just the
minsyms are missing?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Joel Brobecker]

> But Joel's case did have debugging information, I think - so just the
> minsyms are missing?

Yes, that's right. And one interesting thing I did find: "nm" on
mips-irix dumps the symbol from the symbol table AND the dwarf-2
info...

-- 
Joel

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Andrew Cagney]

> But Joel's case did have debugging information, I think - so just the
>> minsyms are missing?
> 
> 
> Yes, that's right. And one interesting thing I did find: "nm" on
> mips-irix dumps the symbol from the symbol table AND the dwarf-2
> info...

What about the ".pdr" section?

I get the feeling that core GDB has another really useful table just 
beyond its fingertips - the unwind table - and that can be used to find 
things like map from a pc to the function start/end/name/...:

- PPC64 has a traceback table just past the end of the function and that 
can provide a pointer (tb_offset) back to the function's start

- For ia64, it must have similar (for that binary search to work)

- For MIPS there's this PDR section and it appears to have the function 
start as well.

Andrew

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Daniel Jacobowitz]

On Sat, Nov 22, 2003 at 01:53:59PM -0500, Andrew Cagney wrote:
> >But Joel's case did have debugging information, I think - so just the
> >>minsyms are missing?
> >
> >
> >Yes, that's right. And one interesting thing I did find: "nm" on
> >mips-irix dumps the symbol from the symbol table AND the dwarf-2
> >info...
> 
> What about the ".pdr" section?
> 
> I get the feeling that core GDB has another really useful table just 
> beyond its fingertips - the unwind table - and that can be used to find 
> things like map from a pc to the function start/end/name/...:
> 
> - PPC64 has a traceback table just past the end of the function and that 
> can provide a pointer (tb_offset) back to the function's start
> 
> - For ia64, it must have similar (for that binary search to work)
> 
> - For MIPS there's this PDR section and it appears to have the function 
> start as well.

I don't believe that the IRIX tools generate .pdr.  I might be mistaken
about that, though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Joel Brobecker]

> > - For MIPS there's this PDR section and it appears to have the function 
> > start as well.
> 
> I don't believe that the IRIX tools generate .pdr.  I might be mistaken
> about that, though.

I confirm. I checked in a few executables, and couldn't find any section
named .pdr.

-- 
Joel

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Joel Brobecker]

> >   b. A recent version of the IRIX linker has introduced an extra asm CU
> >      (Compilation Unit) named "__sgi_ld_generated_code" which contains
> >      one function before CU gdb_local_symbol.adb, and 2 after. So the
> >      code range of gdb_local_symbol.adb is included in the code range
> >      of the linker CU.
> 
> What information does this have - does it have dwarf information or how
> else are we finding its code range?

This is coming from the dwarf-2 data. The code range is deduced from
the first function start address and the last function end address
(no low_pc and high_pc attributes).

> Rather than mesing with the minimal symbol table, we should probably be
> correcting the assumption.
> 
> Partial symbol tables include function addresses.  find_pc_sect_psymtab
> assumes that everything would have a minimal symbol, but we can
> probably correct that.

The problem I have at the moment is that I don't see how to correct it
reliably.

> The loop in that function looks quite strange
> to me: note that the inner loop uses the same variable, deliberately,
> as the outer loop.  Here's a better version of (b):
> 
> >      b. Then, we scan all the partial symtabs for the ones which code
> >         range include the given address. For all the qualifying ones,
> >         we check whether it contains a function which start address
> >         matches the minimal symbol address. If yes, then we have found
> >         the right symtab. Otherwise, we just return the first partial
> >         symtab we found.
> 							^^^^^^^^^^^^^^
> 							best match

Suppose you are indeed in a unit for which no debugging information has
been generated. In that case, we should not use any partial symtab,
but the minimal symbol right? How can we be sure of which approach
(debug info vs symbol table) to take without making a gamble?

Hmmm, but maybe I am slightly misunderstanding you: Are you suggesting
that, by returning the best match, the situation will improve, even
if not perfect? Would the best-match comparison use the "distance"
algorithm I have seen somewhere else? (we try to return the smallest
psymtab that contain the address).


> There's already code in find_pc_sect_psymbol to do this sort of
> best-match.  Something similar is needed here, but we need to be
> careful of the recursion.  Probably, find_pc_sect_psymtab should build
> on find_pc_sect_psymtab rather than the other way around to solve your
> problem.

Did you mean "Probably, find_pc_sect_psymtab should build on
find_pc_sect_symtab" (typo in second function name?). There is something
I am missing because I thought that the symtab list is not necessarily
compleite, as some psymtabs may not have been converted yet at the time
of the symtab scan. Which to me explained why we relied to the psymtabs
to find the appropriate symtab rather than the other way around...

-- 
Joel

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[Daniel Jacobowitz]

On Mon, Nov 17, 2003 at 05:24:19PM -0800, Joel Brobecker wrote:
> > >   b. A recent version of the IRIX linker has introduced an extra asm CU
> > >      (Compilation Unit) named "__sgi_ld_generated_code" which contains
> > >      one function before CU gdb_local_symbol.adb, and 2 after. So the
> > >      code range of gdb_local_symbol.adb is included in the code range
> > >      of the linker CU.
> > 
> > What information does this have - does it have dwarf information or how
> > else are we finding its code range?
> 
> This is coming from the dwarf-2 data. The code range is deduced from
> the first function start address and the last function end address
> (no low_pc and high_pc attributes).

OK, makes sense.

One thing that would solve your problem, then, would be to record
accurate ranges for psymtabs and symtabs.  This has been discussed
before but never implemented.  It may be the best solution.

> > Rather than mesing with the minimal symbol table, we should probably be
> > correcting the assumption.
> > 
> > Partial symbol tables include function addresses.  find_pc_sect_psymtab
> > assumes that everything would have a minimal symbol, but we can
> > probably correct that.
> 
> The problem I have at the moment is that I don't see how to correct it
> reliably.
> 
> > The loop in that function looks quite strange
> > to me: note that the inner loop uses the same variable, deliberately,
> > as the outer loop.  Here's a better version of (b):
> > 
> > >      b. Then, we scan all the partial symtabs for the ones which code
> > >         range include the given address. For all the qualifying ones,
> > >         we check whether it contains a function which start address
> > >         matches the minimal symbol address. If yes, then we have found
> > >         the right symtab. Otherwise, we just return the first partial
> > >         symtab we found.
> > 							^^^^^^^^^^^^^^
> > 							best match
> 
> Suppose you are indeed in a unit for which no debugging information has
> been generated. In that case, we should not use any partial symtab,
> but the minimal symbol right? How can we be sure of which approach
> (debug info vs symbol table) to take without making a gamble?

But at present, we might still use the preceding psymtab, wouldn't we?

> Hmmm, but maybe I am slightly misunderstanding you: Are you suggesting
> that, by returning the best match, the situation will improve, even
> if not perfect? Would the best-match comparison use the "distance"
> algorithm I have seen somewhere else? (we try to return the smallest
> psymtab that contain the address).

Similar, see below: the closes psymbol base address less than the
address.

> > There's already code in find_pc_sect_psymbol to do this sort of
> > best-match.  Something similar is needed here, but we need to be
> > careful of the recursion.  Probably, find_pc_sect_psymtab should build
> > on find_pc_sect_psymtab rather than the other way around to solve your
> > problem.
> 
> Did you mean "Probably, find_pc_sect_psymtab should build on
> find_pc_sect_symtab" (typo in second function name?). There is something 
> I am missing because I thought that the symtab list is not necessarily
> compleite, as some psymtabs may not have been converted yet at the time
> of the symtab scan. Which to me explained why we relied to the psymtabs
> to find the appropriate symtab rather than the other way around...

The typo was in the second function, but I meant
"find_pc_sect_psymbol".  With that does it make more sense?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] minimal symbols on mips-irix and overlapping CUs...

[David Anderson]

Joel writes:
|> > - For MIPS there's this PDR section and it appears to have the function 
|> > start as well.
|> 
|> I don't believe that the IRIX tools generate .pdr.  I might be mistaken
|> about that, though.
|
|I confirm. I checked in a few executables, and couldn't find any section
|named .pdr.


Quite right. In IRIX pdr is an area in the o32 mdebug
(third-eye) debug information, not an elf section.

What 'PDR section' above might have referred to:
The Elf section. 
		.rtproc 
is generated in o32 ELF to handle run-time stack walkback, as
in C++ or Ada exceptions.  In header files the struct is RPDR
defined in IRIX '/usr/include/sym.h'.
A run-time pdr, slightly different from an mdebug pdr.  
It is accessed like a variable via the data items
_procedure_table, and _procedure_table_size not thru section
headers (as a runtime feature) (_procedure_table,
procedure_table_size are per shared-library/executable, not
global). The data did not exist unless you asked for it, as in
CC -32 -exceptions, for example.

For o32 we also have (but I am having trouble remembering)
  in /usr/include/sys/elf.h
  #define MIPS_PDR_EXCEPTION     ".MIPS.pdr_exception"
which I cannot at the moment recall how to generate. If anyone cares
let me know and I'll find out.

Regards,
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea