This is the mail archive of the
mailing list for the GDB project.
Re: [ob(ish)/committed] Fix SEGV in hppa_frame_cache
- From: Andrew Cagney <cagney at gnu dot org>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 05 Mar 2004 19:42:19 -0500
- Subject: Re: [ob(ish)/committed] Fix SEGV in hppa_frame_cache
- References: <20040305050546.GC1226@gnat.com>
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:
(gdb) file coremaker
(gdb) core-file corefile
*** SEGV ***
What happens is that we hit the following code in hppa_frame_cache():
/* Yow! */
u = find_unwind_entry (frame_func_unwind (next_frame));
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
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:
/* We could find this information by examining prologues. I
think anyone has actually written any tools (not even "strip")
which leave them out of an executable, so maybe this is a moot
/* ??rehrauer: Actually, it's quite possible to stepi your
code that doesn't have unwind entries. For example,
the dynamic linker will give you a PC that has none.
disabled this warning. */
warning ("Unable to find unwind for PC 0x%x -- Help!",
return (CORE_ADDR) 0;