Re: RFC: partial symbol table address range generalization

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Oct 23, 2001 at 11:15:38PM -0500, Jim Blandy wrote:
> > As far as getting this information from the stabs reader, we should be
> > able to do it if we know separate "possible" and "definite" ranges, I
> > think.  I'm not sure if we have enough information to do this.  We
> > don't for the general case, but we should generally have one "definite"
> > range per file (corresponding to the main .text segment).  It would be
> > nice to at least take this region out of any symtabs that seem to
> > encompass it, so that if the main program is built without
> > -ffunction-sections, we will behave sanely in the presence of (say)
> > libstdc++.a.
> 
> I encourage you to take a shot at it.  The idea is to have `struct
> addrset' support a bunch of groovy operations (like set subtraction,
> testing for intersections between two sets, etc.), carefully coded and
> gotten right once and for all, that make it easy to do this kind of
> sanity checking and refinement.  Here's the header file for the code
> I've got now; imagine adding the setwise ops you want here, and then
> using them in the stabs reader.

I've got a question.  What we really want to represent here are not
just sets of addresses, but a single address space and the symtabs
known to correspond to different sections of it.  Would it be more
useful to represent them that way, so that the code to search the
address space would only happen once for all psymtabs/symtabs?

Then we could work on splitting off "ranges known to belong to this
objfile" and "ranges suspected to belong to this objfile" somehow.  I'm
not sure how much information of this sort we can really get from
stabs, though, so it may not be worthwhile from that perspective; but
it might be more efficient anyway.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer