This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: partial symbol table address range generalization
- To: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: RFC: partial symbol table address range generalization
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 23 Oct 2001 21:35:24 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <20011023233450.09F855E9D8@zwingli.cygnus.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