[ob(ish)/committed] Fix SEGV in hppa_frame_cache
Andrew Cagney
cagney@gnu.org
Sat Mar 6 00:42:00 GMT 2004
> I was happily testing what I hoped would be the latest version of
> the next/step patch replacing a complex condition by a frame ID
> comparison, when I discovered that it caused a few problems on
> HP/UX... But of course, HP/UX just got frame-ified!
>
> Here is a description of the first problem I looked into:
>
> (in gdb.base)
> % gdb
> (gdb) file coremaker
> (gdb) core-file corefile
> (gdb) up
> *** SEGV ***
>
> Ooops!
>
> What happens is that we hit the following code in hppa_frame_cache():
>
> /* Yow! */
> u = find_unwind_entry (frame_func_unwind (next_frame));
> if (!u)
> return;
That 'll learn me for using the HP compiler :-/
> Unfortunately, that return causes the return value to be undefined.
> And we later crash while trying to dereference this undefined value
> in hppa_frame_this_id().
>
> So I fixed it with the attached patch. This fixed 8 tests.
> I didn't commit it to the 6.1 branch yet, as I wanted to wait for
> Andrew's comments first. Don't want to disturb the branch too much.
For HP/UX, I think we'll be doing frequent pull-ups - this will be just
the first of many bugs :-( Definitly go ahead.
> There is also something that bothers me. If I understand this code well,
> it looks like we are going to abort the unwinding as soon as we hit a
> frame for which we can't find an associated function. Is that correct?
Yes, its taken straight from hppa_frame_find_saved_regs.
> That would be very unfortunate, especially after we manage to install
> the next/step patch I was testing; Once this patch is installed, the
> chances us GDB trying to unwind from an unknown location will be more
> important, no? If we don't know how to find our way out of there, then
> the next/step machinery will be weakened. Andrew, if you confirm my
> understanding is correct, I'll try to see if we can do better.
The code just needs to be sufficient to unwind one level of PC/FP - so
that the caller can be found. Having some of the frame saved pc code
before the abort would improve things. As for the SP:
You must be looking for a challenge, from frame_chain:
if (!u)
{
/* We could find this information by examining prologues. I
don't
think anyone has actually written any tools (not even "strip")
which leave them out of an executable, so maybe this is a moot
point. */
/* ??rehrauer: Actually, it's quite possible to stepi your
way into
code that doesn't have unwind entries. For example,
stepping into
the dynamic linker will give you a PC that has none.
Thus, I've
disabled this warning. */
#if 0
warning ("Unable to find unwind for PC 0x%x -- Help!",
get_frame_pc (t
mp_frame));
#endif
return (CORE_ADDR) 0;
}
Andrew
More information about the Gdb-patches
mailing list