"Charles B. Owen" <[EMAIL PROTECTED]> writes:
>It's a known bug that gdb (I've tried up to 5.0) fails when debugging any
>executable that includes pthreads under Irix 6.5 (fails with unknown signal
>message and locks up).  I tried mapping the various signals, but could not
>get it to work.  Has anyone got a fix in the works?  Does anyone have any
>ideas of how to debug g++ code on an Irix machine that uses threads short of
>lots of print statements?  Any help will be greatly appreciated.

Here's the situation as I understand it. FWIW.

The only means for debugging IRIX6.5 pthreads  apps is to use
a shared library named 'libspypt.so' (the debugger itself must do this)
and a bunch of unique-to-irix calls into libspypt.so. 

This library interface is shipped with IRIX, so the IRIX folks
ensure the two work together across IRIX changes -- while keeping
the interface constant so the debugger executable
itself is independent of which IRIX6.5 is in use.

AFAIK, only IRIX debuggers (dbx, WorkShop) and a perhaps-unreleased
version of TotalView (from Etnus) know the interface.
And the demangler library code in dbx and WorkShop does not know about
g++ demangling.

The pthreads-debug interface is a bit complicated because of the, um, messy
relations between per-thread and per-process actions.
We've not documented the interface publicly, AFAIK.
It's not a secret, it's just not documented publicly yet.
It's not a simple extension of the /proc ioctl's...

I do hope to contribute gdb patches on this some time this year.
(of course with comments explaining the interface).
(I'll be on vacation for 6 weeks starting July 11, so don't hope
for any action soon...).

Sorry.
David B. Anderson [EMAIL PROTECTED] [EMAIL PROTECTED] http://reality.sgi.com/davea/

Reply via email to