Re: [ob(ish)/committed] Fix SEGV in hppa_frame_cache

[Andrew Cagney <cagney@gnu.org>]

> 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