Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* User level threads debugging with GDB
@ 2010-04-09  8:12 PILLON Julien
  2010-04-09 10:49 ` Paul Koning
  0 siblings, 1 reply; 5+ messages in thread
From: PILLON Julien @ 2010-04-09  8:12 UTC (permalink / raw)
  To: gdb

Hi,
I would like to know the right way to do some user-level threads debugging with GDB and I have a few questions :  
First, the main work will be within the libthread_db (especially in the td_ta_new function I guess) but what else must be modified and what can be left as is ?
Next, how should I implement the stack printing ? 
Is the attach mode altered with this kind of modifications ? And if it is, where are the sources to modify ?

regards

Julien


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: User level threads debugging with GDB
  2010-04-09  8:12 User level threads debugging with GDB PILLON Julien
@ 2010-04-09 10:49 ` Paul Koning
  2010-04-09 13:04   ` RE : " PILLON Julien
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Koning @ 2010-04-09 10:49 UTC (permalink / raw)
  To: PILLON Julien, gdb

I've just gone through this for NetBSD...

If your platform has a libthread_db then it seems sensible to use that
and interface GDB to it, as Linux does (or can do; it doesn't seem to do
it in all cases).  If not, then you don't need to create one.  Some
existing files offer various pieces of the answer that you can use.  For
example, dec-threads.c is short and simple but not necessarily a
complete answer.  linux-nat.c is very helpful but a bunch of what it
does exists because of extra work needed on Linux.

Stack printing relies on the register access routines; those have to
work per thread.  If they do then the rest just works.

I found the main changes were in the "wait" and "resume" routines.  In
"wait" because after the wait finishes you want to get the list of
threads and their status, and use the GDB routines that update GDB's
list of threads.  In  "resume" because you need to be able to step and
continue a single thread as well as all threads.  

For any given platform, I expect that you'll find parts of the answer in
several of the existing threads support files, but probably not the
whole answer in any one of them.

	paul

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of PILLON Julien
> Sent: Friday, April 09, 2010 4:13 AM
> To: gdb@sourceware.org
> Subject: User level threads debugging with GDB
> 
> Hi,
> I would like to know the right way to do some user-level threads
> debugging with GDB and I have a few questions :
> First, the main work will be within the libthread_db (especially in
the
> td_ta_new function I guess) but what else must be modified and what
can
> be left as is ?
> Next, how should I implement the stack printing ?
> Is the attach mode altered with this kind of modifications ? And if it
> is, where are the sources to modify ?
> 
> regards
> 
> Julien


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE : User level threads debugging with GDB
  2010-04-09 10:49 ` Paul Koning
@ 2010-04-09 13:04   ` PILLON Julien
  2010-04-09 13:43     ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: PILLON Julien @ 2010-04-09 13:04 UTC (permalink / raw)
  To: Paul Koning, gdb

Thank you for your answer. 
The fact is that I don't want to make big modification to GDB... So I think  I'll go on implementing a libthread_db (with this method, it will be compatible with future (and previous ?) versions of GDB )
So if I've understood well, if my implementation (td_ta_new, td_thr_get*regs) is correct, the stack printing will be ok with a out of the box GDB ?

And will the atttach mode be ok too or is there some special work to do ?


Julien
________________________________________
De : Paul Koning [Paul_Koning@Dell.com]
Date d'envoi : vendredi 9 avril 2010 12:49
À : PILLON Julien; gdb@sourceware.org
Objet : RE: User level threads debugging with GDB

I've just gone through this for NetBSD...

If your platform has a libthread_db then it seems sensible to use that
and interface GDB to it, as Linux does (or can do; it doesn't seem to do
it in all cases).  If not, then you don't need to create one.  Some
existing files offer various pieces of the answer that you can use.  For
example, dec-threads.c is short and simple but not necessarily a
complete answer.  linux-nat.c is very helpful but a bunch of what it
does exists because of extra work needed on Linux.

Stack printing relies on the register access routines; those have to
work per thread.  If they do then the rest just works.

I found the main changes were in the "wait" and "resume" routines.  In
"wait" because after the wait finishes you want to get the list of
threads and their status, and use the GDB routines that update GDB's
list of threads.  In  "resume" because you need to be able to step and
continue a single thread as well as all threads.

For any given platform, I expect that you'll find parts of the answer in
several of the existing threads support files, but probably not the
whole answer in any one of them.

        paul

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of PILLON Julien
> Sent: Friday, April 09, 2010 4:13 AM
> To: gdb@sourceware.org
> Subject: User level threads debugging with GDB
>
> Hi,
> I would like to know the right way to do some user-level threads
> debugging with GDB and I have a few questions :
> First, the main work will be within the libthread_db (especially in
the
> td_ta_new function I guess) but what else must be modified and what
can
> be left as is ?
> Next, how should I implement the stack printing ?
> Is the attach mode altered with this kind of modifications ? And if it
> is, where are the sources to modify ?
>
> regards
>
> Julien


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: RE : User level threads debugging with GDB
  2010-04-09 13:04   ` RE : " PILLON Julien
@ 2010-04-09 13:43     ` Daniel Jacobowitz
  2010-04-09 13:54       ` RE : " PILLON Julien
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2010-04-09 13:43 UTC (permalink / raw)
  To: PILLON Julien; +Cc: Paul Koning, gdb

On Fri, Apr 09, 2010 at 03:04:28PM +0200, PILLON Julien wrote:
> Thank you for your answer. 
> The fact is that I don't want to make big modification to GDB... So I think  I'll go on implementing a libthread_db (with this method, it will be compatible with future (and previous ?) versions of GDB )

This is not likely to work.  Linux thread debugging uses a little bit
of the libthread_db but also knows a great deal about native OS
threads.  There is also some libthread_db code for Solaris, but it's
tied together with procfs support.  There is no generic libthread_db
layer.

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE : RE : User level threads debugging with GDB
  2010-04-09 13:43     ` Daniel Jacobowitz
@ 2010-04-09 13:54       ` PILLON Julien
  0 siblings, 0 replies; 5+ messages in thread
From: PILLON Julien @ 2010-04-09 13:54 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Paul Koning, gdb

Ok, I thought it was really full used...
So if I go on implementing libthread_db, I'll have to modify GDB also...
I think one day (...) I'll manage to understand the deeps of GDB... ^^
Thanks

Julien

________________________________________
De : Daniel Jacobowitz [dan@codesourcery.com]
Date d'envoi : vendredi 9 avril 2010 15:43
À : PILLON Julien
Cc : Paul Koning; gdb@sourceware.org
Objet : Re: RE : User level threads debugging with GDB

On Fri, Apr 09, 2010 at 03:04:28PM +0200, PILLON Julien wrote:
> Thank you for your answer.
> The fact is that I don't want to make big modification to GDB... So I think  I'll go on implementing a libthread_db (with this method, it will be compatible with future (and previous ?) versions of GDB )

This is not likely to work.  Linux thread debugging uses a little bit
of the libthread_db but also knows a great deal about native OS
threads.  There is also some libthread_db code for Solaris, but it's
tied together with procfs support.  There is no generic libthread_db
layer.

--
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-04-09 13:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-09  8:12 User level threads debugging with GDB PILLON Julien
2010-04-09 10:49 ` Paul Koning
2010-04-09 13:04   ` RE : " PILLON Julien
2010-04-09 13:43     ` Daniel Jacobowitz
2010-04-09 13:54       ` RE : " PILLON Julien

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox