🚀 go-pugleaf

J. Cone writes:
 > Dear Sir/Madam,
 > 
 > Please tell me whether the following is a known problem, or else tell me 
 > where to stick printf's into the gdb code to try to understand 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).
 > 
 > It does post-mortem debugging apparently correctly, although it may be 
 > mis-interpreting the location of the vtable pointers in C++.
 > 
 > When I try to run a program from within it, I get to a state like this:
 > 
 > # ps -ef | fgrep smsM
 > smf_oper  8391     1  0 18:12:28 pts/0     0:00 ./smsMaster
 > smf_oper  8731  8701  0 18:14:13 pts/ta    0:00 gdb bin/smsMaster.jcone
 > smf_oper  8701  3418  0 18:14:11 pts/ta    0:00 gdb bin/smsMaster.jcone
 >      root  9470  9012  0 18:14:24 pts/tb    0:00 fgrep smsM
 > # ps -lp 8731
 >    F S        UID   PID  PPID  C PRI 
 > NI             ADDR   SZ            WCHAN TTY       TIME COMD
 >   11 R        102  8731  8701  0 152 
 > 20         422c3700  900                - pts/ta    0:00 gdb
 > # ps -lp 8701
 >    F S        UID   PID  PPID  C PRI 
 > NI             ADDR   SZ            WCHAN TTY       TIME COMD
 >    1 S        102  8701  3418  0 152 
 > 20         422c3700  900          2000fa8 pts/ta    0:00 gdb
 > 
 > The gdb hangs forever having produced:
 > 
 > (gdb) run
 > Starting program: /volA/IN/service_packages/SMS/bin/smsMaster.jcone
 > 
 > and only kill -9 will kill the child, after which the parent (the original 
 > gdb) will bus-error.
 > 
 > 
 > I can't get a debugger onto the child, because it's already being debugged.
 > 
 > I can't get a debugger onto the parent.  When I try, I get:
 > 
 > Attaching to program: /opt/gcc-3.0.3/bin/gdb, process 11446
 > ttrace attach: Lockf deadlock detection.
 > 
 > the manual page for which says someone has vfork'ed and not yet exec'd.
 > 
 > Sincerely stuck,
 > James Cone.
 > 
 > 


Yes, known problem, vfork seems to not work properly on such platform.
Try this patch (of course, adapt it to hpux1100.mh or whatever
makefile fragment you end up using).

Elena


Index: hpux1020.mh
===================================================================
RCS file: /cvs/uberbaum/gdb/config/pa/hpux1020.mh,v
retrieving revision 1.3
diff -u -r1.3 hpux1020.mh
--- hpux1020.mh 2002/01/18 04:51:05     1.3
+++ hpux1020.mh 2002/01/21 19:01:06
@@ -1,10 +1,10 @@
 # Host: Hewlett-Packard PA-RISC machine, running HPUX 10.20
 
-MH_CFLAGS = -D__HP_CURSES
+MH_CFLAGS = -D__HP_CURSES -Dvfork=fork


 > 
 > _______________________________________________
 > Bug-gdb mailing list
 > Bug-gdb@gnu.org
 > http://mail.gnu.org/mailman/listinfo/bug-gdb