Multi-Threaded Extensions for GdbServer

Multi-Threaded Extensions for GdbServer

[Marius Groeger]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 982 bytes --]

Hi all,

several people asked me to post this to the wider audience of gdb
developers. AFAIK there are several approaches for extending the
gdbserver to be able to debug remote programs that use threads. The
attached patch does this. The main advantage of it is that it doesn't
require libthread_db or symbol information on the target. We need
this for debugging of embedded targets with limited resources.
The main downside of the patch is that it's for some pretty ancient
5.0 snapshot (20010427). It also contains a small number of general
fixes which are not related to MT debugging.

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions GmbH     mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 39711 bytes --]

Re: Multi-Threaded Extensions for GdbServer

[Daniel Jacobowitz]

On Wed, May 22, 2002 at 10:50:24AM +0200, Marius Groeger wrote:
> Hi all,
> 
> several people asked me to post this to the wider audience of gdb
> developers. AFAIK there are several approaches for extending the
> gdbserver to be able to debug remote programs that use threads. The
> attached patch does this. The main advantage of it is that it doesn't
> require libthread_db or symbol information on the target. We need
> this for debugging of embedded targets with limited resources.
> The main downside of the patch is that it's for some pretty ancient
> 5.0 snapshot (20010427). It also contains a small number of general
> fixes which are not related to MT debugging.

Not needing symbol information on the target is definitely the way to
go, but libthread_db is very small and has better reliabilty.  I'm
still finishing the legal legwork to get this work committed (I've
already finished it); it should be early next week (really!).  After
that I'll take a better look at what you've sent; it may have useful
advantages that I can merge into the existing code.  It would be nice
to support both with and without thread_db.

I notice that you added glibc specific code to remote.c and some
protocol extensions; that makes this unsuitable to just drop in.
I believe you needed the same extension that was added in a later
version of GDB for looking up symbols, so this isn't a big deal in any
case.

Thanks!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Multi-Threaded Extensions for GdbServer

[Marius Groeger]

On Sat, 25 May 2002, Daniel Jacobowitz wrote:

> still finishing the legal legwork to get this work committed (I've
> already finished it); it should be early next week (really!).  After
> that I'll take a better look at what you've sent; it may have useful
> advantages that I can merge into the existing code.  It would be nice
> to support both with and without thread_db.

Thanks, please keep us posted.

Regards
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions GmbH     mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

Re: Multi-Threaded Extensions for GdbServer

[Andrew Cagney]

> I notice that you added glibc specific code to remote.c and some
> protocol extensions; that makes this unsuitable to just drop in.
> I believe you needed the same extension that was added in a later
> version of GDB for looking up symbols, so this isn't a big deal in any
> case.

FYI, the GLIBC maintainer is not willing to support anything other than 
the published [functional] libthread-db interfaces.  While teaching GDB 
the internals of GLIBC might get things working short term, it won't 
work long term unless the GLIBC maintainer is willing to publish those 
internal details as part of a formal interface.

enjoy,
Andrew