From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: gdb-patches@sources.redhat.com Subject: Re: Simple but crucial bug fix to gdb Date: Thu, 31 May 2001 17:40:00 -0000 Message-id: <87ofs9hw29.fsf@dynamic-addr-83-177.resnet.rochester.edu> References: <3.0.5.32.20010530142745.01470ec0@pophost.pdxuxbre.lmc.com> <20010530173650.A21397@redhat.com> <3B15711D.BEA4B77E@cygnus.com> <3B1638A2.79AE4BCF@redhat.com> <20010531194656.A27403@redhat.com> X-SW-Source: 2001-05/msg00516.html Christopher Faylor writes: > On Thu, May 31, 2001 at 03:56:32PM -0500, Jim Blandy wrote: > > > >Fernando Nasser 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