Re: RFC: partial symbol table address range generalization

[Andrew Cagney <ac131313 at cygnus dot com>]

> - Changing the STABS partial symbol table scanner to recognize
>   non-contiguous .o files seems like it should be possible, but I
>   wasn't able to do it in a way that I was sure wouldn't break any
>   targets.  So for now, I'm going to leave the STABS reader alone; the
>   data structures will be capable of describing non-contiguous .o
>   files on STABS platforms, but the reader will never recognize them.

Given that GCC's emphasis is on dwarf2, the above task can fall to the 
person that wants GDB + GCC + stabs to work.  Further, your change 
neither breaks nor removes existing functionality from stabs or any 
other debug format.  If anything it sets things up ready for others.

So I can't see anyone objecting on those grounds.

> +     /* STABS doesn't reliably give us nice start and end addresses for
> +        each function.  Instead, we are told the addresses of various
> +        boundary points, and we have to gather those together to build
> +        ranges.  These are our running best guess as to the range of
> +        text addresses for this psymtab.  */
> +     CORE_ADDR textlow, texthigh;

Just a side thought.  When working with the code, I've never been 100% 
certain how to interpret the high/low (and on occasion have encountered 
off by 1 errors).  Perhaphs include ``[textlow, texthigh)'' or was it 
``[textlow, texthigh]'' where relevant in the commentry.

nice,
Andrew