This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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...