No Subject

No Subject

[@ 2001-03-29 16:27 UTC (permalink / raw)]

No Subject

[@ 2001-03-29 16:26 UTC (permalink / raw)]

No Subject

[Thompson, James C]

This problem has already been reported to the bugs list:

    http://www.cygnus.com/ml/gdb-bugs/1999-Jan/0001.html

But I would like to add some clarifying information.  I'd be willing to help
find and fix this problem, because I like gdb very much and want to use it
for my IRIX development.  However, I've already taken my investigation about
as far as I can by myself, so I need some help.

The problem occurs with the following software versions:

    gdb 4.17, as released last year
    gdb 4.17.85 (4.18 pre-release candidate), recently released
    IRIX 6.5

My gdb startup report is as follows:

	foreigner [248]--> ./gdb ./hello
	GNU gdb 4.17.85
	Copyright 1998 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 "mips-sgi-irix6.5"...
	(gdb)  

The original bug report mentioned code compiled with gcc; I have the same
problem with MIPSpro C/C++.  I suspect that the compiler doesn't matter.

The problem is as reported earlier; to summarize: it occurs when trying to
debug any program that has the posix threads library (-lpthread) linked in.
Gdb reports an unknown signal, then nothing further happens (it hangs):

	(gdb) run
	Starting program: /home/jct/zetetic/hello/./hello
	warning: Signal ? does not exist on this system.

Interrupting the process (C-c) results in:

	/proc/2428755: Interrupted function call.
	PIOCSTATUS or PIOCWSTOP failed.
	(gdb)

This is all as previously reported;  I can add the following:

First, it doesn't matter what the program is actually trying to do, because
it never gets to main().  In fact, to recreate the problem only requires
that the POSIX threads library be linked in.  The problem can be recreated
with just a simple hello-world program, if it's linked with the pthreads
library:

    cc hello.c -o hello -lpthread

The same program without -lpthread will run without problem in the debugger.

Second, the problem appears to occur in the __start function:

	(gdb) where
	#0  __start ()
	    at
/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s:103

Finally, I used gdb to debug itself, after locating the function that was
producing the error and setting a breakpoint.  The problem signal is the
third to arrive:

	foreigner [259]--> ./gdb ./gdb
	GNU gdb 4.17.85
	Copyright 1998 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 "mips-sgi-irix6.5"...
	Setting up the environment for debugging gdb.
	During symbol reading, type qualifier 'const' ignored.
	Breakpoint 1 at 0x101519e8: file utils.c, line 474.
	Breakpoint 2 at 0x1014e670: file top.c, line 2608.
	(top-gdb) break target_signal_to_host
	Breakpoint 3 at 0x100c4adc: file target.c, line 1482.
	(top-gdb) run ./hello
	Starting program: /home/jct/build/gdb-4.17.85/gdb/./gdb ./hello
	GNU gdb 4.17.85
	Copyright 1998 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 "mips-sgi-irix6.5"...
	Setting up the environment for debugging gdb.
	.gdbinit:5: Error in sourced command file:
	Function "fatal" not defined.
	(gdb) run
	Starting program: /home/jct/build/gdb-4.17.85/gdb/./hello

	Breakpoint 3, target_signal_to_host (oursig=TARGET_SIGNAL_0) at
target.c:1482
	1482      switch (oursig)
	(top-gdb) p oursig
	$1 = TARGET_SIGNAL_0
	(top-gdb) cont
	Continuing.

	Breakpoint 3, target_signal_to_host (oursig=TARGET_SIGNAL_0) at
target.c:1482
	1482      switch (oursig)
	(top-gdb) p oursig
	$2 = TARGET_SIGNAL_0
	(top-gdb) cont
	Continuing.

	Breakpoint 3, target_signal_to_host (oursig=TARGET_SIGNAL_UNKNOWN)
	    at target.c:1482
	1482      switch (oursig)
	(top-gdb) p oursig
	$3 = TARGET_SIGNAL_UNKNOWN
	(top-gdb) printf "%d\n", oursig
	76
	(top-gdb) 

This is where it gets weird, for me at least.  Signal 76?  I've never heard
of such a beast, and it's not documented in the IRIX man pages.  However, I
do know that some operating systems, Solaris for example, use special
signals for the kernel to notify the process of changes in its runnability,
for the purposes of scheduling user threads or somesuch.  Perhaps that's
what's going on here.  Either that or the signal value is getting mangled
somewhere.  I couldn't find the signal handler, though, to check the
signal's original value.  I tried to understand the signal setup inside gdb,
but it's rather, um, complex and I wasn't able to follow it.

I was able to follow the stack trace further up, though:

	(top-gdb) where
	#0  target_signal_to_host (oursig=TARGET_SIGNAL_UNKNOWN) at
target.c:1482
	During symbol reading, type qualifier 'const' ignored.
	#1  0x100a52c0 in procfs_resume (pid=-1, step=0,
signo=TARGET_SIGNAL_UNKNOWN)
	    at procfs.c:3808
	#2  0x100ab1fc in solib_create_inferior_hook () at irix5-nat.c:1259
	#3  0x100a1700 in fork_inferior (
	    exec_file=0x102a6788 "/home/jct/build/gdb-4.17.85/gdb/./hello",
	    allargs=0x1029ac38 "", env=0x1029b860,
	    traceme_fun=0x100a3a10 <proc_set_exec_trap>,
	    init_trace_fun=0x100a35c0 <procfs_init_inferior>,
pre_trace_fun=0,
	    shell_file=0x7fff35ab "/usr/freeware/bin/bash") at
fork-child.c:414
	(top-gdb)    

It looks like the function solib_create_inferior_hook is in a tight loop
waiting for something (for shared libraries to load?).  When signal 76
arrives, the child process stops, but because gdb doesn't know how to deal
with that signal number, it's unable to restart the child, hence the whole
thing hangs.

Again, I've taken this as far as I can, but would be happy to act as a
remote pair of hands and eyes if the gdb team doesn't have an IRIX 6.5
system handy for testing.

(BTW, I'm sorry about the crappy formatting of the gdb sessions above, but
I'm required to use MS Outlook from this site.)

--JT

No Subject

[Jason P. Jesso]

No Subject

[Jeffrey A Law]

More info on HP shutting down the Mass language labs -- apparently
all activities are being transferred to CLL (Cupertino Language Lab).

First mention of Cygnus in this thread that I've seen.

------- Forwarded Message

Sender:   law@cygnus.com
From:     rehrauer@apollo.hp.com
To:       law@cygnus.com
Date:     Mon, 22 Dec 1997 08:25:47 -0800
Subject:  WDB, a GDB-based debugger for HP-UX

Path: cygnus.com!news.sgi.com!sdd.hp.com!apollo.hp.com!rehrauer
From: rehrauer@apollo.hp.com (Steve Rehrauer)
Newsgroups: comp.sys.hp.hpux
Subject: Re: WDB, a GDB-based debugger for HP-UX
Date: 22 Dec 1997 14:28:50 GMT
Organization: Hewlett-Packard Company, Chelmsford, MA
Lines: 27
Message-ID: <67ltf2$jrg$1@hpwhey.ch.apollo.hp.com>
References: <676hjj$9ja$1@hpwhey.ch.apollo.hp.com> <34971415.4A4E@mmm.com> <67b
as6$os0$1@hpwhey.ch.apollo.hp.com> <cdmoh2dmcag.fsf@eskimo.nvl.virginia.edu>
NNTP-Posting-Host: jurassic.ch.apollo.hp.com
Xref: cygnus.com comp.sys.hp.hpux:77982

In <cdmoh2dmcag.fsf@eskimo.nvl.virginia.edu>, Adrian Filipi-Martin says:
>	Hmmm.  I related your previous announcement to a colleague
>working on a uniform debugging interface for high perfroamnce
>computing.  She has been in contact with HPC developers/policy makers
>at various companies, HP included.  She also tells me that WDB
>development was recently put on hold for a year.  Do you know anything
>of this?  I tend to prefer your announcement, but she can claims to
>have a direct line to god on this issue.

Well, my communications with the Divine are a little more circumspect. :-)

I'm guessing she's heard that the Chelmsford, MA site is being closed; its
projects (including WDB) being transferred to our sister lab in Cupertino,
CA; and inferring a long delay from those facts.

In truth, the impact on WDB is unclear.  The project has certainly not been
cancelled, nor even put on hold!  Feedback within HP has been clearly positive
and supportive.  There can't help but be some delays in the short-term, of
course.  But in the long-term, being physically closer to the other HP-UX
language projects (to say nothing of Cygnus Solutions, the maintainers of
GDB) can only be good for WDB, in my opinion.

But of course, "I don't speak for HP."  --Steve
- -- 
All software is bug-free, assuming          | Steve rehrauer@apollo.hp.com
 sufficiently clever definitions of         | ex-Massachusetts Language Lab
 "feature" and "expected behaviour".        | USDA Zone 5, more or less

------- End of Forwarded Message