Re: Simple but crucial bug fix to gdb

[Daniel Berlin <dan at cgsoftware dot com>]

Christopher Faylor <cgf@redhat.com> writes:

> On Thu, May 31, 2001 at 03:56:32PM -0500, Jim Blandy wrote:
> >
> >Fernando Nasser <fnasser@redhat.com> writes:
> >> Irrelevant to the fact that his compiler may not be doing the right
> >> thing, GDB should not be dumping core.
> >
> >That's absolutely true.
> >
> >> I sincerely expect that you provide us with the "more correct" fix asap.
> >
> >Please, don't be upset.  I can't provide a more correct fix without
> >understanding the user's situation more.  I asked him a question in a
> >message before the one I sent you, and I'm waiting to see what he
> >says.
> >
> >Each partial symbol table object has an address range, textlow and
> >texthigh, which is supposed to enclose all the functions it covers.
> >If that address range is not set correctly, then GDB may not be able
> >to find the full symbols for a given text address.
> >
> >The user has a stabs file which manages to get textlow_not_set cleared
> >(indicating that pst->textlow has been set), while pst is zero.  This
> >is very curious --- if the pst is zero, which textlow was it that got
> >set?
> >
> >There's something very odd (or, as Daniel would have me say, even
> >odder than usual) going on here.  Rather than slap a test for null
> >over the problem and have it disappear, I want to try to understand
> >what's going on.
> >
> >If you've got scurvy, you want limes, not spare teeth.
> 
> Is there some reason why you are not responding to the part of the
> analysis which points to pst being guarded against NULL earlier in the
> file?
>   Why is it ok to do this at one point and not ok a few lines
> later?  Does SOFUN_ADDRESS_MAYBE_MISSING have some bearing on this
> or is the existing code actually broken?

The reason it's guarded against earlier is for the case where you have
a textlow of 0. Like in an object file.

We don't want to change the textlow address if that's really what it
claims the starting address to be.

So if we've started a psymtab, and we think textlow_not_set, and we
see a function, we assume everything is copacetic.

However, we should *never* see a case where pst is NULL, and
textlow_not_set is 1, at the point we see a function.
This would imply either some other code is broken, or the compiler is
producing symbols that appear outside of all the source files, which is
specifically not allowed.  We also won't get the function address
right if this is the case, unless we patch it up later, so we actually
need to completely skip this symbol. The current patch will still add
the psymbol to the list, which is a bad idea, since we *know* the
address is wrong.

Guarding against NULL is also the wrong thing to do here anyway, unless the
compiler really is that broken.  IN which case, you probably actually
need to kludge somewhere *else*, so that we don't run into this case.
Guarding against null is equivalent of ignoring the problem until it
goes away.  It's certainly something that shouldn't be done without
making it clear that something has gone very awry.
> 
> cgf

-- 
"It's a good apartment because they allow pets.  I have a
Shetland pony named Nikkie.  Last summer Nikkie was involved in
a bizarre electrolysis accident.  All her hair was removed
except for her tail.  Now I rent her out to Hare Krishna family
picnics.
"-Steven Wright