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

[Daniel Jacobowitz <drow at mvista dot com>]

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