🚀 go-pugleaf

Dear Listener,

Please tell me whether the following is a known problem, or else advise 
about the steps I am taking to diagnose it.

My machine: HP-UX hp5 B.11.00 A 9000/785 2002388384 two-user license
    - this is running 64-bit hpux, but I am debugging 32-bit som programs

Details of gdb:
$ gdb
GNU gdb 5.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa2.0-hp-hpux11.00".

Built with GCC 3.0.3.

The README says that it doesn't build.  I disagree; it built for hppa2.0 
(som binaries) and hppa2.0w (64-bit elf binaries).

I have hacked it as formerly described to this list, to do interactive 
debugging.


When I evaluate function calls (eg print malloc(20)), the substantive 
program SEGV's, possibly with kernel reports of stack-growth 
failure.  Increasing maxssize and maxssize_64 has no effect.

Attempting to evaluate the problem, hand_function_call assembles the stack 
frame, then the SEGV happens while trying to run_stack_dummy.  My best 
handle on what's going on is (in another gdb debugging the first):

(gdb) bt 2
#0  write_register_pid (regnum=33, val=310500, ptid=Error accessing memory 
address 0x2: Invalid argument.
) at regcache.c:525
#1  0x00071ad4 in target_write_pc (v=310500, ptid=
       {pid = 0, lwp = 0, tid = 9523}) at hppa-tdep.c:2437
(More stack frames follow...)

which suggests that the PC is not being reset correctly, so the program is 
being commanded to jump into space.  If anyone has a compelling reason for 
believing that this is an artifact in the second gdb (which wouldn't 
surprise me completely) please tell me.

Other suggestions welcome.

Sincerely,
James Cone.