From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFC: partial symbol table address range generalization Date: Tue, 23 Oct 2001 16:54:00 -0000 Message-id: <20011023195430.A15242@nevyn.them.org> References: <20011023233450.09F855E9D8@zwingli.cygnus.com> X-SW-Source: 2001-10/msg00305.html On Tue, Oct 23, 2001 at 06:34:50PM -0500, Jim Blandy wrote: > At the moment, GDB's partial symbol table structures assume that each > compilation unit's text occupies a single contiguous range of > addresses. If a given address falls between a `struct partial_symtab' > structure's `texthigh' and `textlow' addresses, then GDB assumes that > reading that partial symbol table's debugging info will provide > complete information about that address. > > However, this assumption isn't true. A given .o file's code can > actually appear in any number of distinct regions, separated by code > from other .o files. This can happen when we compile and link a C++ > program, like the below (from GCC's test suite): I'd like to point you at my thoughts from the first time I noticed this behavior: < http://sources.redhat.com/ml/gdb/2001-08/msg00161.html > When I looked at this problem in August, I wasn't brave enough to suggest the solution you're proposing (which I completely agree with). However... > There is some logic in GDB's lookup functions to cope with overlapping > partial symtabs, and they've been working pretty well on our behalf. > However, they're fragile, and do break in everyday use. For example, > in the executable produced from the source file above, if you try to > set a breakpoint on a library routine compiled without debug > information, GDB will set the breakpoint in `main' instead. (On some > platforms, `_exit' is such a function.) This particular problem should be avoidable anyway. I would appreciate it if you would look at: < http://sources.redhat.com/ml/gdb/2001-09/msg00068.html > 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer