Re: [RFC] Modernize HP-UX core file handling

[Randolph Chung <randolph at tausq dot org>]

> Do the following (I used something close to GCC 3.4.3):
> 
>         % gcc -o crash crash.c
>         % ulimit -c 100000
>         % ./crash
> 
> This should produce a core file that GDB should be able to debug.
> But the backtrace command fails:
> 
>         (gdb) core core
>         (gdb) bt
>         #0  0xc01f5e38 in kill () from /usr/lib/libc.2
>         #1  0x00002988 in cause_crash ()
>         warning: Cannot access memory at address 0xffffffed

i wonder why this is still not working for me:

tausq@hiauly3:~/src/build/gdb$ gcc -o crashme crashme.c
tausq@hiauly3:~/src/build/gdb$ ./crashme
ABORT instruction (core dumped)
tausq@hiauly3:~/src/build/gdb$ ./gdb ./crashme ./core
[...]
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

Reading symbols from /home/tausq/src/build/gdb/crashme...Segmentation fault (core dumped)

:-(

> The problem is that somehow r3 got clobbered during the call to kill,
> and no longer contains the frame base address (it contains 0x1). I am
> a bit surprised by this, since r3 is supposed to be callee-save.  In any
> case, GDB later fails when it uses that value as the base address where
> to read the saved RP from.

it will be useful to get the unwind record and disassembly for <kill>. 

> The current code seems a bit more complicated than it needs to be,
> at least to me. There is also a bit of duplication between the code that
> analyzes the prologue, and the code that just skips it. 

yeah, they are a bit duplicative; i thought about unifying them, but
they are not quite exactly the same. worse yet, we need to support two
different kinds of "skipping prologues" (as discussed in the comments)
:(

> This mixture
> between using part of the information from the unwind record, and
> some other information derived from analyzing the prologue may
> increase the complexity of the code.

is there another way? the unwind record itself does not give enough
information to determine the location of register values for a frame; it
only tells you how many registers are saved, so we still need to do code
reading to find out where they are actually saved. for your example, i'm
curious to know what "kill" looks like. if you placed a breakpoint on
kill (not the stub, but the real kill) and do a backtrace on a running
process, does it work?

> And also, the fact that the
> HP native compiler and GCC do not use the same convention for the
> frame (and the unwind record) makes it even more iffy. I am wondering
> whether it might be possible to simplify all this by using the usual
> approach relying mostly on prologue analysis and register tracking.

well, without using the unwind information, how do you determine 
where the prologue ends? how do you determine if e.g. r3 is being used
as a "regular" register or a frame pointer?

> I'm just speaking aloud right now, sharing some general ideas, as fixing
> the problem above within the current implementation does not seem easy
> without resorting to a hack. And it almost feels that it would be a
> hack on top on a pile of other hacks (no offense intended, it may be
> my lack of knowledge of the pa/hpux architecture too). For instance,
> if you look at the prologue skipping routine, you'll find that we
> include all instructions at the begining of a function until we have
> found where all registers are saved. We know before scanning the
> instrunctions that the SP was saved, but we don't know that the register
> containing the old SP has itself been saved on the stack. How to extend
> the loop condition to include that possibility? The code computing
> the frame cache also seems to be doing a lot of guessing... Perhaps
> the same sort of cleanup as what we did with Andrew for mips would
> be beneficial. It's something I'll keep on my long-term TODO list.
> 
> Anyway, just some thoughts.

i'm all ears to how we can simplify the code; we can possibly clean that
up a bit. the current code is mostly the result of fixing errors found
by the testsuite on hppa-linux. now that we are starting to do more hpux
stuff we are discovering more corner cases :( as long as we don't
compromise the results on hppa-linux i'm open to suggestions on how to
clean this up.

as you observed, gcc doesn't quite generate the same frame code as HP
compilers. This is a known problem, but since GDB is mostly consistent
with GCC, it's one that hasn't received a lot of attention.  The code
also contains workarounds for bugs in HP compilers (i wonder how old
that bit of code is) which doesn't help to simplify the code.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/