[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