Re: gdb4-17.86 build issues on HP-UX 10.20 and 11.0

[Mike Vermeulen <mev@hpclhayb.cup.hp.com>]

> Although it now builds OK, it doesn't work --- the run command forks
> a subprocess but the subprocess never seems to get as far as actually
> running the target program.  It looks like it's hanging up while the
> subprocess is still running a shell, if ps is to be believed:
> 
> tgl 21107 11905  0 18:57:22 ttyp6    0:00 gdb cjpeg
> tgl 21108 21107  0 18:57:41 ttyp6    0:00 /bin/ksh -c exec /users/tgl/jpeg/sr
c/cjpeg <testimg.ppm
> 
> Any suggestions on debugging that?

Looking at the code, I have a guess of how of what is going on and how
one would solve it.  I don't immediately have time to put together this
configuration or adequately test it, so let me pass my suggestion along...

This code has the following structure:

	if (...condition...){
           compute offsets to fetch 32-bit wide registers from save state
	} else {
           compute offsets to fetch 64-bit wide registers from save state
	}

All the patch did was #ifdef out some code from the else clause,
so no register is being fetched at all!, probably why things are
hanging.

Instead, one should recognize that on HP-UX 9.X, the "else" case never
applies (*) and make the appropriate patch so that on 9.x we do just the
stuff in the "if" clause and if #ifdef CPU_HPPA_RISC_20 is defined we have
the "if" and the "then" parts...

--mev, Mike Vermeulen

(*) The reason the else clause never applies is that with PA-8000, HP added
    many 64-bit wide registers.  These can be accessed even in 32-bit codes
    and are supported even for PA7100 and earlier architectures on HP-UX 10.20.

    The HP-UX 9.X kernel never knows about these wider registers and
    HP-UX 9.X will not run on PA8000 architecture machines.  Hence, no
    definition of the wide-mode save state or way to fetch from it...