Re: GDB support for thread-local storage

Re: GDB support for thread-local storage

[James Cownie]

> > But what is stopping us picking up that code, compiling it on the host 
> > (not target), and then using it in GDB?
> 
> Version skew primarily. 

Can you not choose the right version of libthread_db at runtime based
on the version of linuxthreads and dlopen it in gdb ?

Ideally there'd be some version information in the thread library code
which gdb could extract in a specified manner, and then a convention
about how that maps to a the name of a suitable .so version of
libthread_db.

This lets you

1) use libthread_db inside gdb on the host machine
2) keep gdb insulated from the version dependency on the thread
   library.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Tue, Jun 25, 2002 at 09:48:12AM +0100, James Cownie wrote:
> > > But what is stopping us picking up that code, compiling it on the host 
> > > (not target), and then using it in GDB?
> > 
> > Version skew primarily. 
> 
> Can you not choose the right version of libthread_db at runtime based
> on the version of linuxthreads and dlopen it in gdb ?
> 
> Ideally there'd be some version information in the thread library code
> which gdb could extract in a specified manner, and then a convention
> about how that maps to a the name of a suitable .so version of
> libthread_db.

But there isn't this version information.  We could probably detect the
glibc version number, but these are internal structures, not
interfaces; detecting when they have changed is quite hard.

> This lets you
> 
> 1) use libthread_db inside gdb on the host machine
> 2) keep gdb insulated from the version dependency on the thread
>    library.

Nope.  We'd have to be the ones writing such a thread_db; there is no
version that can run on the host machine at present.

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

Re: GDB support for thread-local storage

[James Cownie]

Daniel Jacobowitz wrote :-

> But there isn't this version information.  We could probably detect the
> glibc version number, but these are internal structures, not
> interfaces; detecting when they have changed is quite hard.

So, ask the thread library folks to provide a suitable versioning
symbol. As you rightly point out trying to guess the version is
unlikely to succeed !

> Nope.  We'd have to be the ones writing such a thread_db; there is no
> version that can run on the host machine at present.

However, having a version on the host had already been posited by
someone else. I didn't make that part of the proposal.

I'm merely suggesting a way around the version skew which you cited as
the primary problem.

Since libthread_db is always dlopened anyway, 

( http://sources.redhat.com/ml/libc-alpha/2000-06/msg00048.html )

it seems to me that you already need a good version symbol, or else
how can you handle programs which are using different versions on libc
and associated different versions of the threads library ?

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Tue, Jun 25, 2002 at 04:31:15PM +0100, James Cownie wrote:
> 
> Daniel Jacobowitz wrote :-
> 
> > But there isn't this version information.  We could probably detect the
> > glibc version number, but these are internal structures, not
> > interfaces; detecting when they have changed is quite hard.
> 
> So, ask the thread library folks to provide a suitable versioning
> symbol. As you rightly point out trying to guess the version is
> unlikely to succeed !

Anything that requires changes to the library isn't really viable; too
many libraries already exist.

> > Nope.  We'd have to be the ones writing such a thread_db; there is no
> > version that can run on the host machine at present.
> 
> However, having a version on the host had already been posited by
> someone else. I didn't make that part of the proposal.
> 
> I'm merely suggesting a way around the version skew which you cited as
> the primary problem.
> 
> Since libthread_db is always dlopened anyway, 
> 
> ( http://sources.redhat.com/ml/libc-alpha/2000-06/msg00048.html )
> 
> it seems to me that you already need a good version symbol, or else
> how can you handle programs which are using different versions on libc
> and associated different versions of the threads library ?

We can't.  It is always dlopened on the host when debugging natively
and on the target when debugging remotely, but that's it.

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

Re: GDB support for thread-local storage

[James Cownie]

> > So, ask the thread library folks to provide a suitable versioning
> > symbol. As you rightly point out trying to guess the version is
> > unlikely to succeed !
> 
> Anything that requires changes to the library isn't really viable; too
> many libraries already exist.

But that seems like an argument for packing up and going for a beer
which could be applied to _any_ improvement in anything associated
with libc :-)

The exact same argument could have been employed against introducing
libthread_db itself in the first place !

Surely one has to move forwards.

Adding a suitable version symbol can only help, it can't break
anything. If it's there the debugger can use it. If not you can keep
doing what you already do, and it seems you really need it even for
the normal native cases.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Tue, Jun 25, 2002 at 04:53:37PM +0100, James Cownie wrote:
> > > So, ask the thread library folks to provide a suitable versioning
> > > symbol. As you rightly point out trying to guess the version is
> > > unlikely to succeed !
> > 
> > Anything that requires changes to the library isn't really viable; too
> > many libraries already exist.
> 
> But that seems like an argument for packing up and going for a beer
> which could be applied to _any_ improvement in anything associated
> with libc :-)
> 
> The exact same argument could have been employed against introducing
> libthread_db itself in the first place !
> 
> Surely one has to move forwards.
> 
> Adding a suitable version symbol can only help, it can't break
> anything. If it's there the debugger can use it. If not you can keep
> doing what you already do, and it seems you really need it even for
> the normal native cases.

You'll never get them to document interface changes in pthreads'
internal data structures.  You're welcome to try if you like pain more
than I do.  The only layer the glibc folks support for accessing this
data is thread_db.

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

Re: GDB support for thread-local storage

[James Cownie]

> You'll never get them to document interface changes in pthreads'
> internal data structures.  You're welcome to try if you like pain
> more than I do.  The only layer the glibc folks support for
> accessing this data is thread_db.

I'm not sugggesting that they document it, rather that they provide a
version symbol which tells you which version of the pthreads code you
have, and then name libthread_db with a name which includes the
version number.

All I'm after is that one can tell from a debugger which version of
the pthread library one is looking at and then deduce which
libthread_db.so to dlopen.

Something as trivial as

static volatile int __pthread_version_number = 123;

somwehere would probably do. 

The documentation requirement would be

  The static symbol __pthread_version_number gives the version number
 of the pthread library to allow a debugger to locate the appropriate
 version of libthread_db.

and that's it. It doesn't change...

Thought they need to remember to change the version number when they
make changes which affect libthread_db.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Tue, Jun 25, 2002 at 05:11:39PM +0100, James Cownie wrote:
> 
> > You'll never get them to document interface changes in pthreads'
> > internal data structures.  You're welcome to try if you like pain
> > more than I do.  The only layer the glibc folks support for
> > accessing this data is thread_db.
> 
> I'm not sugggesting that they document it, rather that they provide a
> version symbol which tells you which version of the pthreads code you
> have, and then name libthread_db with a name which includes the
> version number.
> 
> All I'm after is that one can tell from a debugger which version of
> the pthread library one is looking at and then deduce which
> libthread_db.so to dlopen.
> 
> Something as trivial as
> 
> static volatile int __pthread_version_number = 123;
> 
> somwehere would probably do. 
> 
> The documentation requirement would be
> 
>   The static symbol __pthread_version_number gives the version number
>  of the pthread library to allow a debugger to locate the appropriate
>  version of libthread_db.
> 
> and that's it. It doesn't change...
> 
> Thought they need to remember to change the version number when they
> make changes which affect libthread_db.

That's what I meant by document.  If you look at libthread_db, you'll
see that it includes the internal header which describes the layout of
a thread descriptor.  Changes to that structure are not counted and I
don't think they'll like the idea.  They're also hard to identify,
since it draws types from other headers.

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

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Tue, Jun 25, 2002 at 12:18:34PM -0400, Andrew Cagney wrote:
> >Adding a suitable version symbol can only help, it can't break
> >>anything. If it's there the debugger can use it. If not you can keep
> >>doing what you already do, and it seems you really need it even for
> >>the normal native cases.
> >
> >
> >You'll never get them to document interface changes in pthreads'
> >internal data structures.  You're welcome to try if you like pain more
> >than I do.  The only layer the glibc folks support for accessing this
> >data is thread_db.
> 
> Does the current thread-db code at least sanity check version match 
> internally?

I don't believe it has any mechanism for this, no.

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

Re: GDB support for thread-local storage

[Andrew Cagney]

> Adding a suitable version symbol can only help, it can't break
>> anything. If it's there the debugger can use it. If not you can keep
>> doing what you already do, and it seems you really need it even for
>> the normal native cases.
> 
> 
> You'll never get them to document interface changes in pthreads'
> internal data structures.  You're welcome to try if you like pain more
> than I do.  The only layer the glibc folks support for accessing this
> data is thread_db.

Does the current thread-db code at least sanity check version match 
internally?

Andrew

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Tue, Jun 25, 2002 at 12:18:34PM -0400, Andrew Cagney wrote:
> > >Adding a suitable version symbol can only help, it can't break
> > >>anything. If it's there the debugger can use it. If not you can keep
> > >>doing what you already do, and it seems you really need it even for
> > >>the normal native cases.
> > >
> > >
> > >You'll never get them to document interface changes in pthreads'
> > >internal data structures.  You're welcome to try if you like pain more
> > >than I do.  The only layer the glibc folks support for accessing this
> > >data is thread_db.
> > 
> > Does the current thread-db code at least sanity check version match 
> > internally?
> 
> I don't believe it has any mechanism for this, no.

Doesn't libthread_db read `struct _pthread_descr_struct' from the
linuxthreads library in the inferior, rather than knowing the layout
itself?  So it's actually the inferior's linuxthreads library that
describes its own structures' layout.

It's got *some* defense against version skew.

Re: GDB support for thread-local storage

[Andrew Cagney]

> Daniel Jacobowitz <drow@mvista.com> writes:
> 
>> On Tue, Jun 25, 2002 at 12:18:34PM -0400, Andrew Cagney wrote:
> 
>> > >Adding a suitable version symbol can only help, it can't break
> 
>> > >>anything. If it's there the debugger can use it. If not you can keep
>> > >>doing what you already do, and it seems you really need it even for
>> > >>the normal native cases.
> 
>> > >
>> > >
>> > >You'll never get them to document interface changes in pthreads'
>> > >internal data structures.  You're welcome to try if you like pain more
>> > >than I do.  The only layer the glibc folks support for accessing this
>> > >data is thread_db.
> 
>> > 
>> > Does the current thread-db code at least sanity check version match 
>> > internally?
> 
>> 
>> I don't believe it has any mechanism for this, no.
> 
> 
> Doesn't libthread_db read `struct _pthread_descr_struct' from the
> linuxthreads library in the inferior, rather than knowing the layout
> itself?  So it's actually the inferior's linuxthreads library that
> describes its own structures' layout.

The structure layout will have been compiled into libthread-db.a.  It 
implicitly knows the layout itself.

> It's got *some* defense against version skew.

To defend against version skew, libthread-db needs to check that its 
internals are consistent with the target.  A simple variable value check 
was mentioned.

Andrew

Re: GDB support for thread-local storage

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > Doesn't libthread_db read `struct _pthread_descr_struct' from the
> > linuxthreads library in the inferior, rather than knowing the layout
> > itself?  So it's actually the inferior's linuxthreads library that
> > describes its own structures' layout.
> 
> The structure layout will have been compiled into libthread-db.a.  It
> implicitly knows the layout itself.

I think you're wrong here.  Could you show me the code?

(Not that the question is especially relevant to the discussion --- of
course it could do a simple checksum check.)

Re: GDB support for thread-local storage

[Andrew Cagney]

> Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
>> > Doesn't libthread_db read `struct _pthread_descr_struct' from the
>> > linuxthreads library in the inferior, rather than knowing the layout
>> > itself?  So it's actually the inferior's linuxthreads library that
>> > describes its own structures' layout.
> 
>> 
>> The structure layout will have been compiled into libthread-db.a.  It
>> implicitly knows the layout itself.
> 
> 
> I think you're wrong here.  Could you show me the code?

Sorry, you've lost me.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/descr.h?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=glibc
> struct _pthread_descr_struct {
>   /* XXX Remove this union for IA-64 style TLS module */
>   union {
>     struct {
>       void *tcb;                /* Pointer to the TCB.  This is not always
>                                    the address of this thread descriptor.  */
>       union dtv *dtvp;
>       pthread_descr self;       /* Pointer to this structure */
>     } data;
>     void *__padding[16];
>   } p_header;
>   pthread_descr p_nextlive, p_prevlive;
>                                 /* Double chaining of active threads */
>   pthread_descr p_nextwaiting;  /* Next element in the queue holding the thr */
>   pthread_descr p_nextlock;     /* can be on a queue and waiting on a lock */
>   pthread_t p_tid;              /* Thread identifier */
>   int p_pid;                    /* PID of Unix process */

Note the use of ISA/ABI dependant data types such as ``int'', ``void 
*'', ...  As such they are implicitly included in and compiled into 
libhread-db.a

enjoy,
Andrew

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Wed, Jun 26, 2002 at 11:56:58PM -0500, Jim Blandy wrote:
> 
> Andrew Cagney <ac131313@ges.redhat.com> writes:
> > > Doesn't libthread_db read `struct _pthread_descr_struct' from the
> > > linuxthreads library in the inferior, rather than knowing the layout
> > > itself?  So it's actually the inferior's linuxthreads library that
> > > describes its own structures' layout.
> > 
> > The structure layout will have been compiled into libthread-db.a.  It
> > implicitly knows the layout itself.
> 
> I think you're wrong here.  Could you show me the code?
> 
> (Not that the question is especially relevant to the discussion --- of
> course it could do a simple checksum check.)

You're right, and you're wrong.  For instance, td_ta_map_id2thr.c:

#include <linuxthreads/internals.h>
  struct pthread_handle_struct phc;
  if (ps_pdread (ta->ph, ta->handles + pt % pthread_threads_max, &phc,
                 sizeof (struct pthread_handle_struct)) != PS_OK)
  if (phc.h_descr == NULL)

etc.

which references:
struct pthread_handle_struct {
  struct _pthread_fastlock h_lock; /* Fast lock for sychronized access */
  pthread_descr h_descr;        /* Thread descriptor or NULL if invalid */
  char * h_bottom;              /* Lowest address in the stack thread */
};


Worse, it reads the _pthread_descr_struct from the inferior. 
_pthread_descr_struct does not describe the layout of anything; it's
the actual descriptor.  It has things like a sigjmp_buf in it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[maint] The GDB maintenance process

[Daniel Jacobowitz]

I get the feeling I'm already pretty unpopular for some of my opinions on
how GDB maintenane should work.  This isn't going to make it any better, but
I feel it should be said.

I believe that our current process has some problems.  Let me try to
explain.  First, to make sure we're all on the same page...

 What does it mean to be a Global Maintainer, in practice?
  - A certain amount of autonomy in the areas of GDB that no one wants to
    take specific responsibility for.  There's no specific maintainer for
    things like the frame support or the type/value systems.
  - A little more freedom in approving patches to other people's areas of
    GDB - not a lot, but it's definitely there.
    [In practice, this depends on:
     o How much risk you're willing to take of annoying people.
     o How likely other maintainers are to shout at you about it.]
  - Authority to approve patches covering general debugger issues.

 What does it mean to be a maintainer for a specific host/target/subsystem,
 in practice?
  - The authority to approve patches and apply your own patches to that area
    of the debugger.

I'd like everyone to notice one thing missing from the above list.  No one
has the _responsibility_ for approving patches.  This is a volunteer
project, and anyone who's watched it in action for a little while will see
that the volunteers are often busy and distracted.  There's no one who
can handle or should have to handle the responsibilities of patch approval.

Another thing to think about: because of the layout of the above, there is
frequently no one who has the _right_ to approve a patch.  They require
buy-in from a number of additional maintainers.  In addition our volunteers
are often too busy to find time to respond to patches.  This impacts patches
from other maintainers (frequently, but generally a small impact) and from
outside contributors (happens less frequently, but larger impact - most of
these never get approved at all, from what I've seen).


Some other GNU projects have a similar setup and don't have this problem. 
GCC and binutils are my usual examples.  How do they avoid it?  They have a
different definition of global maintainer.  That's what ours used to be
called - Blanket Write Privileges.  The system works a little differently:
  - Maintainers for specific areas of the compiler can commit/approve
    patches to the areas they maintain without buy-in from a blanket
    maintainer.
  - Blanket maintainers can commit/approve patches anywhere without buy-in
    from a specific area maintainer.

[I hope Richard will forgive me for using him as an example and for putting
words in his mouth...] This doesn't replace common sense - you generally
won't find Richard Henderson approving patches to the C++ frontend, because:
  - He knows he isn't familiar with it
  - He knows it has an active set of maintainers at all times

Similarly, just because he can check in patches to any target backend, that
doesn't mean he won't ask a target maintainer to look over it first.  If
someone objects to a patch in their area, he would generally not just check
it in anyway.  If they object to it after he checks it in, the two will
discuss the problem like reasonable people and come to some agreement.


Some noticeable differences between these two models:
  - In the GCC model, more people are able/likely to check in patches which
    break things.
  - But in the GCC model, more people are able/likely to check in patches to
    fix it afterwards.
  - Because more people have the privilege of approving a given patch,
    and fewer people's approvals are needed for any particular patch,
    patches (usually) get approved more quickly.
  - Development can happen more quickly, and does not get slowed to a
    standstill when (say) one of us is pulled off of community GDB work for
    an urgent customer project.  This happens all the time - I've never seen
    all the GDB maintainers with time for GDB at the same time.


Right now, we use stricter policies to prevent problems which cause
breakage.  I think these policies are stifling us.  Loosening them (and
maybe adding a formal patch reversion policy) would let more people fix
problems more easily, as they arise, without slowing development.

If there are people on our Global Maintainer list that we don't think should
be trusted with the extra responsibility of the above, then perhaps we need
to rethink who belongs in that list.  I'm not pointing any fingers - I don't
have anyone in mind, and I've been quite happy working with absolutely all
of the current team.  Just putting the idea out.


I've discussed this general situation with a (small) sampling of other GDB
developers and contributors - enough to know that I'm not alone in my
concerns.  These aren't entirely my own words, either.  I'll let other
people take credit/blame for them if they want to, and if I've represented
their opinions accurately.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [maint] The GDB maintenance process

[Kevin Buettner]

On Feb 17,  1:07pm, Daniel Jacobowitz wrote:

> Right now, we use stricter policies to prevent problems which cause
> breakage.  I think these policies are stifling us.  Loosening them (and
> maybe adding a formal patch reversion policy) would let more people fix
> problems more easily, as they arise, without slowing development.

I agree.

Kevin

Re: [maint] The GDB maintenance process

[Elena Zannoni]

Daniel Jacobowitz writes:
 > I get the feeling I'm already pretty unpopular for some of my opinions on
 > how GDB maintenane should work.  This isn't going to make it any better, but
 > I feel it should be said.
 > 

OK, I'll take the bait. No offense intended. Just read until the end.

 > I believe that our current process has some problems.  Let me try to
 > explain.  First, to make sure we're all on the same page...
 > 
 >  What does it mean to be a Global Maintainer, in practice?
 >   - A certain amount of autonomy in the areas of GDB that no one wants to
 >     take specific responsibility for.  There's no specific maintainer for
 >     things like the frame support or the type/value systems.
 >   - A little more freedom in approving patches to other people's areas of
 >     GDB - not a lot, but it's definitely there.
 >     [In practice, this depends on:
 >      o How much risk you're willing to take of annoying people.
 >      o How likely other maintainers are to shout at you about it.]

The above point is not part of the global maintainer description. I
take you want it to be? I don't agree. It just makes it possible for
particularly 'active' individuals to dominate the list and removes
the more egalitarian feel that this community has. You can say that
the linux kernel community is like that, and that gcc is like that,
etc, but we don't have to be. 

I have seen sometimes very quick turnarounds on patches during
holidays, and maybe some of such patches should have been thought
through more carefully. If you don't give time to the appropriate
maintainers to chime in, the entropy can become way too high, with
patches, and reverted patches going around.

 >   - Authority to approve patches covering general debugger issues.
 > 
 >  What does it mean to be a maintainer for a specific host/target/subsystem,
 >  in practice?
 >   - The authority to approve patches and apply your own patches to that area
 >     of the debugger.
 > 
 > I'd like everyone to notice one thing missing from the above list.  No one
 > has the _responsibility_ for approving patches.  This is a volunteer
 > project, and anyone who's watched it in action for a little while will see
 > that the volunteers are often busy and distracted.  There's no one who
 > can handle or should have to handle the responsibilities of patch approval.
 > 

So, you are proposing that we let the vacuum be filled with heroics?
I.e. quantity vs quality.

 > Another thing to think about: because of the layout of the above, there is
 > frequently no one who has the _right_ to approve a patch.  They require
 > buy-in from a number of additional maintainers.  In addition our volunteers
 > are often too busy to find time to respond to patches.  This impacts patches
 > from other maintainers (frequently, but generally a small impact) and from
 > outside contributors (happens less frequently, but larger impact - most of
 > these never get approved at all, from what I've seen).
 > 

Wait, lots of external contributor's patches never make it in because
of the copyright assignment problems. Also I see external people
dropping patches, not because the are not reviewed, but because they
*are reviewed*. I.e. a patch is submitted, I ask for some changes, and
the person never comes back with a new patch.

There would be also something to say about championing your patches,
ie, push a bit. For instance this is what David is doing with the
namespaces stuff, he is keeping me posted, and he makes sure I don't
fall asleep at the wheel. 

Just saying, things are not as black and white as they are portraited.

 > 
 > Some other GNU projects have a similar setup and don't have this problem. 
 > GCC and binutils are my usual examples.  How do they avoid it?  They have a
 > different definition of global maintainer.  That's what ours used to be
 > called - Blanket Write Privileges.  The system works a little differently:
 >   - Maintainers for specific areas of the compiler can commit/approve
 >     patches to the areas they maintain without buy-in from a blanket
 >     maintainer.

I think you are misunderstanding. Gdb is like that. If one maintains
one area, that's it, period. His/her approval is enough. Even if the
maintainer is not global, the authority is the same *in that specific
area*.

 >   - Blanket maintainers can commit/approve patches anywhere without buy-in
 >     from a specific area maintainer.
 > 
 > [I hope Richard will forgive me for using him as an example and for putting
 > words in his mouth...] This doesn't replace common sense - you generally
 > won't find Richard Henderson approving patches to the C++ frontend, because:
 >   - He knows he isn't familiar with it
 >   - He knows it has an active set of maintainers at all times
 > 
 > Similarly, just because he can check in patches to any target backend, that
 > doesn't mean he won't ask a target maintainer to look over it first.  If
 > someone objects to a patch in their area, he would generally not just check
 > it in anyway.  If they object to it after he checks it in, the two will
 > discuss the problem like reasonable people and come to some agreement.
 > 
 > 
 > Some noticeable differences between these two models:
 >   - In the GCC model, more people are able/likely to check in patches which
 >     break things.
 >   - But in the GCC model, more people are able/likely to check in patches to
 >     fix it afterwards.
 >   - Because more people have the privilege of approving a given patch,
 >     and fewer people's approvals are needed for any particular patch,
 >     patches (usually) get approved more quickly.
 >   - Development can happen more quickly, and does not get slowed to a
 >     standstill when (say) one of us is pulled off of community GDB work for
 >     an urgent customer project.  This happens all the time - I've never seen
 >     all the GDB maintainers with time for GDB at the same time.
 > 

Yes, we have day jobs, that are not 'work on FSF gdb'. If you loosen
the rules, then it becomes possible for a small, fully funded, elite to
take control.  

And how long would you wait before stepping in? That's a hard problem.
1 hour, one day, one working day, one week? 

 > 
 > Right now, we use stricter policies to prevent problems which cause
 > breakage.  I think these policies are stifling us.  Loosening them (and
 > maybe adding a formal patch reversion policy) would let more people fix
 > problems more easily, as they arise, without slowing development.
 > 

I really think that having the bug database track patches is a very
big improvement. We should try to push its use a bit more before
giving up on the current rules. 

 > If there are people on our Global Maintainer list that we don't think should
 > be trusted with the extra responsibility of the above, then perhaps we need
 > to rethink who belongs in that list.  I'm not pointing any fingers - I don't
 > have anyone in mind, and I've been quite happy working with absolutely all
 > of the current team.  Just putting the idea out.
 > 
 > 
 > I've discussed this general situation with a (small) sampling of other GDB
 > developers and contributors - enough to know that I'm not alone in my
 > concerns.  These aren't entirely my own words, either.  I'll let other
 > people take credit/blame for them if they want to, and if I've represented
 > their opinions accurately.

Hmm, I am not too happy with this behind the scenes discontent, if
there is something wrong, let's hear it.

Ok, that said, I too am seeing patches that are not reviewed. So there
are wrinkles in the process. But I don't think that the 'let's take
over' approach is an appropriate solution.

elena


 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> I've discussed this general situation with a (small) sampling of other GDB
> developers and contributors - enough to know that I'm not alone in my
> concerns.  These aren't entirely my own words, either.  I'll let other
> people take credit/blame for them if they want to, and if I've represented
> their opinions accurately.

I recall you rasing this previously with me but I don't recall
agreeing with your opinions (my concerns run along similar lines to
what Elena posted).

Normally political issues get discussed with the global maintainers
(so that the mailing lists can focus on technical discussion).
However, if you feel that it is better discussed here, then so be it.

enjoy,
Andrew

Re: [maint] The GDB maintenance process

[Andrew Cagney]

>  What does it mean to be a Global Maintainer, in practice?
>   - A certain amount of autonomy in the areas of GDB that no one wants to
>     take specific responsibility for.  There's no specific maintainer for
>     things like the frame support or the type/value systems.
>   - A little more freedom in approving patches to other people's areas of
>     GDB - not a lot, but it's definitely there.
>     [In practice, this depends on:
>      o How much risk you're willing to take of annoying people.
>      o How likely other maintainers are to shout at you about it.]
>   - Authority to approve patches covering general debugger issues.
> 
>  What does it mean to be a maintainer for a specific host/target/subsystem,
>  in practice?
>   - The authority to approve patches and apply your own patches to that area
>     of the debugger.
> 
> I'd like everyone to notice one thing missing from the above list.  No one
> has the _responsibility_ for approving patches.  This is a volunteer
> project, and anyone who's watched it in action for a little while will see
> that the volunteers are often busy and distracted.  There's no one who
> can handle or should have to handle the responsibilities of patch approval.

This isn't correct.  The MAINTAINERS file reads:

                        Various Maintainers

  Note individuals who maintain parts of the debugger need approval to
  check in changes outside of the immediate domain that they maintain.

  If there is no maintainer for a given domain then the responsibility
  falls to a global maintainer.

  If there are several maintainers for a given domain then
  responsibility falls to the first maintainer.  The first maintainer is
  free to devolve that responsibility among the other maintainers.

so it makes definite references to `responsibility'.  Put simply, `the
buck stops'.  Perhaps you should ask a different question `is the buck
ignored?' and what should be done if/when it is.

Even though GDB is developed by volunteers, it is entirely reasonable
to expect the volunteers to take their duties seriously.  Monitoring
the bug data base; approving patches; where helpful, contributing to
discussions.  Now that I typically file patches into the bug database,
this should be much easier.

However, what is unreasonable is to place un-realistic expectations on
the said maintainers.  The assumption that a volunteer is working 24x7
and living in north america isn't, for instance, reasonable.  A
significant number of GDB maintainers have real jobs and real
timezones.

> Some other GNU projects have a similar setup and don't have this problem. 
> GCC and binutils are my usual examples.  How do they avoid it?  They have a
> different definition of global maintainer.  That's what ours used to be
> called - Blanket Write Privileges.  The system works a little differently:
>   - Maintainers for specific areas of the compiler can commit/approve
>     patches to the areas they maintain without buy-in from a blanket
>     maintainer.
>   - Blanket maintainers can commit/approve patches anywhere without buy-in
>     from a specific area maintainer.

`write' was a simple typo.  From the outset (i.e., from when I got
handed this job) it was made very clear that neither I, nor any other
global maintainer, could override the decision of a specific
maintainer.

This was, and still is, very important.  It ensures that the area has
a certain level of continuity, and it ensures that I (or another
global maintainer) doesn't ride gunshot over a specific maintainer.

> [I hope Richard will forgive me for using him as an example and for putting
> words in his mouth...] This doesn't replace common sense - you generally
> won't find Richard Henderson approving patches to the C++ frontend, because:
>   - He knows he isn't familiar with it
>   - He knows it has an active set of maintainers at all times
> 
> Similarly, just because he can check in patches to any target backend, that
> doesn't mean he won't ask a target maintainer to look over it first.  If
> someone objects to a patch in their area, he would generally not just check
> it in anyway.  If they object to it after he checks it in, the two will
> discuss the problem like reasonable people and come to some agreement.

The interaction dynamics of a committed patch are very different to
those of an unapproved patch.  Once a patch is committed, the person
with objections is, unequestionably, put in the back seat.

> Some noticeable differences between these two models:
>   - In the GCC model, more people are able/likely to check in patches which
>     break things.
>   - But in the GCC model, more people are able/likely to check in patches to
>     fix it afterwards.

(ROFL.)

The GCC model involves a number of development phases and the above
comments would only relate to one of those phases.  At other times
increasingly strict controls are placed on what can be
committed/approved.  The GCC group spend a significant (out of
control?)  amount of their time trying to re-stablize GCC for their
releases.

For GDB, on the other hand, interesting development can and does get
approved/committed at any time.  GDB snaps are of such quality that we
can confidently refer someone to current sources for fixes (except
when I have a bad day like today :-).  Further, instead of using
official releases (and as you yourself have done) arbitrary snaps can
even make their way into a distro.

>   - Because more people have the privilege of approving a given patch,
>     and fewer people's approvals are needed for any particular patch,
>     patches (usually) get approved more quickly.
>   - Development can happen more quickly, and does not get slowed to a
>     standstill when (say) one of us is pulled off of community GDB work for
>     an urgent customer project.  This happens all the time - I've never seen
>     all the GDB maintainers with time for GDB at the same time.

The only way I've got my patches into GCC is by acting as a champion
for their cause.  Exactly like Elena described.  Having worked on
other open source projects I'd have to conclude the same also applied
to them.

Sounds like it really is time to drag out "aegis".

Andrew

Re: [maint] The GDB maintenance process

[Daniel Jacobowitz]

Thanks to everyone who responded; I'll try to address everything.

I want to share a piece of perspective on why I raise this issue now. 
I'm finding the GDB development process to be too slow to be workable -
patches take a month or more routinely, and I don't have the time to
juggle them for that long.  I'm facing that I may need to back down my
level of involvement as a consequence of how awkward the development
model is for getting any forward progress.

Maybe that means that I just don't have the time and the patience to be
a useful contributor to GDB.  Me, I think that it means that we need to
make the process less painful for contributors.

On Mon, Feb 17, 2003 at 09:35:53PM -0500, Andrew Cagney wrote:
> > I've discussed this general situation with a (small) sampling of other GDB
> > developers and contributors - enough to know that I'm not alone in my
> > concerns.  These aren't entirely my own words, either.  I'll let other
> > people take credit/blame for them if they want to, and if I've represented
> > their opinions accurately.
> 
> I recall you rasing this previously with me but I don't recall
> agreeing with your opinions (my concerns run along similar lines to
> what Elena posted).

Hmm, I don't remember actually discussing this with you before.  Must
be going soft.  We've certainly butted heads over related topics.

> Normally political issues get discussed with the global maintainers
> (so that the mailing lists can focus on technical discussion).
> However, if you feel that it is better discussed here, then so be it.

If you feel that's more appropriate, just say so.  I've no particular
preference for where the conversation happens, as long as it happens.



On Mon, Feb 17, 2003 at 04:05:40PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > I get the feeling I'm already pretty unpopular for some of my opinions on
>  > how GDB maintenane should work.  This isn't going to make it any better, but
>  > I feel it should be said.
>  > 
> 
> OK, I'll take the bait. No offense intended. Just read until the end.
> 
>  > I believe that our current process has some problems.  Let me try to
>  > explain.  First, to make sure we're all on the same page...
>  > 
>  >  What does it mean to be a Global Maintainer, in practice?
>  >   - A certain amount of autonomy in the areas of GDB that no one wants to
>  >     take specific responsibility for.  There's no specific maintainer for
>  >     things like the frame support or the type/value systems.
>  >   - A little more freedom in approving patches to other people's areas of
>  >     GDB - not a lot, but it's definitely there.
>  >     [In practice, this depends on:
>  >      o How much risk you're willing to take of annoying people.
>  >      o How likely other maintainers are to shout at you about it.]
> 
> The above point is not part of the global maintainer description. I
> take you want it to be? I don't agree. It just makes it possible for
> particularly 'active' individuals to dominate the list and removes
> the more egalitarian feel that this community has. You can say that
> the linux kernel community is like that, and that gcc is like that,
> etc, but we don't have to be. 

I don't especially want it to be; I want something different, farther
down.  This is my vision of how we work right now.  The above is
informal but in my experience a pretty accurate summary of the way
things really are.

> I have seen sometimes very quick turnarounds on patches during
> holidays, and maybe some of such patches should have been thought
> through more carefully. If you don't give time to the appropriate
> maintainers to chime in, the entropy can become way too high, with
> patches, and reverted patches going around.

I guess I just don't see this to be as much of a problem as others do.
For one thing, with the higher entropy level, more development actually
happens.

>  > Another thing to think about: because of the layout of the above, there is
>  > frequently no one who has the _right_ to approve a patch.  They require
>  > buy-in from a number of additional maintainers.  In addition our volunteers
>  > are often too busy to find time to respond to patches.  This impacts patches
>  > from other maintainers (frequently, but generally a small impact) and from
>  > outside contributors (happens less frequently, but larger impact - most of
>  > these never get approved at all, from what I've seen).
>  > 
> 
> Wait, lots of external contributor's patches never make it in because
> of the copyright assignment problems. Also I see external people
> dropping patches, not because the are not reviewed, but because they
> *are reviewed*. I.e. a patch is submitted, I ask for some changes, and
> the person never comes back with a new patch.
> 
> There would be also something to say about championing your patches,
> ie, push a bit. For instance this is what David is doing with the
> namespaces stuff, he is keeping me posted, and he makes sure I don't
> fall asleep at the wheel. 
> 
> Just saying, things are not as black and white as they are portraited.

Sure.  But my portrayal isn't entirely inaccurate, either.  One example
- inter-compilation-unit references in DWARF-2.  It's been posted at
least twice, by different contributors.  When asked for changes,
they've come back with changes.  It's still not supported, over a year
later.

On the subject of David, infinite kudos to him for his
single-mindedness and patience.  When I look at the amount of forward
progress he's made compared to the time he's invested in making it, I
become even more convinced that we have a problem.

>  > Some other GNU projects have a similar setup and don't have this problem. 
>  > GCC and binutils are my usual examples.  How do they avoid it?  They have a
>  > different definition of global maintainer.  That's what ours used to be
>  > called - Blanket Write Privileges.  The system works a little differently:
>  >   - Maintainers for specific areas of the compiler can commit/approve
>  >     patches to the areas they maintain without buy-in from a blanket
>  >     maintainer.
> 
> I think you are misunderstanding. Gdb is like that. If one maintains
> one area, that's it, period. His/her approval is enough. Even if the
> maintainer is not global, the authority is the same *in that specific
> area*.

I know that.  That's no different between GCC and GDB; I'm not
discussing a radical 100% turnaround here.

>  >   - Blanket maintainers can commit/approve patches anywhere without buy-in
>  >     from a specific area maintainer.
>  > 
>  > [I hope Richard will forgive me for using him as an example and for putting
>  > words in his mouth...] This doesn't replace common sense - you generally
>  > won't find Richard Henderson approving patches to the C++ frontend, because:
>  >   - He knows he isn't familiar with it
>  >   - He knows it has an active set of maintainers at all times
>  > 
>  > Similarly, just because he can check in patches to any target backend, that
>  > doesn't mean he won't ask a target maintainer to look over it first.  If
>  > someone objects to a patch in their area, he would generally not just check
>  > it in anyway.  If they object to it after he checks it in, the two will
>  > discuss the problem like reasonable people and come to some agreement.
>  > 
>  > 
>  > Some noticeable differences between these two models:
>  >   - In the GCC model, more people are able/likely to check in patches which
>  >     break things.
>  >   - But in the GCC model, more people are able/likely to check in patches to
>  >     fix it afterwards.
>  >   - Because more people have the privilege of approving a given patch,
>  >     and fewer people's approvals are needed for any particular patch,
>  >     patches (usually) get approved more quickly.
>  >   - Development can happen more quickly, and does not get slowed to a
>  >     standstill when (say) one of us is pulled off of community GDB work for
>  >     an urgent customer project.  This happens all the time - I've never seen
>  >     all the GDB maintainers with time for GDB at the same time.
>  > 
> 
> Yes, we have day jobs, that are not 'work on FSF gdb'. If you loosen
> the rules, then it becomes possible for a small, fully funded, elite to
> take control.  
> 
> And how long would you wait before stepping in? That's a hard problem.
> 1 hour, one day, one working day, one week? 

Are we talking about the same thing?  I don't think I understand you.

First of all, the idea of a small, fully funded elite taking control of
the project doesn't make any sense to me.  Either their changes are
worthwhile - the existing maintainers will cooperate with them - or
they overstep their boundaries - they are asked to cease.  We don't
hand out maintainership to all comers.

It's not about control of GDB, it's about the growth and quality of
GDB!  I don't care who controls it.  I'll mostly resist making a
comment here about who currently controls GDB - more than half the
global maintainers work at the same place - because it's an entirely
benign and open control.

Second, what do you mean by "step in"?  Step in in response to what?  A
broken patch?  A violation of authority?  The latter and partly the
former are what GCC has a formal steering committee for.  We could do
the same thing, or use a vote of the global maintainers.  In practice
it's rarely necessary.

>  > Right now, we use stricter policies to prevent problems which cause
>  > breakage.  I think these policies are stifling us.  Loosening them (and
>  > maybe adding a formal patch reversion policy) would let more people fix
>  > problems more easily, as they arise, without slowing development.
>  > 
> 
> I really think that having the bug database track patches is a very
> big improvement. We should try to push its use a bit more before
> giving up on the current rules. 

I don't like it, but that's just my general anti-GNATS rancor.  Maybe
Bugzilla will be better.

>  > If there are people on our Global Maintainer list that we don't think should
>  > be trusted with the extra responsibility of the above, then perhaps we need
>  > to rethink who belongs in that list.  I'm not pointing any fingers - I don't
>  > have anyone in mind, and I've been quite happy working with absolutely all
>  > of the current team.  Just putting the idea out.
>  > 
>  > 
>  > I've discussed this general situation with a (small) sampling of other GDB
>  > developers and contributors - enough to know that I'm not alone in my
>  > concerns.  These aren't entirely my own words, either.  I'll let other
>  > people take credit/blame for them if they want to, and if I've represented
>  > their opinions accurately.
> 
> Hmm, I am not too happy with this behind the scenes discontent, if
> there is something wrong, let's hear it.

That's what I'm doing!  I assure you, I don't enjoy generating this
much rancor.

On Mon, Feb 17, 2003 at 11:28:46PM -0500, Andrew Cagney wrote:
> 
> >  What does it mean to be a Global Maintainer, in practice?
> >   - A certain amount of autonomy in the areas of GDB that no one wants to
> >     take specific responsibility for.  There's no specific maintainer for
> >     things like the frame support or the type/value systems.
> >   - A little more freedom in approving patches to other people's areas of
> >     GDB - not a lot, but it's definitely there.
> >     [In practice, this depends on:
> >      o How much risk you're willing to take of annoying people.
> >      o How likely other maintainers are to shout at you about it.]
> >   - Authority to approve patches covering general debugger issues.
> > 
> >  What does it mean to be a maintainer for a specific host/target/subsystem,
> >  in practice?
> >   - The authority to approve patches and apply your own patches to that area
> >     of the debugger.
> > 
> > I'd like everyone to notice one thing missing from the above list.  No one
> > has the _responsibility_ for approving patches.  This is a volunteer
> > project, and anyone who's watched it in action for a little while will see
> > that the volunteers are often busy and distracted.  There's no one who
> > can handle or should have to handle the responsibilities of patch approval.
> 
> This isn't correct.  The MAINTAINERS file reads:
> 
>                         Various Maintainers
> 
>   Note individuals who maintain parts of the debugger need approval to
>   check in changes outside of the immediate domain that they maintain.
> 
>   If there is no maintainer for a given domain then the responsibility
>   falls to a global maintainer.
> 
>   If there are several maintainers for a given domain then
>   responsibility falls to the first maintainer.  The first maintainer is
>   free to devolve that responsibility among the other maintainers.
> 
> so it makes definite references to `responsibility'.  Put simply, `the
> buck stops'.  Perhaps you should ask a different question `is the buck
> ignored?' and what should be done if/when it is.
> 
> Even though GDB is developed by volunteers, it is entirely reasonable
> to expect the volunteers to take their duties seriously.  Monitoring
> the bug data base; approving patches; where helpful, contributing to
> discussions.  Now that I typically file patches into the bug database,
> this should be much easier.
> 
> However, what is unreasonable is to place un-realistic expectations on
> the said maintainers.  The assumption that a volunteer is working 24x7
> and living in north america isn't, for instance, reasonable.  A
> significant number of GDB maintainers have real jobs and real
> timezones.

[North America doesn't have real jobs and real timezones?  They're just
different...]  OK, I withdraw my comment about no one having
responsibility.  Let me try from another side.

The volunteers do take their duty seriously, but with the density of
responsibility involved [i.e., when a particular person or people are
responsible for a decision, there tend to be just one or two of them]
it's very hard to make forward progress when people are busy.  And
we're all busy people.  Significant patches almost always take three
weeks or more if they can't be approved by their author; some take
months, even with repeated prodding.

We don't just have a bottleneck, we have a bottleneck per maintainer.

> > Some other GNU projects have a similar setup and don't have this problem. 
> > GCC and binutils are my usual examples.  How do they avoid it?  They have a
> > different definition of global maintainer.  That's what ours used to be
> > called - Blanket Write Privileges.  The system works a little differently:
> >   - Maintainers for specific areas of the compiler can commit/approve
> >     patches to the areas they maintain without buy-in from a blanket
> >     maintainer.
> >   - Blanket maintainers can commit/approve patches anywhere without buy-in
> >     from a specific area maintainer.
> 
> `write' was a simple typo.  From the outset (i.e., from when I got
> handed this job) it was made very clear that neither I, nor any other
> global maintainer, could override the decision of a specific
> maintainer.
> 
> This was, and still is, very important.  It ensures that the area has
> a certain level of continuity, and it ensures that I (or another
> global maintainer) doesn't ride gunshot over a specific maintainer.

Which raises two thoughts in my mind.
 - What are the benefits of this continuity, and do they really
outweigh the disadvantages (slow progress, primarily)?  My position is
that they do _not_.
 - Why do we need rules to prevent global maintainers riding gunshot
over area maintainers?  If people are willing (AND ABLE - people's
circumstances, however regrettable, aren't relevant to the GDB project
as a whole) to maintain their area responsively, and if the global
maintainers are reasonable people, there are few problems and problems
can be easily resolved.

> > [I hope Richard will forgive me for using him as an example and for putting
> > words in his mouth...] This doesn't replace common sense - you generally
> > won't find Richard Henderson approving patches to the C++ frontend, because:
> >   - He knows he isn't familiar with it
> >   - He knows it has an active set of maintainers at all times
> > 
> > Similarly, just because he can check in patches to any target backend, that
> > doesn't mean he won't ask a target maintainer to look over it first.  If
> > someone objects to a patch in their area, he would generally not just check
> > it in anyway.  If they object to it after he checks it in, the two will
> > discuss the problem like reasonable people and come to some agreement.
> 
> The interaction dynamics of a committed patch are very different to
> those of an unapproved patch.  Once a patch is committed, the person
> with objections is, unequestionably, put in the back seat.

I disagree.  Especially in the presence of a reversion policy.

> > Some noticeable differences between these two models:
> >   - In the GCC model, more people are able/likely to check in patches which
> >     break things.
> >   - But in the GCC model, more people are able/likely to check in patches to
> >     fix it afterwards.
> 
> (ROFL.)
> 
> The GCC model involves a number of development phases and the above
> comments would only relate to one of those phases.  At other times
> increasingly strict controls are placed on what can be
> committed/approved.  The GCC group spend a significant (out of
> control?)  amount of their time trying to re-stablize GCC for their
> releases.

That's not accurate.  First of all, the comments relate to all three of
the phases in the GCC development process, although the effect is
mostly damped down in the third phase by the release manager's hand. 
Even in stage 3, other maintainers are free to exercise their
judgement.

Also, the GCC tree spends most of its time in a more useful state than
the above really portrays.  Things tend to work.  The restabilization
is 75% a function of less-frequently-tested platforms - and you can't
realistically claim that the stability of GDB development keeps THEM
working, since we have evidence to the contrary for each of the last
several releases.

> For GDB, on the other hand, interesting development can and does get
> approved/committed at any time.  GDB snaps are of such quality that we
> can confidently refer someone to current sources for fixes (except
> when I have a bad day like today :-).  Further, instead of using
> official releases (and as you yourself have done) arbitrary snaps can
> even make their way into a distro.

[Red Hat does this too, by the way.]  Having done it, I've resolved to
avoid it in the future.  Costs outweighed benefits.

> >   - Because more people have the privilege of approving a given patch,
> >     and fewer people's approvals are needed for any particular patch,
> >     patches (usually) get approved more quickly.
> >   - Development can happen more quickly, and does not get slowed to a
> >     standstill when (say) one of us is pulled off of community GDB work for
> >     an urgent customer project.  This happens all the time - I've never seen
> >     all the GDB maintainers with time for GDB at the same time.
> 
> The only way I've got my patches into GCC is by acting as a champion
> for their cause.  Exactly like Elena described.  Having worked on
> other open source projects I'd have to conclude the same also applied
> to them.

Let me put it this way.  When I initially became a GDB developer, I was
in the process of merging back MontaVista patches to the community for
all of the toolchain packages.  For GCC and binutils, I ended up with
(eventually) write-after-approval, which means exactly nothing. 
Depending on the patch, I have to nag people about them for a day or
several.  The only way I could get patches into GDB efficiently enough
for it to be worth my time was to invest a great deal of effort into
the GDB project; to become one of the maintainers in question.  Should
that really be necessary?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [maint] The GDB maintenance process

[Jim Blandy]

I agree with what Daniel has said here.  I'm concerned that some
people have misunderstood his points, so I'll put it differently.

I think GDB could get better use of the contributors it has now by
adjusting the rules for patch approval.

- Slow patch review is a real problem on GDB --- even acknowledging
  the legitimate reasons for some delays that Elena has mentioned.

- It's true that "... some maintainers should try to review patches in
  their areas of responsibility more often", but merely saying so
  doesn't have any effect.  Folks have been saying that ever since
  Cygnus loosened its grip on GDB and the process opened to the
  public.  That statement seems to express a hope that the maintainers
  will somehow "wake up" and everything will get better.  It's been
  years, now, and we need to stop waiting for this to happen.  Let's
  work with the people we've got, rather than hoping they'll transform
  themselves somehow.

- If we accept that the maintainers' behavior is stable, then the next
  alternative is to adjust the organization that they operate under.
  Is there some way to re-organize the people we have, accepting their
  job committments and personal limitations (I have myself in mind
  here as much as anyone else, so don't be affronted), so that things
  progress better?  Is the current organization optimal?

Set that line of thinking aside, and consider another problem:

As far as I can tell, the Global Maintainers don't really have the
privileges that one would expect.  A Global Maintainer ought to be
someone who can make or approve a change anywhere in GDB.  This means,
in addition to having good technical judgement, that we trust them to
ask others as appropriate, and that we consider them good people to
debate with when a disagreement does come up.

This is different from the current definition --- as far as I can
tell, Global Maintainers aren't really that much different from anyone
else.  I've seen them criticized for approving changes, not because of
any specific problem with the changes, but because it was seen as
outside their purview.

I would personally be happy to see the current list of Global
Maintainers, of which I am a member, emptied out, and have people
re-establish their reputations to be added to the list, if it would
make folks more comfortable about straightening out the definition
this way.

So, to bring the two threads together: I think GDB could get better
use of the contributors it has now by relaxing the rules about who is
allowed to approve a patch.  With the redefinition of Global
Maintainer we're suggesting, more people would have the right to
review and approve a patch, so there are more chances someone will.

When I was maintaining Guile, I ended up replacing my dictatorship
with a group of four maintainers --- Mikael Djurfeldt, Maciej
Stachowiak, and Marius Vollmer.  Any one of those guys I trusted as
much as I trust myself.  There was no risk in making them my peers,
since I was just as likely to make a poor decision as they were (if
not more so), and if they didn't like something, it would certainly
benefit from a re-examination.  Surely we have people in the GDB
community in addition to Andrew who have earned that level of trust.


Just to add another idea to the mix:

I was talking to a friend of mine about the way GDB is run, and he was
amazed that we give individual people complete power, and complete
responsibility, for sections of code.  Everyone is going to be wrong
sometimes, he said, and it's easy to protect against, without being
too bureaucratic.

In the Apache system, which is used now in a lot of projects, they
have a pretty big group of global maintainers.  Any non-obvious core
change needs to be described on the list, and get three "+1" votes
from other global maintainers.  But if anyone posts a "-1", the change
is vetoed: it gets discussed for a longer period, and then put up for
a straight vote.

The nice thing here is that *nobody* has absolute power --- come on,
even the most talented among us is going to do something questionable
every so often, and would benefit from some more discussion --- but
it's still easy enough to get buy-in for most changes that it's
efficient.

But whether or not you like that idea, GDB has been operating under
basically the same system, and suffering the same problems, long
enough to confidently conclude that we, at least, are always going to
operate the way we do now under the system we have now.  This
delegated dictatiorship (with all due respect to our hard-working and
conscientious dictator) is more of an inherited legacy from ancient
days than a well-tuned process.  I think it's time to try to bring in
good ideas from other projects, like GCC and Apache.

Re: [maint] The GDB maintenance process

[Joel Brobecker]

Daniel said:
> I want to share a piece of perspective on why I raise this issue now. 
> I'm finding the GDB development process to be too slow to be workable -
> patches take a month or more routinely,

> Maybe that means that I just don't have the time and the patience to be
> a useful contributor to GDB.  Me, I think that it means that we need to
> make the process less painful for contributors.

So far, I have only really started making some contributions maybe a
year and a half ago, and my level of involvment is very far from a lot
of the developpers I see on this list. But I tend to agree with Daniel
that patches _sometimes_ take a very long time to be included, and that
it is easy to be discouraged. 

I think there are also a lot of patches floating around that are waiting
for at least a review. One of the ACT developpers actually stopped
submitting his patches, just because he did not receive any feedback.
And yet he spent the effort of creating a PR and attaching the patch to
this PR! So I am submitting the changes on his behalf now, and took on
the job of trying to push for these patches to be reviewed.

I agree that we are all very busy, and that it's natural that reviews
do not always happen in a timely manor. In fact, I am generally happy
with the delay-to-review, but my feeling is that the GDB community is
losing a lot of valuable work because it never gets looked at.

With my modest experience on the GDB project, and without any experience
on any other GNU project like this, it's difficult to make any
recommendation. My feeling is that we could try relaxing a bit the
rules, and allow global maintainers to approves changes if the
associated maintainer is unable to review them in say, a few (couple?)
of weeks.

Look at http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html
for intance. This patch addresses a GDB crash, and the fix has been
sitting since Oct 30th, despite 2 pings, 1 recommendation for approval,
and a message to the maintainers. I do not want to blame the maintainers
here, but in my opinion the global maintainers should be able to act as
surrogates when they see that a patch has been sitting for more than a
certain duration, and they have the knowledge to review it.

-- 
Joel

Re: [maint] The GDB maintenance process

[Jim Blandy]

ac131313@redhat.com (Andrew Cagney) writes:
> > Some noticeable differences between these two models:
> >   - In the GCC model, more people are able/likely to check in patches which
> >     break things.
> >   - But in the GCC model, more people are able/likely to check in patches to
> >     fix it afterwards.
> 
> (ROFL.)
> 
> The GCC model involves a number of development phases and the above
> comments would only relate to one of those phases.  At other times
> increasingly strict controls are placed on what can be
> committed/approved.  The GCC group spend a significant (out of
> control?)  amount of their time trying to re-stablize GCC for their
> releases.
> 
> For GDB, on the other hand, interesting development can and does get
> approved/committed at any time.  GDB snaps are of such quality that we
> can confidently refer someone to current sources for fixes (except
> when I have a bad day like today :-).  Further, instead of using
> official releases (and as you yourself have done) arbitrary snaps can
> even make their way into a distro.

The problem is, being that stable has a cost associated with it.  GCC
pays that cost at certain parts in their cycle; we pay that cost all
the time, every day.

Sure, it's nice being able to grab an arbitrary GDB snapshot and
distribute it.  But the rules which give us that property also slow
GDB's development into a more capable system.  The decision to pay
that particular price for that particular benefit is what we want to
open up for discussion.

Stability needs to be balanced with progress in features; although I'd
hate to see it go too far towards the latter, I think the balance we
have now is tipped too far in favor of the former.

Re: [maint] The GDB maintenance process

[David Carlton]

Here is some free-associating that I have about GDB's approval
process.  I'm not sure yet what I think about various concrete
proposals out there; I would like to see more existing models
discussed, because it seems unlikely to me that GDB's current model is
optimal (though, of course, what is?), and because recent history
seems to be full of interesting and potentially effective software
development models, models that I wish I knew more about.

* Overall, I'm quite happy with my experience working with GDB.  On
  the other hand, I suspect that various idiosyncracies in my
  situation make me a bit of an outlier in terms of ability and
  willingness to stick through the process.  It does seem to me that
  there have been other people's patches that would be valuable but
  that have died through lack of timely follow-through (whether by the
  approvers, by the submitters, or both, not to mention issues like
  copyright approval that we're unlikely to change).  The more people
  who are willing and allowed to help newcomers through this process,
  the better GDB will be.

* Sometimes the division of responsibility seems to me a bit strange.
  If I were a C++ maintainer, for example, it might drive me a bit
  bonkers having to wait for other people's approval for patches that
  only affect C++ but that are located in code that is in somebody
  else's domain.  (I was impressed with the way Daniel got the
  'demangling partial symbols' patch through.)

* The most serious strangeness of division of responsibility is having
  separate maintainers for the testsuite whose approval is required.
  We should do whatever we can to encourage people to write tests,
  whether to test new features or to fill in gaps in existing
  features; the more people who can approve tests, the better.  (I
  might be imagining things, but it seems to me like people have been
  frequently adding tests without waiting for approval recently; this
  seems like a good thing to me.)  It seems to me that, at the very
  least, anybody who can approve patches in a specific area should
  also be able to commit patches for tests in that area.  (Though of
  course it's good to, in addition, allow people to approve testsuite
  patches even if they can't approve non-testsuite patches: like I
  said, the more tests, the better.)

* Speaking of tests, the better the testsuite is, the less likely that
  patches will break things.  (Some currently popular development
  methodologies are rooted on this idea.)  On the other hand, there
  are good reasons (the history of GDB, its architecture, the test
  suite's architecture, and the nature of debuggers) that the
  testsuite's coverage will never be perfect, setting aside the issue
  that "not breaking behavior" isn't the same as "good".

* I have been impressed with GDB's stability.  Of course, it doesn't
  hurt that I'm using GDB on i686-pc-gnu-linux.  (Or that, frankly,
  I'm not a very heavy GDB user.)

* By temperament and programming style, I prefer to break up my
  patches into lots of small changes whose correctness should be
  relatively easy to verify.  Unfortunately, this means that it takes
  a long time for the sum of my changes to be approved.  For example,
  it's been more than 3 months since I posted a version of linespec.c
  that I think most people would agree was a significant improvement
  to its predecessor; I've submitted 14 patches to that file so far,
  with approximately an equal number to come.  I actually rather enjoy
  that process when it's going well - I log in each day, read my
  email, get an approval message for my latest patch, take a bit of
  time to generate and test my next patch, and then move on to
  something else - but it gets annoying when I have to wait for
  approval for simple, obviously correct patches.

  I've had a similar experience with cleaning up lookup_symbol_aux:
  there are bugs in that code, and I have patches to fix them, but I'm
  not sure when they'll make it into GDB.  I sigh with envy as I watch
  Andrew committing simple frame patch after simple frame patch
  without needing anybody else's approval.  A series of small patches
  like that can be a wonderful way to cleanse code.

* Continuing my last bullet point, however, it's not obvious to me
  that the changes in the approval process that Daniel suggests would
  help.  After all, there are already 3 people who can approve patches
  to linespec.c (so I'm certainly not mad at Elena - she's the only
  one taking time to actually approve the patches in question!), and I
  don't see why increasing that number would decrease the approval
  time.  So the obvious place to look for improvement is for me to
  change my behavior; I have some thoughts along those lines that I'm
  going to try to implement over the next few weeks.

* Having patches in the bug database is probably a good idea, but it
  means that somebody has to take the effort to put patches in the bug
  database.  It was great when Andrew cleaned out his mailbox and
  dumped it into the bug database; I'm not optimistic about the bug
  database working well for this in the longer term.

* Increasing the number of people who are familiar with a given
  segment of GDB's code can only improve GDB's health.  The current
  approval process seems to me to work against this, to some extent.

David Carlton
carlton@math.stanford.edu

Re: [maint] The GDB maintenance process

[Daniel Berlin]

On Tuesday, February 18, 2003, at 08:49  PM, Daniel Jacobowitz wrote:

> Thanks to everyone who responded; I'll try to address everything.
>
> I want to share a piece of perspective on why I raise this issue now.
> I'm finding the GDB development process to be too slow to be workable -
> patches take a month or more routinely, and I don't have the time to
> juggle them for that long.  I'm facing that I may need to back down my
> level of involvement as a consequence of how awkward the development
> model is for getting any forward progress.
>

A few days ago, I actually ran statistics on how long it takes for a 
patch to get first review in gcc vs gdb over the past year, and for 
gcc, it's 2.some odd days.  Believe it or not, for gdb, it was well 
over two weeks.
That's not good.
Outliers are the norm in gdb, there was no middle ground.
Either something takes 1 day to get a review, or it takes months.
The only reason the average is actually only a little over two weeks is 
because of a string of 0 day turnarounds that occasionally happen.
> Maybe that means that I just don't have the time and the patience to be
> a useful contributor to GDB.  Me, I think that it means that we need to
> make the process less painful for contributors.
FWIW, I agree, but i hold no hope it will happen.
I'm not a cynic, i'm just experienced.
I'd be a cynic if it wasn't based on experience, of course.
>
>> I have seen sometimes very quick turnarounds on patches during
>> holidays, and maybe some of such patches should have been thought
>> through more carefully. If you don't give time to the appropriate
>> maintainers to chime in, the entropy can become way too high, with
>> patches, and reverted patches going around.
>
> I guess I just don't see this to be as much of a problem as others do.
> For one thing, with the higher entropy level, more development actually
> happens.
Bingo.
I don't think we should stall development (and in the extreme,  even if 
it means we can't make quality releases any day of the year) because 
mistakes occasionally happen in patches, or because not every 
maintainer in existence has said something about a patch.  That's a 
recipe for no progress.  The old "adding more developers to a late 
project makes it later because of communication overhead" problem.

>
>>> Another thing to think about: because of the layout of the above, 
>>> there is
>>> frequently no one who has the _right_ to approve a patch.  They 
>>> require
>>> buy-in from a number of additional maintainers.  In addition our 
>>> volunteers
>>> are often too busy to find time to respond to patches.  This impacts 
>>> patches
>>> from other maintainers (frequently, but generally a small impact) 
>>> and from
>>> outside contributors (happens less frequently, but larger impact - 
>>> most of
>>> these never get approved at all, from what I've seen).
>>>
>>
>> Wait, lots of external contributor's patches never make it in because
>> of the copyright assignment problems.

Bull.
This counts for *maybe* 10% of patches that don't make it in, if that.
>> Also I see external people
>> dropping patches, not because the are not reviewed, but because they
>> *are reviewed*. I.e. a patch is submitted, I ask for some changes, and
>> the person never comes back with a new patch.

Or maybe it's because frequently the review took >1 month, and they 
just don't want to spend that much more time waiting again after making 
changes, or they moved on to other projects.

Have you noticed GDB *very rarely* keeps minor contributors coming back?
OTOH, most opensource projects (including gcc) i am a part of 
frequently have the same minor contributors, again and again.

Maybe we need community exit interviews to back this point up.

>
> Are we talking about the same thing?  I don't think I understand you.
>
> First of all, the idea of a small, fully funded elite taking control of
> the project doesn't make any sense to me.  Either their changes are
> worthwhile - the existing maintainers will cooperate with them - or
> they overstep their boundaries - they are asked to cease.  We don't
> hand out maintainership to all comers.

Well, they gave it to me (and Stan Shebs :P) at one point, so ...
:)


>
> That's not accurate.  First of all, the comments relate to all three of
> the phases in the GCC development process, although the effect is
> mostly damped down in the third phase by the release manager's hand.
> Even in stage 3, other maintainers are free to exercise their
> judgement.
>
> Also, the GCC tree spends most of its time in a more useful state than
> the above really portrays.
Yup.
Andrew's just plain wrong on this one.
All patches are bootstrapped and reg-tested on at least one platform, 
and those that are larger or could affect multiple platforms are 
bootstrapped and regtested on multiple platforms.

Any needed stabilization is generally because of latent bugs in 
*other*, less tested platforms, that improvements expose.
*Not* problems in the patches themselves.


>
>> For GDB, on the other hand, interesting development can and does get
>> approved/committed at any time.  GDB snaps are of such quality that we
>> can confidently refer someone to current sources for fixes (except
>> when I have a bad day like today :-).  Further, instead of using
>> official releases (and as you yourself have done) arbitrary snaps can
>> even make their way into a distro.
>
> [Red Hat does this too, by the way.]  Having done it, I've resolved to
> avoid it in the future.  Costs outweighed benefits.
>
I agree that it should be avoided, too.
It's just painful and not necessary here.
Our users don't clamor for a release on a certain date, nor have we 
ever had a need to make one.
The only advantage this adds is to companies using gdb sources and 
wanting to do merges to an internal tree.

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> Sure.  But my portrayal isn't entirely inaccurate, either.  One example
> - inter-compilation-unit references in DWARF-2.  It's been posted at
> least twice, by different contributors.  When asked for changes,
> they've come back with changes.  It's still not supported, over a year
> later.

Yes, I think it is fair to say that we've recently dropped baton on that 
one :-(  JimB, what's the current status?

Anyway a mid-mortem is in order.

GDB has a serious problem with _old_ forks.  cf:

- hp fork
- apple fork
- act's fork
- caldera's fork

You'll note that, in each of these cases, they really are forks(1).  The 
relevent developers created their own repository and then went off into 
the wilderness only to mysteriously appear later with a jumbo patch.  I 
believe that decision for forking was largly driven by the desire to, 
due to short term commercial pressure, avoid doing the right thing.

Not unreasonably, the GDB developers asked that such jumbo patches be 
broken down into something more managable, more up-to-date, and (too 
often) `lint' free(2).

Also, not unreasonably, the GDB developers asked/questioned 
architectural decisions made on those branches.

Less realistic, perhaps, is an over expectation of how much a 
contributor can reasonably be asked.  Even ignoring those `comercial 
pressures', many contributors figure `take it or leave it'.  Maintainers 
need to be willing to not only spend time adding glamerous new features, 
but also when an important patch appears, pick it up and run with it(3).

One thing GCC(4) and GDB are now is encouraging exprementation on 
branches development to always occure on branches cut from the the 
relevant repository.  For GDB we've had both success stories but also 
disasters.  With that in mind, and looking at the GCC / GDB success 
stories, I'd suggest the following guidelines:

- branches shall post all commits
They don't need approval but can be commented on.

- branches shall to be focused
The interps branch started out too large with too many changes - look at 
the size of the final commit compared to that branch at its peak.  Much 
time was lost because the branch started with too much lint :-(

- branches shall track mainline.
This keeps the level of divergence under control.  It also keeps the 
pressure on developers to push cleanups and other stuff into the mainline.

Andrew

--

(1) I was discussing this with a GCC developer and they pointed out, for 
the reasons I note, that these are not branches.

(2) As in the stuff you find on your clothing (not the program).  Forks 
and branches, like navel's, are shockers for breeding lint - entropy 
that serves no useful purpose.

(4) Yes, as I mentioned, I discuss this with GCC developers to see what 
lessons can be learnt.

(3) Note that if I pick up a really old patch, I'll often review, tweak 
and commit it.  I figure that if a patch is more than a month old, it 
isn't realistic to be asking a contributor to make minor changes.

Re: [maint] The GDB maintenance process

[Andrew Cagney]

>>  > Right now, we use stricter policies to prevent problems which cause
>>  > breakage.  I think these policies are stifling us.  Loosening them (and
>>  > maybe adding a formal patch reversion policy) would let more people fix
>>  > problems more easily, as they arise, without slowing development.
>>  > 
>> 
>> I really think that having the bug database track patches is a very
>> big improvement. We should try to push its use a bit more before
>> giving up on the current rules. 
> 
> 
> I don't like it, but that's just my general anti-GNATS rancor.  Maybe
> Bugzilla will be better.

The idea of tracking things as bugs or GNATS?

Tracking this stuff in a public database is, I think, clearly better 
than the status quo (my mailbox).  It's already been mentioned that 
there is possibly a lack of response with some maintainers.  At least 
with me putting unreviewed patches in the database, we can figure out 
what patches there are, and if there is a problem.  (my todo list 
includes checking that all the key developers are on the bug tracking 
list, I suspect that some are not.)

Anyway, have a look in the database, you'll notice all sorts of 
interesting things.

For instance search for tdep & h8300.  There is an obvious backlog and 
someone (a global maintainer like yourself or I) needs to step up and 
work through them with the contributors.  That task, while no where near 
as glamerous as a new feature, is absolutly needed and maintainers do 
need to be willing to chip in (in fact I think that task and 
documentation should be given a higher profile when handing out 
`credit').  Hopefuly these patches will even yield a new developer.

Andrew

Re: [maint] The GDB maintenance process

[Daniel Jacobowitz]

On Wed, Feb 19, 2003 at 10:17:12AM -0500, Andrew Cagney wrote:
> 
> >> > Right now, we use stricter policies to prevent problems which cause
> >> > breakage.  I think these policies are stifling us.  Loosening them (and
> >> > maybe adding a formal patch reversion policy) would let more people fix
> >> > problems more easily, as they arise, without slowing development.
> >> > 
> >>
> >>I really think that having the bug database track patches is a very
> >>big improvement. We should try to push its use a bit more before
> >>giving up on the current rules. 
> >
> >
> >I don't like it, but that's just my general anti-GNATS rancor.  Maybe
> >Bugzilla will be better.
> 
> The idea of tracking things as bugs or GNATS?

Mostly, GNATS.

> Tracking this stuff in a public database is, I think, clearly better 
> than the status quo (my mailbox).  It's already been mentioned that 
> there is possibly a lack of response with some maintainers.  At least 
> with me putting unreviewed patches in the database, we can figure out 
> what patches there are, and if there is a problem.  (my todo list 
> includes checking that all the key developers are on the bug tracking 
> list, I suspect that some are not.)
> 
> Anyway, have a look in the database, you'll notice all sorts of 
> interesting things.

Which reminds me.  We've got two GNATS databases set up for GDB: 'gdb'
and 'gdb-patches'.  Should we use the gdb-patches GNATS database to
separate them from bug reports?

> For instance search for tdep & h8300.  There is an obvious backlog and 
> someone (a global maintainer like yourself or I) needs to step up and 
> work through them with the contributors.  That task, while no where near 
> as glamerous as a new feature, is absolutly needed and maintainers do 
> need to be willing to chip in (in fact I think that task and 
> documentation should be given a higher profile when handing out 
> `credit').  Hopefuly these patches will even yield a new developer.

TBH, I've been avoiding it because I don't know the slightest thing
about the h8300 and it seemed like someone (I don't remember who -
MichaelS maybe?) did.  If I'm wrong then one of us is just going to
have to suck it up and learn about the h8300... yay, another project.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> With my modest experience on the GDB project, and without any experience
> on any other GNU project like this, it's difficult to make any
> recommendation. My feeling is that we could try relaxing a bit the
> rules, and allow global maintainers to approves changes if the
> associated maintainer is unable to review them in say, a few (couple?)
> of weeks.

Fernando does this already.  He also sends out e-mail saying he is off 
line for a bit (he is down the hall from me which is an advantage). 
Other maintainers do not, sigh!  More of a concern is that repeated 
pings often result in radio silence.

I don't think having a global maintainer step in after N weeks will 
really help.  It just butters over what may be a more serious underlying 
problem.

Andrew

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> A few days ago, I actually ran statistics on how long it takes for a patch to get first review in gcc vs gdb over the past year, and for gcc, it's 2.some odd days.  Believe it or not, for gdb, it was well over two weeks.
> That's not good.

Ah, statistics.  Ah metrics.

Given most outliers are now in the bug database can you perhaphs break 
it down by area and, hopefully, more usefuly, look at each area's change 
rate.

It is the change/progress that is important, not the absolute numbers. 
A lack of change that is of concern.  For instance, I worry about build 
and remote problems.  The former definitly makes progress, the latter 
less so :-(

Andrew

PS: And metrics are made to be abused.  As soon as people know the 
metric that they are being measured by, the quickly addapt their 
behavour to make that specific metric look better.

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> ac131313@redhat.com (Andrew Cagney) writes:
> 
>> > Some noticeable differences between these two models:
>> >   - In the GCC model, more people are able/likely to check in patches which
>> >     break things.
>> >   - But in the GCC model, more people are able/likely to check in patches to
>> >     fix it afterwards.
> 
>> 
>> (ROFL.)
>> 
>> The GCC model involves a number of development phases and the above
>> comments would only relate to one of those phases.  At other times
>> increasingly strict controls are placed on what can be
>> committed/approved.  The GCC group spend a significant (out of
>> control?)  amount of their time trying to re-stablize GCC for their
>> releases.
>> 
>> For GDB, on the other hand, interesting development can and does get
>> approved/committed at any time.  GDB snaps are of such quality that we
>> can confidently refer someone to current sources for fixes (except
>> when I have a bad day like today :-).  Further, instead of using
>> official releases (and as you yourself have done) arbitrary snaps can
>> even make their way into a distro.
> 
> 
> The problem is, being that stable has a cost associated with it.  GCC
> pays that cost at certain parts in their cycle; we pay that cost all
> the time, every day.

GDB is less stable then you might think.  Right now while both:

- interps
- frame

are causing problems they are not getting in the way of DavidC's dwarf2 
stuff (gee wiz, both my doing :-/).  GDB always builds, gdb always 
`break main; run'.  Is that too much to ask?

The problem with GDB's stability is that allows people to quickly forget:

- what it is like with out it
- how much gain there is from it
- how relatively small the pain
- how much more expensive it is to have to re-do something later
- how, with a bit of peer revew, problematic code could have been done 
right the first time (and how much that fallout costs).

Andrew

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> Which reminds me.  We've got two GNATS databases set up for GDB: 'gdb'
> and 'gdb-patches'.  Should we use the gdb-patches GNATS database to
> separate them from bug reports?

No!!!!  That gdb-patches database should be deleted.  It's dead.

People already have to track:

- gdb@
- gdb-patches@
- gnats@

and that is to complicated for some.  At least, by having both patches 
and bugs in a single database, we've a one stop-shop.  A better change 
is to dump gdb-patches@

> TBH, I've been avoiding it because I don't know the slightest thing
> about the h8300 and it seemed like someone (I don't remember who -
> MichaelS maybe?) did.  If I'm wrong then one of us is just going to
> have to suck it up and learn about the h8300... yay, another project.

No worse than having me review them.  All that can be done is review 
them at a coding / broad architectural level and assume that the 
contributor, given that they are using the target, have it working. 
Knowing that they run the testsuite also helps.

Andrew

Re: [maint] The GDB maintenance process

[Daniel Jacobowitz]

On Wed, Feb 19, 2003 at 10:47:46AM -0500, Andrew Cagney wrote:
> 
> >With my modest experience on the GDB project, and without any experience
> >on any other GNU project like this, it's difficult to make any
> >recommendation. My feeling is that we could try relaxing a bit the
> >rules, and allow global maintainers to approves changes if the
> >associated maintainer is unable to review them in say, a few (couple?)
> >of weeks.
> 
> Fernando does this already.  He also sends out e-mail saying he is off 
> line for a bit (he is down the hall from me which is an advantage). 
> Other maintainers do not, sigh!  More of a concern is that repeated 
> pings often result in radio silence.

Yes, Fernando does this.  He also tends to disappear for long periods
of time without doing it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [maint] The GDB maintenance process

[Daniel Jacobowitz]

On Wed, Feb 19, 2003 at 11:19:07AM -0500, Andrew Cagney wrote:
> >ac131313@redhat.com (Andrew Cagney) writes:
> >
> >>> Some noticeable differences between these two models:
> >>>   - In the GCC model, more people are able/likely to check in patches 
> >>which
> >>>     break things.
> >>>   - But in the GCC model, more people are able/likely to check in 
> >>patches to
> >>>     fix it afterwards.
> >
> >>
> >>(ROFL.)
> >>
> >>The GCC model involves a number of development phases and the above
> >>comments would only relate to one of those phases.  At other times
> >>increasingly strict controls are placed on what can be
> >>committed/approved.  The GCC group spend a significant (out of
> >>control?)  amount of their time trying to re-stablize GCC for their
> >>releases.
> >>
> >>For GDB, on the other hand, interesting development can and does get
> >>approved/committed at any time.  GDB snaps are of such quality that we
> >>can confidently refer someone to current sources for fixes (except
> >>when I have a bad day like today :-).  Further, instead of using
> >>official releases (and as you yourself have done) arbitrary snaps can
> >>even make their way into a distro.
> >
> >
> >The problem is, being that stable has a cost associated with it.  GCC
> >pays that cost at certain parts in their cycle; we pay that cost all
> >the time, every day.
> 
> GDB is less stable then you might think.  Right now while both:
> 
> - interps
> - frame
> 
> are causing problems they are not getting in the way of DavidC's dwarf2 
> stuff (gee wiz, both my doing :-/).  GDB always builds, gdb always 
> `break main; run'.  Is that too much to ask?

Of course not.  If someone breaks that, they (or we) fix it quickly. 
GCC's no different.

> The problem with GDB's stability is that allows people to quickly forget:
> 
> - what it is like with out it
> - how much gain there is from it
> - how relatively small the pain
> - how much more expensive it is to have to re-do something later
> - how, with a bit of peer revew, problematic code could have been done 
> right the first time (and how much that fallout costs).

I don't see where any of this is coming from.  As you point out above,
in a lot of respects GDB isn't all that stable.  What are we risking
here?

It also seems that Jim and I don't agree that the gain outweighs the
pain.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> - It's true that "... some maintainers should try to review patches in
>   their areas of responsibility more often", but merely saying so
>   doesn't have any effect.

For the record your name is top of the list of that `some maintainers'.

Andrew

Re: [maint] The GDB maintenance process

[David Carlton]

On Wed, 19 Feb 2003 09:54:50 -0500, Andrew Cagney <ac131313@redhat.com> said:

> One thing GCC(4) and GDB are now is encouraging exprementation on
> branches development to always occure on branches cut from the the
> relevant repository.

Would Red Hat be happy hosting significant branches for other
companies?  Would those other companies be happy depending on Red
Hat's CVS servers?  (Maybe a reasonable answer here is "yes, but money
should change hands".)  It might be nice if GDB were using a source
code management tool that didn't depend on having a single repository,
making it easier for people to maintain public branches elsewhere but
to still sync them with an official branch.

Anyways, I'd been planning for a while to write up some documentation
about creating branches; I'll try to do that sooner than later.  I was
somewhat resistant to the idea myself, but in retrospect it was
unquestionably the right way to go for my project.

David Carlton
carlton@math.stanford.edu

Re: [maint] The GDB maintenance process

[Kevin Buettner]

On Feb 19,  9:33am, David Carlton wrote:

> On Wed, 19 Feb 2003 09:54:50 -0500, Andrew Cagney <ac131313@redhat.com> said:
> 
> > One thing GCC(4) and GDB are now is encouraging exprementation on
> > branches development to always occure on branches cut from the the
> > relevant repository.
> 
> Would Red Hat be happy hosting significant branches for other
> companies?

I assume you're referring to the sources.redhat.com repository, right?

I think the answer is "yes", so long as the branch in question is
intended to (eventually) further mainline gdb development.  If the
branch is just some custom bit of work that is likely to never make
it to the mainline, probably not.

> Would those other companies be happy depending on Red
> Hat's CVS servers?

I doubt it.  But...

For the contract work that Red Hat itself does, Red Hat does not depend
solely on the external (sources.redhat.com) respository.  Red Hat has
an internal repository that it uses for customer work.  From time to time,
the public repository is merged to Red Hat's internal repository.  Also,
from time to time, work that was performed for a customer which couldn't
immediately go into the public repository is pushed out to the public.

> (Maybe a reasonable answer here is "yes, but money
> should change hands".)  It might be nice if GDB were using a source
> code management tool that didn't depend on having a single repository,
> making it easier for people to maintain public branches elsewhere but
> to still sync them with an official branch.

Hmm.  Something to think about.

Kevin

Re: [maint] The GDB maintenance process

[Christopher Faylor]

On Wed, Feb 19, 2003 at 11:29:13AM -0500, Andrew Cagney wrote:
>That gdb-patches database should be deleted.  It's dead.

Done.

cgf

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> On Feb 19,  9:33am, David Carlton wrote:
> 
> 
>> On Wed, 19 Feb 2003 09:54:50 -0500, Andrew Cagney <ac131313@redhat.com> said:
>> 
> 
>> > One thing GCC(4) and GDB are now is encouraging exprementation on
>> > branches development to always occure on branches cut from the the
>> > relevant repository.
> 
>> 
>> Would Red Hat be happy hosting significant branches for other
>> companies?

FYI, it isn't a Red Hat decision.

> I assume you're referring to the sources.redhat.com repository, right?
> 
> I think the answer is "yes", so long as the branch in question is
> intended to (eventually) further mainline gdb development.  If the
> branch is just some custom bit of work that is likely to never make
> it to the mainline, probably not.

And that decision is up to this group.

>> Would those other companies be happy depending on Red
>> Hat's CVS servers?

Should money making corporate types be willing to bet the crown jewls on 
those same resources (sware, subversion, sourceforge)?  Interesting 
question.

Red Hat makes sourceware available as a public service.  It funds it 
rather than owns it.  The machine is adminstered by a group of overseers 
(chrisf and jasonm are two).

Andrew

Re: [maint] The GDB maintenance process

[David Carlton]

On Wed, 19 Feb 2003 10:57:20 -0700, Kevin Buettner <kevinb@redhat.com> said:

> For the contract work that Red Hat itself does, Red Hat does not
> depend solely on the external (sources.redhat.com) respository.  Red
> Hat has an internal repository that it uses for customer work.  From
> time to time, the public repository is merged to Red Hat's internal
> repository.  Also, from time to time, work that was performed for a
> customer which couldn't immediately go into the public repository is
> pushed out to the public.

Thanks for the info; that sounds sensible.

It would be nice if there were a scheme that allowed such development
to go on smoothly while still making it as easy as possible for
changes in separate repositories to make it into the mainline.  I
don't really know to do that, though.

David Carlton
carlton@math.stanford.edu

Re: [maint] The GDB maintenance process

[Christopher Faylor]

On Wed, Feb 19, 2003 at 02:01:14PM -0500, Andrew Cagney wrote:
>Red Hat makes sourceware available as a public service.  It funds it 
>rather than owns it.  The machine is adminstered by a group of overseers 
>(chrisf and jasonm are two).

I know that Jason likes svn but I haven't used it.  I'm not sure that it
would be easy to convince me to spend any time trying to convert
everything to a new source control system.  CVS is nice because it lives
everywhere and is a known commodity.  Do we really want to think about
the headache of having people set up svn (or arch, or whatever) if they
want to develop with gdb?  Do we want to make gdb's repository separate
from, say, cygwin's or newlib's?  Seems like a lot of tricky work to me.

cgf

Re: [maint] The GDB maintenance process

[Andrew Cagney]

>> Fernando does this already.  He also sends out e-mail saying he is off 
>> line for a bit (he is down the hall from me which is an advantage). 
>> Other maintainers do not, sigh!  More of a concern is that repeated 
>> pings often result in radio silence.
> 
> 
> Yes, Fernando does this.  He also tends to disappear for long periods
> of time without doing it.

Fernando and I finding that my e-mail pings to him got black holed for 6 
months didn't help (this is where being able to walk down the hall is a 
disadvantage :-).   I don't know that others have the luxury of that excuse.

Andrew

Re: [maint] The GDB maintenance process

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:

> > - It's true that "... some maintainers should try to review patches in
> >   their areas of responsibility more often", but merely saying so
> >   doesn't have any effect.
> 
> For the record your name is top of the list of that `some maintainers'.

If you like.  I pick on myself often enough elsewhere in that message
that it should be clear I'm not trying to make others feel bad for
shortcomings I have myself.

In fact, this is exactly what we need to put behind us: we can spend
another few years feeling bad for being insufficiently responsive, and
treating it as a personal failure.  But that approach hasn't improved
things noticeably, so, is there something else we can do?  Given the
people we have, the community we have, and their known strengths and
weaknesses, what is the best way to organize them?  Can we improve on
what we're doing now?

I think the explicit hierarchy we have now, outlined in MAINTAINERS,
is a real problem in this sense.  It's a big, public, political deal
to rearrange that hierarchy.  There are other systems where the
processes of promoting promising contributors and clearing dead wood
happen smoothly and automatically, without confrontation.  People
contribute as they are able, and leaders emerge and recede in a
natural way, not by fiat.  The Apache system, for example, encourages
newcomers to acquire expertise in different areas, and allows less
responsive people to simply fall to the wayside as irrelevant.

These systems are in widespread use, and I think some are even
well-documented, like: http://httpd.apache.org/dev/guidelines.html

Re: [maint] The GDB maintenance process

[Christopher Faylor]

Has anyone taken the time to go through the list of outstanding patches
and categorize them by maintainership?

I'm wondering if this is just a problem with a couple of maintainers
being unresponsive.

For instance, as a not-so-wild guess, I'd say that the symtab part of
gdb frequently falls behind.  That may be because there are more
symtab-related patches being supplied or it could be that I'm just
imagining things.

If there are some maintainers who just aren't responsive enough, for
whatever reason, then the simple expedient of adding another maintainer
for that specific part of gdb might go a long way towards fixing the
backlog.

However, if the patches are all over the board then this technique
probably won't work.

cgf

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> Has anyone taken the time to go through the list of outstanding patches
> and categorize them by maintainership?

Already done, see the bug database.   Mind you only very recently but I 
think we're already seeing results.

> I'm wondering if this is just a problem with a couple of maintainers
> being unresponsive.
> 
> For instance, as a not-so-wild guess, I'd say that the symtab part of
> gdb frequently falls behind.  That may be because there are more
> symtab-related patches being supplied or it could be that I'm just
> imagining things.

There are more symtab patches but, thanks to one maintainer, they are 
moving.  Not sure about other categories, some do appear stalled :-(

> If there are some maintainers who just aren't responsive enough, for
> whatever reason, then the simple expedient of adding another maintainer
> for that specific part of gdb might go a long way towards fixing the
> backlog.

There is responsive and then there is reliable :-/

Andrew

Re: [maint] The GDB maintenance process

[Jason Molenda]

On Wed, Feb 19, 2003 at 02:01:14PM -0500, Andrew Cagney wrote:
>Red Hat makes sourceware available as a public service.  It funds it 
>rather than owns it.  The machine is adminstered by a group of overseers 
>(chrisf and jasonm are two).

Minor correction - RH owns the physical sources.redhat.com system.
It pays for the network bandwidth, electricity, and the necessary
network IS resources.  The time spent actually administering the
box (almost entirely Chris Faylor these days) is outside the scope
of cgf's Day Job, so most administration is on a volunteer basis.

On Wed, Feb 19, 2003 at 03:39:50PM -0500, Christopher Faylor wrote:

> I know that Jason likes svn but I haven't used it.  I'm not sure that it
> would be easy to convince me to spend any time trying to convert
> everything to a new source control system.  CVS is nice because it lives
> everywhere and is a known commodity.  

I don't think I saw anyone suggesting alternative SCMs... cagney
wrote "sware, subversion, sourceforge", but he probably meant
to write "subversions", as in "subversions.gnu.org".


(svn is really interesting, and I expect I'll be playing with it
more this year, but it'll be a while before anyone wants to switch
their project to using it.  If nothing else, each developer in that
project has to install/set up svn before they can access the
repository.)

Jason

Re: [maint] The GDB maintenance process

[Jason Molenda]

On Wed, Feb 19, 2003 at 11:29:13AM -0500, Andrew Cagney wrote:
> 
> > Which reminds me.  We've got two GNATS databases set up for GDB: 'gdb'
> > and 'gdb-patches'.  Should we use the gdb-patches GNATS database to
> > separate them from bug reports?
> 
> No!!!!  That gdb-patches database should be deleted.  It's dead.
> 
> People already have to track:
> 
> - gdb@
> - gdb-patches@
> - gnats@
> 
> and that is to complicated for some.  At least, by having both patches 
> and bugs in a single database, we've a one stop-shop.  A better change 
> is to dump gdb-patches@


We've got two separate discussions here:  The social conventions
and procedures for how patches are discussed/applied, and the
infrastructure to support those things.

Using GNATS as the infrastructure to track patches is pathetic.
Using mailing lists to track patches is annoying.

For a minute, though, imagine a magical patch tracking database.
It would be at the core of the patch workflow, not something glommed
on to the side--anything that says "you send your note to gdb-patches
and then you enter it into the patch database" is missing the point.
It wouldn't be a bug database, it would be a patch database--it's
got to track updates to the patch, it's got to relate groups of
patches or patches dependant on other patches.  It'll track the
discussion about patches.  It could track various maintainer's
opinions on a patch (I like the -1/+0/+1 Apache scheme); it could
track when the patch is blocked on a particular person (submitter,
a maintainer), or maybe when the patch is waiting approval by any
one of several people.  It could even relate GNATS bugs and patches
that are attempting to fix those bugs, so when someone sees a bug
in the GNATS database that hasn't yet been fixed, they can click
over to the magical patch tracking database and see why that patch
isn't in yet.

All of these transactions are still visible on a gdb-patches list,
of course, but the mailing list is a read-only view on to what's
happening.  All additional comments or follow-ups are routed through
the magical patch tracking database, and reflected back out to the
gdb-patches list.


I've heard Sourceforge has such a tool.  JimI was telling me at
lunch how they track the tcl patches this way.  And there is a
separate mechanism that tcl and Python both use for larger-scope
proposals ("PEP" for Python, a "Python Enhancement Proposal").
For instance, here's a PEP to add a boolean type to Python:
	http://www.python.org/peps/pep-0285.html
And it has a link into the Patch Tracker sourceforget database 
for the patch to implement the proposal:
	http://python.org/sf/528022



Don't fall into the trap of saying "the only two ways patches can
be tracked are the gdb-patches mailing list or gnats".  Let's start
by imagining a patch database designed around our actual workflow,
one which would require a minor change in how we work and add a
tiny bit of extra patch-management overhead, and yield benefits of
not losing track of patches.  

If such a magical patch tracking database exists, would it be worth
changing our workflow to use it?  I know that patch submitters would
eagerly jump on such a system, but unless all the actual maintainers
think it's a net gain it's not going anywhere.

Once that's all decided - what we want, and if we'd even use it if
we had it - then there's the minor matter of making it exist. :-)
Maybe bugzilla or gnats can be adapted, maybe another program can
be found from the net or a free bit of code from Sourceforge's
PatchTracker can be appropriated, or maybe someone gets the joyus
chance to write it from scratch.  


Before we get bogged down in implementation details and discussions,
it's critical to discuss what such a system would do, and if we're
all willing to push gdb patch work through it.  If we can't dream
up such a system, then let's be happy with gdb-patches and URLs
for patch references.

J

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> 
> 
> We've got two separate discussions here:  The social conventions
> and procedures for how patches are discussed/applied, and the
> infrastructure to support those things.
> 
> Using GNATS as the infrastructure to track patches is pathetic.

Not as pathetic as `cagney's mailbox sitting on a lapbrick with a 
failing hard disk'.

> Using mailing lists to track patches is annoying.

Er, you can't track patches using a mailing list.  A mailing list can be 
used to submit/discuss patches.  It can't be used to track their state. 
  that needs a database.

Time to install aegis, ay?

Andrew

Re: [maint] The GDB maintenance process

[Elena Zannoni]

Jim Blandy writes:
 > Andrew Cagney <ac131313@redhat.com> writes:
 > 
 > > > - It's true that "... some maintainers should try to review patches in
 > > >   their areas of responsibility more often", but merely saying so
 > > >   doesn't have any effect.
 > > 
 > > For the record your name is top of the list of that `some maintainers'.
 > 
 > 
 > I think the explicit hierarchy we have now, outlined in MAINTAINERS,
 > is a real problem in this sense.  It's a big, public, political deal
 > to rearrange that hierarchy.  There are other systems where the
 > processes of promoting promising contributors and clearing dead wood
 > happen smoothly and automatically, without confrontation.  People
 > contribute as they are able, and leaders emerge and recede in a
 > natural way, not by fiat.  The Apache system, for example, encourages
 > newcomers to acquire expertise in different areas, and allows less
 > responsive people to simply fall to the wayside as irrelevant.
 > 
 > These systems are in widespread use, and I think some are even
 > well-documented, like: http://httpd.apache.org/dev/guidelines.html

"Membership as a Committer is by invitation only and must be approved
 by consensus of the active Apache PMC members. A Committer is
 considered inactive by their own declaration or by not contributing
 in any form to the project for over six months. An inactive member
 can become active again by reversing whichever condition made them
 inactive (i.e., by reversing their earlier declaration or by once
 again contributing toward the project's work). Membership can be
 revoked by a unanimous vote of all the active PMC members (except the
 member in question if they are a PMC member)."


How is being a member of the 'Committers' by "invitation only" not
going to be another political deal?

How is the 6 months inactivity period going to help? None of the
current gdb maintainers perticipating in this discussion has ever
disappeared for that long, really.  If some person has disappeared
from radar, like relocated, changed e-mail, etc, the person has been
removed from the list. I can think of one such case.


I don't like this one:

"Ideas must be review-then-commit; patches can be
 commit-then-review. With a commit-then-review process, we trust that
 the developer doing the commit has a high degree of confidence in the
 change."

Re: [maint] The GDB maintenance process

[Jason Molenda]

On Wed, Feb 19, 2003 at 06:57:01PM -0500, Andrew Cagney wrote:

> > Using GNATS as the infrastructure to track patches is pathetic.
> 
> Not as pathetic as `cagney's mailbox sitting on a lapbrick with a 
> failing hard disk'.

Well, yes. :-)  I didn't mean "you, the fellow who has put patches
into gnats, are a fool" -- I meant that the overhead over putting
patches in gnats is too high compared with just sending them to
gdb-patches.  IMHO this is a method that will fail, which is why
I dragged my feet when Elena originally requested the gdb-patches
gnats database be set up.  Ignoring the fact that gnats is a bug
tracker--not a magical patch tracking database--as long as it isn't
at the center of every developer/maintainer's patch workflow, it
will be doomed to irrelevance.

It's got to be easy, it's got to be relevant, and it's gotta be the
way everything is done.

> > Using mailing lists to track patches is annoying.
> 
> Er, you can't track patches using a mailing list.  A mailing list can be 
> used to submit/discuss patches.  It can't be used to track their state. 
>   that needs a database.

I was speaking loosely - I meant the combination of the mailing
list and the web archives of that mailing list.  The mailing list
web archives are a being used as the patch repository right
now--people use URLs into the archives to refer to old patches,
they use google or the htdig search engine to find old patches,
and they grope around blindly to figure out what ever happened with
a given patch.

> Time to install aegis, ay?

I've never looked at Aegis, so I can't say.  First the gdb maintainers
and developers need to decide what they want and will use, then
make it exist; not look at what exists and settle for it.  Maybe
Aegis is exactly what we'd all love in a magical patch tracking
database and we can use it as-is, but IMHO it's too early in that
discussion to care one way or another.


J

Re: [maint] The GDB maintenance process

[Elena Zannoni]

Jason Molenda writes:
 > On Wed, Feb 19, 2003 at 06:57:01PM -0500, Andrew Cagney wrote:
 > 
 > > > Using GNATS as the infrastructure to track patches is pathetic.
 > > 
 > > Not as pathetic as `cagney's mailbox sitting on a lapbrick with a 
 > > failing hard disk'.
 > 
 > Well, yes. :-)  I didn't mean "you, the fellow who has put patches
 > into gnats, are a fool" -- I meant that the overhead over putting
 > patches in gnats is too high compared with just sending them to
 > gdb-patches.  IMHO this is a method that will fail, which is why
 > I dragged my feet when Elena originally requested the gdb-patches
 > gnats database be set up.  Ignoring the fact that gnats is a bug

It must have been my evil twin, because I don't remember asking for
this (I am in favor of something like it, though). To be honest, it
was a project that Jim Blandy started but wasn't finished. It was
abandoned because there were problems with including a patch
preserving spaces, or something like that.

 > tracker--not a magical patch tracking database--as long as it isn't
 > at the center of every developer/maintainer's patch workflow, it
 > will be doomed to irrelevance.
 > 
 > It's got to be easy, it's got to be relevant, and it's gotta be the
 > way everything is done.
 > 
 > > > Using mailing lists to track patches is annoying.
 > > 
 > > Er, you can't track patches using a mailing list.  A mailing list can be 
 > > used to submit/discuss patches.  It can't be used to track their state. 
 > >   that needs a database.
 > 
 > I was speaking loosely - I meant the combination of the mailing
 > list and the web archives of that mailing list.  The mailing list
 > web archives are a being used as the patch repository right
 > now--people use URLs into the archives to refer to old patches,
 > they use google or the htdig search engine to find old patches,
 > and they grope around blindly to figure out what ever happened with
 > a given patch.
 > 
 > > Time to install aegis, ay?
 > 
 > I've never looked at Aegis, so I can't say.  First the gdb maintainers
 > and developers need to decide what they want and will use, then
 > make it exist; not look at what exists and settle for it.  Maybe
 > Aegis is exactly what we'd all love in a magical patch tracking
 > database and we can use it as-is, but IMHO it's too early in that
 > discussion to care one way or another.
 > 
 > 
 > J

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> On Wed, Feb 19, 2003 at 06:57:01PM -0500, Andrew Cagney wrote:
> 
> 
>> > Using GNATS as the infrastructure to track patches is pathetic.
> 
>> 
>> Not as pathetic as `cagney's mailbox sitting on a lapbrick with a 
>> failing hard disk'.
> 
> 
> Well, yes. :-)  I didn't mean "you, the fellow who has put patches
> into gnats, are a fool" -- I meant that the overhead over putting
> patches in gnats is too high compared with just sending them to
> gdb-patches.  IMHO this is a method that will fail, which is why
> I dragged my feet when Elena originally requested the gdb-patches
> gnats database be set up.  Ignoring the fact that gnats is a bug
> tracker--not a magical patch tracking database--as long as it isn't
> at the center of every developer/maintainer's patch workflow, it
> will be doomed to irrelevance.

Actually the overhead is effectively zero.  Any patch not touched for a 
week gets run through a script that turns it into a gnats entry.

Once there, I and everyone else can search it.  I know of non-mainstream 
developers that perfer this as it is easier to pick up a task (and 
easier to track than either gdb@ or gdb-patches@).

It sux, but sux less than not doing it.  It is interum measure that will 
hopefully be replaced by bugzilla.

Andrew

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> How is the 6 months inactivity period going to help? None of the
> current gdb maintainers perticipating in this discussion has ever
> disappeared for that long, really.  If some person has disappeared
> from radar, like relocated, changed e-mail, etc, the person has been
> removed from the list. I can think of one such case.

There was one such case.  There have also been two dummy spits; and, 
after lobying, a number of people `stepping down'.

One thing I've noticed is that people struggle to appreciate the 
difference between `no maintainer' and `inactive maintainer'.  There is 
a definite resistance to `letting go'.

Andrew

Re: [maint] The GDB maintenance process

[Christopher Faylor]

On Wed, Feb 19, 2003 at 03:17:09PM -0800, Jason Molenda wrote:
>On Wed, Feb 19, 2003 at 03:39:50PM -0500, Christopher Faylor wrote:
>>I know that Jason likes svn but I haven't used it.  I'm not sure that
>>it would be easy to convince me to spend any time trying to convert
>>everything to a new source control system.  CVS is nice because it
>>lives everywhere and is a known commodity.
>
>I don't think I saw anyone suggesting alternative SCMs...  cagney wrote
>"sware, subversion, sourceforge", but he probably meant to write
>"subversions", as in "subversions.gnu.org".

I probably responded one message too late.  David Carlton said this:

>It might be nice if GDB were using a source code management tool that
>didn't depend on having a single repository, making it easier for
>people to maintain public branches elsewhere but to still sync them
>with an official branch.

So when I saw Andrew mention subversion, I thought we were still talking
about source control systems rather than systems which run source
control systems.

cgf

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> I agree with what Daniel has said here.  I'm concerned that some
> people have misunderstood his points, so I'll put it differently.
> 
> I think GDB could get better use of the contributors it has now by
> adjusting the rules for patch approval.
> 
> - Slow patch review is a real problem on GDB --- even acknowledging
>   the legitimate reasons for some delays that Elena has mentioned.

I found myself babysitting a short list of largely dormant maintainers 
using regular pings.  That was grosely inefficient.  I've now given that 
one up and have moved on to filing unreviewed patches in the bug 
database - worse for the contributor waiting on a dormant maintainer but 
better for me and the other active maintainers.

It has been in place for ~a month and, in my opinion, has definitly 
improved things.  There is a one-stop-shop where active [global] 
maintainers can either find a backlog of patches or areas that need work.

I just wish that the tool being used was less primative :-(

> - It's true that "... some maintainers should try to review patches in
>   their areas of responsibility more often", but merely saying so
>   doesn't have any effect.  Folks have been saying that ever since
>   Cygnus loosened its grip on GDB and the process opened to the
>   public.  That statement seems to express a hope that the maintainers
>   will somehow "wake up" and everything will get better.  It's been
>   years, now, and we need to stop waiting for this to happen.  Let's
>   work with the people we've got, rather than hoping they'll transform
>   themselves somehow.

And the vast majority of maintainers do a pretty good job.

> - If we accept that the maintainers' behavior is stable, then the next
>   alternative is to adjust the organization that they operate under.
>   Is there some way to re-organize the people we have, accepting their
>   job committments and personal limitations (I have myself in mind
>   here as much as anyone else, so don't be affronted), so that things
>   progress better?  Is the current organization optimal?

Stable or reliable?  Most maintainers are reliable, a small few, though, 
seem to keep falling asleep at the wheel.

Having such people as developers isn't a problem.  Having such people 
hold key responsabilities (such as being in the loop to review patches) is.

Andrew

Re: [maint] The GDB maintenance process

[Richard Earnshaw]

> One thing GCC(4) and GDB are now is encouraging exprementation on 
> branches development to always occure on branches cut from the the 
> relevant repository.  For GDB we've had both success stories but also 
> disasters.  With that in mind, and looking at the GCC / GDB success 
> stories, I'd suggest the following guidelines:
> 
> - branches shall post all commits
> They don't need approval but can be commented on.
> 
> - branches shall to be focused
> The interps branch started out too large with too many changes - look at 
> the size of the final commit compared to that branch at its peak.  Much 
> time was lost because the branch started with too much lint :-(
> 
> - branches shall track mainline.
> This keeps the level of divergence under control.  It also keeps the 
> pressure on developers to push cleanups and other stuff into the mainline.

I think there's a few other ground-rules that ought to apply, particularly 
with respect to the first point:

-Branches should have an owner.
The owner can set further policy for a branch, but may not change the 
ground rules.  In particular, they can set a policy for commits (be it 
adding more reviewers or deciding who can commit).

-All commits to a branch must be covered by an assignment
This saves us from the situation where a branch might become contaminated.

R.

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> I was talking to a friend of mine about the way GDB is run, and he was
> amazed that we give individual people complete power, and complete
> responsibility, for sections of code.  Everyone is going to be wrong
> sometimes, he said, and it's easy to protect against, without being
> too bureaucratic.

Interesting spin.

I think the concept such as `the Buck stops' and having the final 
decision, are very different to `complete power'.   The former is about 
responsibility.

A maintainer, who is a member of a larger team, takes on certain 
responsibilities, such making the final decision when reviewing a patch. 
  The maintainer is assumed to have sufficiently good judgment, however, 
they are also assumed to be taking on board the comments and suggestions 
being made by their peers.

Andrew

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> When I was maintaining Guile, I ended up replacing my dictatorship
> with a group of four maintainers --- Mikael Djurfeldt, Maciej
> Stachowiak, and Marius Vollmer.  Any one of those guys I trusted as
> much as I trust myself.  There was no risk in making them my peers,
> since I was just as likely to make a poor decision as they were (if
> not more so), and if they didn't like something, it would certainly
> benefit from a re-examination.  Surely we have people in the GDB
> community in addition to Andrew who have earned that level of trust.

The global write maintainers already have this responsability.  Every so 
often there needs to be a `judgment call'(1) which falls to the gdb head 
(again `the buck stops').  On the whole, though, the group should be 
discusses technical issues selecting designs based solely on their 
relative merits.

One thing I do do though, is nip debates that are re-flogging head 
issues, in the bud.  Proposals for making GDB LGPL, for instance.

Andrew

(1) The last one I remember making was adopting gdb/cli/cli-*.[hc] for 
cli file names and for that one I tossed a coin.

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> -Branches should have an owner.
> The owner can set further policy for a branch, but may not change the 
> ground rules.  In particular, they can set a policy for commits (be it 
> adding more reviewers or deciding who can commit).

Yep.

> -All commits to a branch must be covered by an assignment
> This saves us from the situation where a branch might become contaminated.

Um, er, yes, `obviously' (How did I forget that one :-( :-).

Andrew

Re: [maint] The GDB maintenance process

[Mark Kettenis]

I mostly agree with Daniel here.  We have too many single points of
failure.  I still have testsuite patches sitting in my tree, dating
months back since they were never approved.  Similarly, Daniel
probably has been held back more than once since I wasn't able to
review threads-related patches in a timely fashion.  I think we should
allow our global maintainers to approve patches even for parts of GDB
where we have a specific maintainer, if they feel they have the
necessary expertise.

Mark

Re: [maint] The GDB maintenance process

[Andrew Cagney]

> I mostly agree with Daniel here.  We have too many single points of
> failure.  I still have testsuite patches sitting in my tree, dating
> months back since they were never approved.  Similarly, Daniel
> probably has been held back more than once since I wasn't able to
> review threads-related patches in a timely fashion.  I think we should
> allow our global maintainers to approve patches even for parts of GDB
> where we have a specific maintainer, if they feel they have the
> necessary expertise.

Depends on what `single point failure' means.  If you look through the 
MAINTAINERS file you'll notice that all but one of the problem areas is 
double, if not triple maintained.  Even with all that dedundency, 
patches in certain areas continues to stall.  While there might be three 
maintainers, the reality is only one or none are reliable.

The first, and most obvious thing is for the global maintainers to 
review their current number of responsibilities and compare that against 
their actual level of commmitment.  I'm down to just target/arch, 
remote, mips and sim/ppc.

The second, is for maintainers to always be on the lookout for potential 
new maintainers (global or not) and, where possible, step aside to let 
new commers in.

Finally, the GDB `tradition' (that appears to have been forgotten) is to 
up front reach consensus on stuff so that the final patches are trivial 
to review.  cf, the block.[hc] change.

enjoy,
Andrew

Unambiguously specifying source locations

[Daniel Jacobowitz]

This isn't a proposal - I haven't clearly thought out the details - just
some ramblings on a problem.

I would like to have a way to clearly identify a location, not by address. 
Primarily this would be for breakpoints; when we re-read an objfile's
symbols, we need to replace breakpoints somehow, and the more of the user's
intent we can preserve the better.  Obviously this is not a perfectly
solvable problem, but we can do pretty well.

It's an important problem, too.  Not only is recompile/reload a pretty
common thing to do, but IDEs which save breakpoints across sessions would
use this also.  Et cetera.

I think it's only source locations that I need to identify in this way, in
the short term, but we should use an extensible syntax.  For a
way-beyond-current-state example, consider an inlined function with multiple
inlined instances.  One of the simpler things we could do is:

  record the number of instances in this objfile before reloading
  check the number of instances in this objfile after reloading
  if same, then we can preserve things like the breakpoint enabled state
    to the new set
  if not, punt - enable all?  warn?

The goal there being to preserve the status of particular breakpoints across
reload, as best as we can, when unrelated changes are made to the source.
Someone fixes emit_foo () and recompiles and we try not to disturb their
eight disabled and one enabled breakpoint on inlined copies of obstack_alloc
where they were tracking the allocation of the bad object.

We could be much more thorough.  Try this on for size:
  Record the source location of the emitted function which contains each
    inlined instance, as unambiguously as we can.
  Record the inlining path.

The result would look something like (I don't like this syntax, just
illustrating):
  [libfoo.so.2][foo-1.cc:foo_func:75][bar-1.h:inline_one:33]\
    [bar-1.h:inline_two:36]
Then after reload if the path still leads to an inlined copy of inline_two
we can re-establish the breakpoint.  Or there are various fuzzy matching
things we could do.  Et cetera.

Generating such paths would be useful for output anyway; and if we can do
them in such a way as to accept them for input too, that would be useful to
our users.  We could also accept as input ambiguous paths and do basically
wildcarding:
  break [libfoo.so.2][bar-1.h]inline_two

Wouldn't that be nice?

The use of braces is not entirely coincidental.  decode_line_1 currently
does not accept anything that starts with a '[' as far as I can see; ObjC
selectors always have +[ or -[.  Using braces simplifies quoting and parsing
quite a bit.  And it could be extended as necessary without too much
trouble.

There are other problems: for instance, we might want to use linker names
for non-inlined functions where possible, for GDB-generated location
descriptions; that would handle keeping track of which constructor we were
stopped on.  Otherwise we'd need some other method for that.

Another nice thing to have might be an element in that list describing
C++ template instantiation.  Not sure if that's necessary or should just be
added to the function name as needed.

Include paths may also be needed.  This happens in C, with static functions
in headers.  Here's an example that bites me all the time:
  [libbfd.so][elf32-i386.c][elflink.h:2300]
  [libbfd.so][elf32-sparc.c][elflink.h:2300]
or maybe it should be:
  [libbfd.so][elf32-i386.c:elflink.h:2300]
  [libbfd.so][elf32-sparc.c:elflink.h:2300]
The latter, I think.

Right now the equivalent to this is handled in build_canonical_line_spec.
It's a little simple-minded; there are plenty of cases it doesn't handle.
It would be nice to do better.

Any specification of this should be explicit about quoting rules, comma,
dammit.

What other thoughts do you all have?  Am I on the right track, should we
draw up a formal specification for these?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Unambiguously specifying source locations

[David Ayers]

Daniel Jacobowitz wrote:

>The use of braces is not entirely coincidental.  decode_line_1 currently
>does not accept anything that starts with a '[' as far as I can see; ObjC
>selectors always have +[ or -[.  
>
Actually this is not the case.  If the +/- is omitted both are offered 
as breakpoints if they exist:

(gdb) b [NSObject autorelease]
[0] cancel
[1] all
[2] -[NSObject autorelease] at NSObject.m:1553
[3] +[NSObject autorelease] at NSObject.m:1575
 >

But maybe you could rely on the fact that there must be a white space 
between the class and the message.

Cheers,
David Ayers

Re: Unambiguously specifying source locations

[Daniel Jacobowitz]

On Fri, Oct 10, 2003 at 05:39:34PM +0200, David Ayers wrote:
> Daniel Jacobowitz wrote:
> 
> >The use of braces is not entirely coincidental.  decode_line_1 currently
> >does not accept anything that starts with a '[' as far as I can see; ObjC
> >selectors always have +[ or -[.  
> >
> Actually this is not the case.  If the +/- is omitted both are offered 
> as breakpoints if they exist:
> 
> (gdb) b [NSObject autorelease]
> [0] cancel
> [1] all
> [2] -[NSObject autorelease] at NSObject.m:1553
> [3] +[NSObject autorelease] at NSObject.m:1575
> >

Hmm, thank you.  I don't quite see how that happens so I'll have to go
peer at linespec.c again.

> But maybe you could rely on the fact that there must be a white space 
> between the class and the message.

I'd rather not - there can be whitespace in file names, shared object
names, et cetera.  Perhaps something different is in order.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Unambiguously specifying source locations

[Felix Lee]

>  [libfoo.so.2][foo-1.cc:foo_func:75][bar-1.h:inline_one:33]\
>    [bar-1.h:inline_two:36]

One thing I'm not clear about, you're mixing source locators with
object locators.  Is it really a path?  Maybe it should be
an arbitrary qualifier list instead?  Like
    foofunc[obj libfoo.so]
    foofunc[src foo.h in foo1.cc]
the first would be all foofunc in libfoo.so. the second would be
all foofunc the compiler generates from foo.cc/foo.h.  and
perhaps let the user combine qualifiers with boolean operators.
--

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Fri, Jun 21, 2002 at 06:14:41PM -0500, Jim Blandy wrote:
> > 
> > One of the reasons I really like having libthread_db handle TLS
> > resolution is that the alternative is to do an inferior function call
> > when you reference a variable.  Check out Uli's document, at the
> > pointer I gave --- even the compiler will sometimes have to generate a
> > call to __tls_get_addr to find a __thread variable's address.
> > 
> > And GDB shouldn't cache this base address while the inferior runs,
> > either --- remember the "GDB must never lie" rule.  Evaluating `x' in
> > GDB had better reference the same storage that it would if the compiler
> > evaluated `x' at the point where the program is stopped.
> > 
> > So if we have trouble keeping the Insight variable window up-to-date
> > now...
> > 
> > Anyway, in that context, having libthread_db handle it all in-process
> > seems really nice.
> 
> Well, libthread_db is still pretty expensive.  It generally does a
> substantial amount of memory access to the inferior.  Cheaper than a
> function call, but not so much.

Well, td_thr_tls_get_addr only makes two calls to ps_pdread.  The
first one is a big one, unfortunately --- it reads a pretty large
structure.

> Part of that is the ridiculous way we use it and abuse the thread_alive
> checks at every opportunity.  If you benchmark some operations on
> libthread_db/native gdb, and gdb/local gdbserver (which uses thread_db,
> but makes some documented assumptions about the threading model, and
> also supports partial stops which I haven't worked out how to do in GDB
> proper) you'll see that the overhead of the remote protocol is
> sometimes less than the overhead of native thread_db.

It seems to me that the right place to handle this is in
proc-service.c, or in the layers below that --- those layers may know
the inferior is stopped, and be able to cache memory contents, etc.

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Sat, Jun 22, 2002 at 11:22:49AM -0400, Andrew Cagney wrote:
> >Sorry, I'm lost here.
> >>
> >>Say, instead of a libthread_db, we had gdb/libthread-db.c which could be 
> >>compiled on all systems.  It would have some sort of procedural 
> >>interface, and would grub around in target data to find thread X lwp 
> >>maps.  However, it could be written in a way that was host architecture 
> >>netural.
> >
> >
> >Sure.  But the design of libthread_db says, "I am 100% coupled to the
> >private structure of this thread implementation.  I must match its
> >version exactly if you want predictable results.  My details can change
> >in minor revisions or even more frequently."  That's not part of the
> >implementation; it's more like the purpose of the design.  It is a
> >layer between implementation-specific details with no guaranteed
> >structure and a structured client interface.
> 
> Right.
> 
> But what is stopping us picking up that code, compiling it on the host 
> (not target), and then using it in GDB?

Version skew primarily.  If you examine the way that libthread_db works
in GNU libc, you'll see that it knows the offset to various private
data structures by including the internal linuxthreads implementation
header.  These can change between minor point-releases of glibc.  We
could detect the version string and have lists of offsets that way but
it would mean updating GDB for every new version of glibc.  This is
probably feasible but mitigates the value of thread_db greatly; the
principal advantage was separating the debugger from knowledge of the
threads implementation.  We'd have to build target data structures (the
way that C++ ABI support does) and their types can vary greatly
architecture to architecture.  If we require libpthread.so to contain
debugging information it would be a little more practical, maybe...

On Solaris this isn't even an option of course.  If we don't use the
system libthread_db we have no way to duplicate its functionality.

> >Without imposing structure on that data, I don't think it'll ever be
> >possible to have a gdb/libthread-db.c.
> 
> We'll never be able to have a single libthread-db.c file but we should 
> at least be able to get the interface defined, and the code implemented, 
> in a way that makes it possible for it to be used on the host.

Perhaps for a limited set of (target arch, target lib version) pairs.

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

Re: GDB support for thread-local storage

[Andrew Cagney]

> I don't know.  HP people do monitor this list so may be able to answer.
>> 
> 
>> > But in any case, HP's gdbarch method for finding thread-local storage
>> > would be very simple: just add the offset to CR27, and there's your
>> > address.
> 
>> 
>> BTW, why, in your propsal, is the offset incorporated into the address
>> that is returned - rather than getting the base address and then
>> adding the offset - more like HP did.
> 
> 
> That's me imitating a rather weird quirk in the way the TLS run-time
> implementation works.  But if you look at my Dwarf 2 sketch proposal,
> we can't do it that way.  We need something that gives us the base
> address.  So the way HP does it is pretty much the way we'll do it,
> except for the assumption that the base address is in a register.

So an initial work-in-progress interface can be simplified to just:

	target_thread_base_address(thread, pc?, &base_addr)
		-> ok, not-available

dropping that offset et.al.?  Someone else can add them if they later 
prove necessary.

Andrew

Re: GDB support for thread-local storage

[Andrew Cagney]

> Sorry, I'm lost here.
>> 
>> Say, instead of a libthread_db, we had gdb/libthread-db.c which could be 
>> compiled on all systems.  It would have some sort of procedural 
>> interface, and would grub around in target data to find thread X lwp 
>> maps.  However, it could be written in a way that was host architecture 
>> netural.
> 
> 
> Sure.  But the design of libthread_db says, "I am 100% coupled to the
> private structure of this thread implementation.  I must match its
> version exactly if you want predictable results.  My details can change
> in minor revisions or even more frequently."  That's not part of the
> implementation; it's more like the purpose of the design.  It is a
> layer between implementation-specific details with no guaranteed
> structure and a structured client interface.

Right.

But what is stopping us picking up that code, compiling it on the host 
(not target), and then using it in GDB?

> Without imposing structure on that data, I don't think it'll ever be
> possible to have a gdb/libthread-db.c.

We'll never be able to have a single libthread-db.c file but we should 
at least be able to get the interface defined, and the code implemented, 
in a way that makes it possible for it to be used on the host.

Andrew

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 05:37:27PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote:
> > > Why aren't we using thread_db, though?  Why can't we run thread_db and
> > > simply serve its memory and register requests from the core file?  I
> > > don't see which part of the interface makes this impossible.  And
> > > we'll need to do it if Linux switches to an NxM thread model, no?
> > 
> > I should add to my previous comment that the use of libthread_db to
> > access TLS data means that such will never be possible in a core file,
> > either, without significant redesign of libthread_db - possibly as some
> > sort of data file which can be loaded separately from the coredump and
> > describe thread structures.
> 
> Well, if the core file support is willing to reach into the notes and
> construct a thread list, what's wrong with having it override the
> `thread_local_storage_get_address' target method, too?

Nothing, you're right.  Whether the corefile will have the details to
do this, however, without incorporating a large chunk of knowledge from
various target libthread_db systems, though - that's dubious at best. 
At least there is an ABI to guide us.

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

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 06:31:25PM -0400, Andrew Cagney wrote:
> 
> >>> I'd call the libthread_db
> >>>approach broken for this purpose (a little outside its design scope
> >>>perhaps).
> >
> >>
> >>I think it reflects limitations of the current libthread-db interface 
> >>rather than a broken approach.
> >
> >
> >I disagree... the concept of having a "libthread_db" with an interface
> >involves it being a target library, part of the system.  Unless you
> >change its "interface" to be a data file rather than code, it requires
> >access to a target in order to interpret target data.  That's my whole
> >objection to it.
> 
> Sorry, I'm lost here.
> 
> Say, instead of a libthread_db, we had gdb/libthread-db.c which could be 
> compiled on all systems.  It would have some sort of procedural 
> interface, and would grub around in target data to find thread X lwp 
> maps.  However, it could be written in a way that was host architecture 
> netural.

Sure.  But the design of libthread_db says, "I am 100% coupled to the
private structure of this thread implementation.  I must match its
version exactly if you want predictable results.  My details can change
in minor revisions or even more frequently."  That's not part of the
implementation; it's more like the purpose of the design.  It is a
layer between implementation-specific details with no guaranteed
structure and a structured client interface.

Without imposing structure on that data, I don't think it'll ever be
possible to have a gdb/libthread-db.c.

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

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 06:14:41PM -0500, Jim Blandy wrote:
> 
> One of the reasons I really like having libthread_db handle TLS
> resolution is that the alternative is to do an inferior function call
> when you reference a variable.  Check out Uli's document, at the
> pointer I gave --- even the compiler will sometimes have to generate a
> call to __tls_get_addr to find a __thread variable's address.
> 
> And GDB shouldn't cache this base address while the inferior runs,
> either --- remember the "GDB must never lie" rule.  Evaluating `x' in
> GDB had better reference the same storage that it would if the compiler
> evaluated `x' at the point where the program is stopped.
> 
> So if we have trouble keeping the Insight variable window up-to-date
> now...
> 
> Anyway, in that context, having libthread_db handle it all in-process
> seems really nice.

Well, libthread_db is still pretty expensive.  It generally does a
substantial amount of memory access to the inferior.  Cheaper than a
function call, but not so much.

Part of that is the ridiculous way we use it and abuse the thread_alive
checks at every opportunity.  If you benchmark some operations on
libthread_db/native gdb, and gdb/local gdbserver (which uses thread_db,
but makes some documented assumptions about the threading model, and
also supports partial stops which I haven't worked out how to do in GDB
proper) you'll see that the overhead of the remote protocol is
sometimes less than the overhead of native thread_db.

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

Re: GDB support for thread-local storage

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > Jim Blandy <jimb@redhat.com> writes:
> >
> >> Andrew Cagney <ac131313@cygnus.com> writes:
> >
> >> > Has solaris, or even MS, done anything in this area?  The
> >> > LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you
> >> > may want to look at what HP/UX is getting up to.
> >
> >> HP implements something much simpler.  It doesn't deal with
> >> thread-local storage in PIC code; the initialization image is laid out
> >> completely at static link time.  It's thread-local storage in
> >> dynamically loaded libraries that introduces all the hair.
> > What I wrote is incorrect.  HP does handle TLS in shared libraries.
> > But in their arrangement, every thread-local variable lives at a
> > offset from register CR27, and GDB can compute that offset at
> > symbol-reading time.
> > I think this means that they don't address a lot of the issues that
> > the IA-64 / SPARC / Red Hat proposal does.  I don't see how you'd
> > handle dlopen'd libraries or lazy allocation in their scheme.
> 
> I don't know.  HP people do monitor this list so may be able to answer.
> 
> > But in any case, HP's gdbarch method for finding thread-local storage
> > would be very simple: just add the offset to CR27, and there's your
> > address.
> 
> BTW, why, in your propsal, is the offset incorporated into the address
> that is returned - rather than getting the base address and then
> adding the offset - more like HP did.

That's me imitating a rather weird quirk in the way the TLS run-time
implementation works.  But if you look at my Dwarf 2 sketch proposal,
we can't do it that way.  We need something that gives us the base
address.  So the way HP does it is pretty much the way we'll do it,
except for the assumption that the base address is in a register.

Re: GDB support for thread-local storage

[Andrew Cagney]

> Jim Blandy <jimb@redhat.com> writes:
> 
>> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> > Has solaris, or even MS, done anything in this area?  The
>> > LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you
>> > may want to look at what HP/UX is getting up to.
> 
>> HP implements something much simpler.  It doesn't deal with
>> thread-local storage in PIC code; the initialization image is laid out
>> completely at static link time.  It's thread-local storage in
>> dynamically loaded libraries that introduces all the hair.
> 
> 
> What I wrote is incorrect.  HP does handle TLS in shared libraries.
> But in their arrangement, every thread-local variable lives at a
> offset from register CR27, and GDB can compute that offset at
> symbol-reading time.
> 
> I think this means that they don't address a lot of the issues that
> the IA-64 / SPARC / Red Hat proposal does.  I don't see how you'd
> handle dlopen'd libraries or lazy allocation in their scheme.

I don't know.  HP people do monitor this list so may be able to answer.

> But in any case, HP's gdbarch method for finding thread-local storage
> would be very simple: just add the offset to CR27, and there's your
> address.

BTW, why, in your propsal, is the offset incorporated into the address 
that is returned - rather than getting the base address and then adding 
the offset - more like HP did.

Andrew

Re: GDB support for thread-local storage

[Jim Blandy]

Jim Blandy <jimb@redhat.com> writes:
> Andrew Cagney <ac131313@cygnus.com> writes:
> > Has solaris, or even MS, done anything in this area?  The
> > LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you
> > may want to look at what HP/UX is getting up to.
> HP implements something much simpler.  It doesn't deal with
> thread-local storage in PIC code; the initialization image is laid out
> completely at static link time.  It's thread-local storage in
> dynamically loaded libraries that introduces all the hair.

What I wrote is incorrect.  HP does handle TLS in shared libraries.
But in their arrangement, every thread-local variable lives at a
offset from register CR27, and GDB can compute that offset at
symbol-reading time.

I think this means that they don't address a lot of the issues that
the IA-64 / SPARC / Red Hat proposal does.  I don't see how you'd
handle dlopen'd libraries or lazy allocation in their scheme.

But in any case, HP's gdbarch method for finding thread-local storage
would be very simple: just add the offset to CR27, and there's your
address.

Given that hpread.c hard-codes a reference to the macro CR27_REGNUM,
which is only defined in config/pa/tm-hppa.h, I assume that hpread.c
is only used in PA targets.  The PA hasn't been multi-arched, so I
assume it's going away.

So, does anyone care if I break the hpread.c code?

Re: GDB support for thread-local storage

[Jim Blandy]

One of the reasons I really like having libthread_db handle TLS
resolution is that the alternative is to do an inferior function call
when you reference a variable.  Check out Uli's document, at the
pointer I gave --- even the compiler will sometimes have to generate a
call to __tls_get_addr to find a __thread variable's address.

And GDB shouldn't cache this base address while the inferior runs,
either --- remember the "GDB must never lie" rule.  Evaluating `x' in
GDB had better reference the same storage that it would if the compiler
evaluated `x' at the point where the program is stopped.

So if we have trouble keeping the Insight variable window up-to-date
now...

Anyway, in that context, having libthread_db handle it all in-process
seems really nice.

Re: GDB support for thread-local storage

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > /* Get address of thread local variable.  */
> > extern td_err_e td_thr_tls_get_addr (const td_thrhandle_t *__th,
> >                                      struct link_map *__map, size_t __offset,
> >                                      void **__address);
> > This takes a thread handle, an entry from the dynamic linker's link
> > map, and an offset, and sets *__address to point to the base of that
> > thread and module's thread-local storage, plus the offset.  It returns
> > an error code if the space hasn't been allocated yet.
> 
> What does GDB do if there isn't [yet] any allocated local storage?

Oh, sorry --- what does *GDB* do?

It depends.  For the first cut, it returns an error:

    (gdb) print i
    Storage for the thread-local variable `i' has not been allocated in
    this thread yet.
    (gdb)

But there are ways we could do better than that.

It's tempting to suggest that referring to unallocated thread-local
storage should cause the storage to be allocated.  This emulates the
way variable references in the actual program behave most closely.

However, this is a pretty heavy-duty operation.  It involves calling a
function in the inferior, which will do a malloc, copy in the
initialization image, update thread structures, and so on.  I don't
think simply trying to print a variable should cause that kind of
disturbance in the inferior.

Instead, I think trying to print an unallocated __thread variable
should cause an error, which suggests that the user try a command
`thread allocate VAR', which will do the right inferior-disturbing
magic to make VAR exist.  That way, the user has control over the
process, and GDB doesn't munge her inferior in unexpected ways.

There is a middle ground.  Initializing a thread-local storage block
is simply a memcpy of the initialization image.  There are no relocs
to apply --- stuff like this:

        __thread int i;
        __thread int *pi = &i;

is forbidden.  This means that there's an exact copy of all the bits
each variable *would* have, if it *were* allocated --- they're just
immutable, and at the wrong address.

So a really clever implementation could actually give you the value of
a thread-local variable like `i' even when it hasn't been allocated
yet.  It would be a non-lazy value, not an lvalue, and have no
address, but at least `print i' would give you the right answer.  We
could even set a bit on the value so that an attempt to assign to it
would give a helpful error message:

    (gdb) set var i = 2
    Storage for the thread-local variable `i' has not been allocated
    in this thread yet.  Type `thread allocate i' to allocate it.
    (gdb)

Or something like that.

Anyway, that's why the gdbarch and target methods I proposed are
producing `struct value' objects, and not something more low-level ---
to leave open the option of handling unallocated values this way.

Re: GDB support for thread-local storage

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> > /* Get address of thread local variable.  */
>> > extern td_err_e td_thr_tls_get_addr (const td_thrhandle_t *__th,
>> >                                      struct link_map *__map, size_t __offset,
>> >                                      void **__address);
>> > This takes a thread handle, an entry from the dynamic linker's link
>> > map, and an offset, and sets *__address to point to the base of that
>> > thread and module's thread-local storage, plus the offset.  It returns
>> > an error code if the space hasn't been allocated yet.
> 
>> 
>> What does GDB do if there isn't [yet] any allocated local storage?
> 
> 
> It returns TD_NOTALLOC.

So, what does *GDB* do if there isn't [yet] any allocated local storage 
(as identified by the above function returning TD_NOTALLOC)?

Andrew

Re: GDB support for thread-local storage

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > /* Get address of thread local variable.  */
> > extern td_err_e td_thr_tls_get_addr (const td_thrhandle_t *__th,
> >                                      struct link_map *__map, size_t __offset,
> >                                      void **__address);
> > This takes a thread handle, an entry from the dynamic linker's link
> > map, and an offset, and sets *__address to point to the base of that
> > thread and module's thread-local storage, plus the offset.  It returns
> > an error code if the space hasn't been allocated yet.
> 
> What does GDB do if there isn't [yet] any allocated local storage?

It returns TD_NOTALLOC.

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote:
> > Why aren't we using thread_db, though?  Why can't we run thread_db and
> > simply serve its memory and register requests from the core file?  I
> > don't see which part of the interface makes this impossible.  And
> > we'll need to do it if Linux switches to an NxM thread model, no?
> 
> I should add to my previous comment that the use of libthread_db to
> access TLS data means that such will never be possible in a core file,
> either, without significant redesign of libthread_db - possibly as some
> sort of data file which can be loaded separately from the coredump and
> describe thread structures.

Well, if the core file support is willing to reach into the notes and
construct a thread list, what's wrong with having it override the
`thread_local_storage_get_address' target method, too?

Re: GDB support for thread-local storage

[Andrew Cagney]

>> > I'd call the libthread_db
>> >approach broken for this purpose (a little outside its design scope
>> >perhaps).
> 
>> 
>> I think it reflects limitations of the current libthread-db interface 
>> rather than a broken approach.
> 
> 
> I disagree... the concept of having a "libthread_db" with an interface
> involves it being a target library, part of the system.  Unless you
> change its "interface" to be a data file rather than code, it requires
> access to a target in order to interpret target data.  That's my whole
> objection to it.

Sorry, I'm lost here.

Say, instead of a libthread_db, we had gdb/libthread-db.c which could be 
compiled on all systems.  It would have some sort of procedural 
interface, and would grub around in target data to find thread X lwp 
maps.  However, it could be written in a way that was host architecture 
netural.

Andrew

Re: GDB support for thread-local storage

[Andrew Cagney]

> /* Get address of thread local variable.  */
> extern td_err_e td_thr_tls_get_addr (const td_thrhandle_t *__th,
>                                      struct link_map *__map, size_t __offset,
>                                      void **__address);
> 
> This takes a thread handle, an entry from the dynamic linker's link
> map, and an offset, and sets *__address to point to the base of that
> thread and module's thread-local storage, plus the offset.  It returns
> an error code if the space hasn't been allocated yet.

What does GDB do if there isn't [yet] any allocated local storage?

Andrew

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 05:46:05PM -0400, Andrew Cagney wrote:
> >This is the more substantial objection, it seems to me.  But simply
> >>because libthread_db can't be used for cross-platform core files
> >>doesn't mean we shouldn't use it in the native case --- for the same
> >>reasons we use it on live processes.
> >
> >
> >Maybe.... I don't think the analogy holds.  When we use it on live
> >processes there is always a system (somewhere) on which thread_db could
> >be running.  That's why I was willing to use it in gdbserver.  Of
> >course, it's ONE MORE library that needs to be on all my targets now,
> >which I'm not in love with.
> >
> >Debugging a core dump can't validly require access to a target.  So
> >making "native debug of a core dump" different from the hopeful "cross
> >debug of a core dump" seems a bit dodgy.
> 
> Yes.
> 
> > I'd call the libthread_db
> >approach broken for this purpose (a little outside its design scope
> >perhaps).
> 
> I think it reflects limitations of the current libthread-db interface 
> rather than a broken approach.

I disagree... the concept of having a "libthread_db" with an interface
involves it being a target library, part of the system.  Unless you
change its "interface" to be a data file rather than code, it requires
access to a target in order to interpret target data.  That's my whole
objection to it.

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

Re: GDB support for thread-local storage

[Andrew Cagney]

> This is the more substantial objection, it seems to me.  But simply
>> because libthread_db can't be used for cross-platform core files
>> doesn't mean we shouldn't use it in the native case --- for the same
>> reasons we use it on live processes.
> 
> 
> Maybe.... I don't think the analogy holds.  When we use it on live
> processes there is always a system (somewhere) on which thread_db could
> be running.  That's why I was willing to use it in gdbserver.  Of
> course, it's ONE MORE library that needs to be on all my targets now,
> which I'm not in love with.
> 
> Debugging a core dump can't validly require access to a target.  So
> making "native debug of a core dump" different from the hopeful "cross
> debug of a core dump" seems a bit dodgy.

Yes.

>  I'd call the libthread_db
> approach broken for this purpose (a little outside its design scope
> perhaps).

I think it reflects limitations of the current libthread-db interface 
rather than a broken approach.

Andrew

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 03:54:12PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Yes.  Search the archives to see the patch I committed to make this
> > "bug" happen instead of trying to use libthread_db; that message also
> > describes the problems.
> 
> Great, thanks.
> 
> > And if you're feeling ambitious, search for the message which describes
> > why it broke libthread_db support for static executables.  I haven't
> > thought of a solution yet.
> 
> I'm not that ambitious yet.
> 
> > > Why aren't we using thread_db, though?  Why can't we run thread_db and
> > > simply serve its memory and register requests from the core file?  I
> > > don't see which part of the interface makes this impossible.  And
> > > we'll need to do it if Linux switches to an NxM thread model, no?
> > 
> > It's not interface but implementation.  There's all sorts of places
> > where libthread_db wants to write to the inferior.  If you fake memory
> > writes, it is possible that this would work; I couldn't figure out how
> > to do that non-intrusively.
> 
> All the calls to ps_p[td]write I see in GNU's libthread_db have to do
> with the implementation of events.  Can't we just ignore those writes?
> Or better yet, make gdb/thread-db.c smart enough not to set event
> breakpoints in the first place when the underyling target doesn't have
> execution?

I tried that; there was some other problem.  It might have been in my
implementation.  Indeed upon looking back at it I see that you are
correct.  Maybe it would work.

> > Of much more interest to me is the fact that the LWP view of core files
> > can be supported cross-platform and the thread_db view of core files
> > can not be.  That is IMO a very substantial design flaw in
> > libthread_db.  Not a problem if all the world's a SPARC, but after the
> > effort I and others went through in order to make cross core debugging
> > functional I'm reluctant to use libthread_db anywhere I can avoid
> > it.
> 
> This is the more substantial objection, it seems to me.  But simply
> because libthread_db can't be used for cross-platform core files
> doesn't mean we shouldn't use it in the native case --- for the same
> reasons we use it on live processes.

Maybe.... I don't think the analogy holds.  When we use it on live
processes there is always a system (somewhere) on which thread_db could
be running.  That's why I was willing to use it in gdbserver.  Of
course, it's ONE MORE library that needs to be on all my targets now,
which I'm not in love with.

Debugging a core dump can't validly require access to a target.  So
making "native debug of a core dump" different from the hopeful "cross
debug of a core dump" seems a bit dodgy.  I'd call the libthread_db
approach broken for this purpose (a little outside its design scope
perhaps).

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

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> Yes.  Search the archives to see the patch I committed to make this
> "bug" happen instead of trying to use libthread_db; that message also
> describes the problems.

Great, thanks.

> And if you're feeling ambitious, search for the message which describes
> why it broke libthread_db support for static executables.  I haven't
> thought of a solution yet.

I'm not that ambitious yet.

> > Why aren't we using thread_db, though?  Why can't we run thread_db and
> > simply serve its memory and register requests from the core file?  I
> > don't see which part of the interface makes this impossible.  And
> > we'll need to do it if Linux switches to an NxM thread model, no?
> 
> It's not interface but implementation.  There's all sorts of places
> where libthread_db wants to write to the inferior.  If you fake memory
> writes, it is possible that this would work; I couldn't figure out how
> to do that non-intrusively.

All the calls to ps_p[td]write I see in GNU's libthread_db have to do
with the implementation of events.  Can't we just ignore those writes?
Or better yet, make gdb/thread-db.c smart enough not to set event
breakpoints in the first place when the underyling target doesn't have
execution?

> Of much more interest to me is the fact that the LWP view of core files
> can be supported cross-platform and the thread_db view of core files
> can not be.  That is IMO a very substantial design flaw in
> libthread_db.  Not a problem if all the world's a SPARC, but after the
> effort I and others went through in order to make cross core debugging
> functional I'm reluctant to use libthread_db anywhere I can avoid
> it.

This is the more substantial objection, it seems to me.  But simply
because libthread_db can't be used for cross-platform core files
doesn't mean we shouldn't use it in the native case --- for the same
reasons we use it on live processes.

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote:
> Why aren't we using thread_db, though?  Why can't we run thread_db and
> simply serve its memory and register requests from the core file?  I
> don't see which part of the interface makes this impossible.  And
> we'll need to do it if Linux switches to an NxM thread model, no?

I should add to my previous comment that the use of libthread_db to
access TLS data means that such will never be possible in a core file,
either, without significant redesign of libthread_db - possibly as some
sort of data file which can be loaded separately from the coredump and
describe thread structures.

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

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Fri, Jun 21, 2002 at 01:18:29PM -0400, Andrew Cagney wrote:
> > > >>BTW, what happens if the target doesn't have execution (i.e. a corefile).
> > > >
> > > >We fall down, just like we do debugging thread_db capable corefiles,
> > > >I'd imagine.  Thread_db does not like read-only targets very much.
> > > 
> > > GDB on a threaded GNU/Linux target, again falls down, sigh!  We can 
> > > hopefully have it working on other platforms.
> > 
> > I beg your pardon?  This is a thread_db limitation, not a GNU/Linux
> > limitation.  GNU/Linux copied the interface from Solaris and I believe
> > we use it on Solaris.  The effect there will be even more extreme than
> > on GNU/Linux.  <check> Yes, we do use it on Solaris.
> > 
> > If threaded corefiles work on Solaris I doubt it's by merit of
> > thread_db.
> 
> We can debug multi-threaded core files on Linux; see below.  I must be
> missing the point.  But this works because the core file reader
> actually goes and constructs the thread list itself.  We're not using
> thread_db to handle that.  Which is sort of a bug --- what you see
> when you run GDB on such a core file are LWP's, not threads.

Yes.  Search the archives to see the patch I committed to make this
"bug" happen instead of trying to use libthread_db; that message also
describes the problems.

And if you're feeling ambitious, search for the message which describes
why it broke libthread_db support for static executables.  I haven't
thought of a solution yet.

> Why aren't we using thread_db, though?  Why can't we run thread_db and
> simply serve its memory and register requests from the core file?  I
> don't see which part of the interface makes this impossible.  And
> we'll need to do it if Linux switches to an NxM thread model, no?

It's not interface but implementation.  There's all sorts of places
where libthread_db wants to write to the inferior.  If you fake memory
writes, it is possible that this would work; I couldn't figure out how
to do that non-intrusively.

Of much more interest to me is the fact that the LWP view of core files
can be supported cross-platform and the thread_db view of core files
can not be.  That is IMO a very substantial design flaw in
libthread_db.  Not a problem if all the world's a SPARC, but after the
effort I and others went through in order to make cross core debugging
functional I'm reluctant to use libthread_db anywhere I can avoid it.

An M:N implementation of libthread_db is even more likely to want to
write to or signal the inferior process.  I don't know if Sun's handles
this gracefully or if they grub through the corefile looking for
threads like we do.

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

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Fri, Jun 21, 2002 at 01:18:29PM -0400, Andrew Cagney wrote:
> > >>BTW, what happens if the target doesn't have execution (i.e. a corefile).
> > >
> > >We fall down, just like we do debugging thread_db capable corefiles,
> > >I'd imagine.  Thread_db does not like read-only targets very much.
> > 
> > GDB on a threaded GNU/Linux target, again falls down, sigh!  We can 
> > hopefully have it working on other platforms.
> 
> I beg your pardon?  This is a thread_db limitation, not a GNU/Linux
> limitation.  GNU/Linux copied the interface from Solaris and I believe
> we use it on Solaris.  The effect there will be even more extreme than
> on GNU/Linux.  <check> Yes, we do use it on Solaris.
> 
> If threaded corefiles work on Solaris I doubt it's by merit of
> thread_db.

We can debug multi-threaded core files on Linux; see below.  I must be
missing the point.  But this works because the core file reader
actually goes and constructs the thread list itself.  We're not using
thread_db to handle that.  Which is sort of a bug --- what you see
when you run GDB on such a core file are LWP's, not threads.

Why aren't we using thread_db, though?  Why can't we run thread_db and
simply serve its memory and register requests from the core file?  I
don't see which part of the interface makes this impossible.  And
we'll need to do it if Linux switches to an NxM thread model, no?


$ ps xf
  PID TTY      STAT   TIME COMMAND
...
 9415 pts/1    S      0:00 -bash
...
28675 pts/1    S      0:00  \_ ./linux-dp
28676 pts/1    S      0:00      \_ ./linux-dp
28677 pts/1    S      0:00          \_ ./linux-dp
28678 pts/1    S      0:00          \_ ./linux-dp
28679 pts/1    S      0:00          \_ ./linux-dp
28680 pts/1    S      0:00          \_ ./linux-dp
28681 pts/1    S      0:00          \_ ./linux-dp
...
$ gdb -nw linux-dp
GNU gdb 2002-06-13-cvs
Copyright 2002 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 "i686-pc-linux-gnu"...
(gdb) attach 28675
Attaching to program: /rigel/jimb/cygnus/pentium3/sourceware/gdb/main/native/build/gdb/testsuite/gdb.threads/linux-dp, process 28675
Reading symbols from /lib/i686/libpthread.so.0...done.
[New Thread 1024 (LWP 28675)]
[New Thread 2049 (LWP 28676)]
[New Thread 1026 (LWP 28677)]
[New Thread 2051 (LWP 28678)]
[New Thread 3076 (LWP 28679)]
[New Thread 4101 (LWP 28680)]
[New Thread 5126 (LWP 28681)]
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x4011a5a1 in __libc_nanosleep () at __libc_nanosleep:-1
-1      __libc_nanosleep: No such file or directory.
        in __libc_nanosleep
(gdb) gcore linux-dp.core
Saved corefile linux-dp.core
(gdb) The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /rigel/jimb/cygnus/pentium3/sourceware/gdb/main/native/build/gdb/testsuite/gdb.threads/linux-dp, process 28675
$ readelf -n linux-dp.core

Notes at offset 0x00000354 with length 0x000016dc:
  Owner         Data size       Description
  CORE          0x0000007c      NT_PRPSINFO (prpsinfo structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
  CORE          0x00000090      NT_PRSTATUS (prstatus structure)
  CORE          0x0000006c      NT_FPREGSET (floating point registers)
  LINUX         0x00000200      NT_PRXFPREG (user_xfpregs structure)
$ gdb -nw linux-dp
GNU gdb 2002-06-13-cvs
Copyright 2002 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 "i686-pc-linux-gnu"...
(gdb) core linux-dp.core
warning: core file may not match specified executable file.
Core was generated by `/rigel/jimb/cygnus/pentium3/sourceware/gdb/main/native/build/gdb/testsuite/gdb.t'.
Program terminated with signal 17, Child status changed.
Reading symbols from /lib/i686/libpthread.so.0...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x40146afe in __select () at __select:-1
-1      __select: No such file or directory.
        in __select
(gdb) info thread
  7 process 67137539  0x4011a5a1 in __libc_nanosleep () at __libc_nanosleep:-1
  6 process 134311939  0x401453e7 in __poll (fds=0x804bddc, nfds=1, 
    timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63
  5 process 67268611  0x4008dba5 in __sigsuspend (set=0x4039a98c)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
  4 process 134443011  0x40146afe in __select () at __select:-1
  3 process 201617411  0x4008dba5 in __sigsuspend (set=0x4079a98c)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
  2 process 268791811  0x40146afe in __select () at __select:-1
* 1 process 335966211  0x40146afe in __select () at __select:-1
(gdb) 

Re: GDB support for thread-local storage

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > For STABS, we can simply invent a new symbol type, whose value is the
> > offset within the thread-local storage block for the current thread
> > for the module containing the stab.  I haven't written up a real
> > proposal for STABS yet.
> > On Linux, Ulrich Drepper has added the following function to
> > libthread_db:
> 
> Has solaris, or even MS, done anything in this area?  The
> LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you
> may want to look at what HP/UX is getting up to.

I didn't see anything in the Solaris "Stabs Interface Manual"
(distributed with the Solaris toolchain, not publicly) about it.

HP implements something much simpler.  It doesn't deal with
thread-local storage in PIC code; the initialization image is laid out
completely at static link time.  It's thread-local storage in
dynamically loaded libraries that introduces all the hair.

> > If you're not convinced it should be a target method, consider this:
> > Remember that libthread_db isn't clean for cross-debugging.  It's a
> > target library.  So at the moment, there are cases where gdbserver
> > loads and uses libthread_db, not GDB itself.  In those cases, the
> > tls_get_addr request needs to be sent across the network connection to
> > gdbserver, td_thr_tls_get_addr needs to be invoked there, and the
> > answer needs to be sent back.  By making tls_get_addr a target method,
> > it's easy for the remote protocol layer to provide its own definition
> > of the method and send a packet across for the request.
> 
> Similar to this, both SOFTWARE_SINGLESTEP and hardware breakpoints are
> ment to be implemented with support from both the target vector and
> the architecture vector.  By doing that, a sequence like:
> 
> 	can target single step?
> 	  yes, step target
> 	else
> 	  use architecture to software singlestep target
> 
> can be implemented (in both cases it isn't so it can't, ulgh).

Yes, I remember you saying this before; I was trying to follow your
lead here.

> However, in the case of the above, is the architecture method needed?
> Given that th only thing implementing this will be the above GNU/Linux
> thread-db library, and GDB's linux thread code will know to call that
> directly.

I don't think that's so.  As I say, Uli is pretty much just following
what the IA-64 and SPARC people have done for their ABI's, and
introducing a new scheme for the IA-32.  So we should expect this
feature to crop up on other platforms.

As far as the gdbarch method is concerned, I dunno.  It's true that
nobody is actually going to define the method at the moment.  But I
don't see why embedded ABI's wouldn't want to support __thread; the
whole point is that __thread can be faster and have less overhead than
the pthreads alternative, which (it seems to me) would make it very
attractive to the embedded world.  So I would expect the gdbarch
method to be used for the first embedded ABI that supports __thread.

Should we put off adding the gdbarch method until someone is actually
going to define it?

Re: GDB support for thread-local storage

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > I've posted a note to the Dwarf mailing list, describing the
> > DW_OP_push_tls_address approach, and saying that we'll experiment with
> > this as a GNU extension to Dwarf and write back when we've actually
> > got something working.
> 
> Hmm, would you be able to post the prososal here?

Sure thing.  (I re-used most of the language in the Dwarf proposal in
the message you replied to, so you've seen almost all of it already.)

Something to make clear, though --- this isn't a "proposal" proper.
The way the Dwarf committee operates (or the way I think it should
operate, and thus the way I try to deal with it) is:

- you float an idea by them for general approval;
- then you go off and implement it as a vendor extension;
- then once you've got it actually working you come back and make it a
  real proposal;
- if it's accepted you get assigned proper numbers (not in the vendor
  extension range) for your attribute tags, die tags, and so on;
- and finally you switch your emitter to recognize the real numbers.

So this is in the "float an idea by them" stage.  Very preliminary.


$Id: dwarf,v 1.4 2002/06/12 21:44:14 jimb Exp $

(The function of DW_OP_push_tls_address is similar to that of the
run-time function __get_tls_addr, so it was tempting to name the
operation DW_OP_get_tls_addr.  However, DW_OP_push_tls_address is more
consistent with the names of the other operations, especially
DW_OP_push_object_address.)


To section 2.4.1.3, "Stack Operations", add the following paragraphs
after DW_OP_push_object_address:

12. DW_OP_push_tls_address

The DW_OP_push_tls_address operation pushes the base address of the
current thread's thread-local storage block.  If the expression occurs
in the Dwarf information for a dynamically loaded library, then
DW_OP_push_tls_address pushes the base address of that library's block
for the current thread.  If the library's storage for the current
thread has not yet been allocated, a Dwarf consumer may arrange for it
to be allocated now, or report an error to the user.

<rationale italics>
Some implementations of C and C++ support a ``__thread'' storage
class, for variables that occupy distinct memory in distinct threads.
For example, the definition:

       __thread int foo;

declares an integer variable named ``foo'' which has a separate value
and address in each thread, much as a variable declared ``auto'' has a
separate value and address in each invocation of the function
containing its declaration.  Creating a new thread creates a new
instance of ``foo'', and when the thread exits, the storage for
``foo'' is freed.

Typically, a program includes an ``initialization image'' --- a block
of memory containing the initial values for any thread-local variables
it defines.  When the program creates a new thread, the run-time
system allocates a fresh block of memory for those thread-local
variables, and copies the initialization image into it to give the
variables their initialized values.

A dynamically loaded library may also define thread-local variables.
Some implementations delay allocating memory for such variables until
the thread actually refers to them for the first time.  This avoids
the overhead of allocating and initializing the library's thread-local
storage for all the threads present in a program when the library is
loaded, even though only a few threads might actually use the library.

However, when an implementation allocates thread-local storage on
demand, this makes it hard to describe the location of a thread-local
variable using ordinary Dwarf expressions: referencing the storage may
entail allocating memory, copying an initialization image into place,
registering it with the thread, and so on.  A dedicated operation like
DW_OP_push_tls_address leaves this complicated task to the debugger,
which is presumably already familiar with the program's ABI and thread
system, and can handle the request appropriately.
</rationale italics>

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Fri, Jun 21, 2002 at 01:18:29PM -0400, Andrew Cagney wrote:
> >>BTW, what happens if the target doesn't have execution (i.e. a corefile).
> >>
> 
> >
> >We fall down, just like we do debugging thread_db capable corefiles,
> >I'd imagine.  Thread_db does not like read-only targets very much.
> 
> GDB on a threaded GNU/Linux target, again falls down, sigh!  We can 
> hopefully have it working on other platforms.

I beg your pardon?  This is a thread_db limitation, not a GNU/Linux
limitation.  GNU/Linux copied the interface from Solaris and I believe
we use it on Solaris.  The effect there will be even more extreme than
on GNU/Linux.  <check> Yes, we do use it on Solaris.

If threaded corefiles work on Solaris I doubt it's by merit of
thread_db.

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

Re: GDB support for thread-local storage

[Andrew Cagney]

>> BTW, what happens if the target doesn't have execution (i.e. a corefile).
>> 

> 
> We fall down, just like we do debugging thread_db capable corefiles,
> I'd imagine.  Thread_db does not like read-only targets very much.

GDB on a threaded GNU/Linux target, again falls down, sigh!  We can 
hopefully have it working on other platforms.

Andrew

Re: GDB support for thread-local storage

[Daniel Jacobowitz]

On Thu, Jun 20, 2002 at 09:35:25PM -0400, Andrew Cagney wrote:
> However, in the case of the above, is the architecture method needed? 
> Given that th only thing implementing this will be the above GNU/Linux 
> thread-db library, and GDB's linux thread code will know to call that 
> directly.
> 
> BTW, what happens if the target doesn't have execution (i.e. a corefile).

We fall down, just like we do debugging thread_db capable corefiles,
I'd imagine.  Thread_db does not like read-only targets very much.

> Andrew
> 
> (Use thread_local_static rather than thr_tls in function names)

_storage, I think?

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

Re: GDB support for thread-local storage

[Andrew Cagney]

> I've posted a note to the Dwarf mailing list, describing the
> DW_OP_push_tls_address approach, and saying that we'll experiment with
> this as a GNU extension to Dwarf and write back when we've actually
> got something working.

Hmm, would you be able to post the prososal here?

> For STABS, we can simply invent a new symbol type, whose value is the
> offset within the thread-local storage block for the current thread
> for the module containing the stab.  I haven't written up a real
> proposal for STABS yet.
> 
> On Linux, Ulrich Drepper has added the following function to
> libthread_db:

Has solaris, or even MS, done anything in this area?  The 
LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you may 
want to look at what HP/UX is getting up to.

> If you're not convinced it should be a target method, consider this:
> Remember that libthread_db isn't clean for cross-debugging.  It's a
> target library.  So at the moment, there are cases where gdbserver
> loads and uses libthread_db, not GDB itself.  In those cases, the
> tls_get_addr request needs to be sent across the network connection to
> gdbserver, td_thr_tls_get_addr needs to be invoked there, and the
> answer needs to be sent back.  By making tls_get_addr a target method,
> it's easy for the remote protocol layer to provide its own definition
> of the method and send a packet across for the request.

Similar to this, both SOFTWARE_SINGLESTEP and hardware breakpoints are 
ment to be implemented with support from both the target vector and the 
architecture vector.  By doing that, a sequence like:

	can target single step?
	  yes, step target
	else
	  use architecture to software singlestep target

can be implemented (in both cases it isn't so it can't, ulgh).

However, in the case of the above, is the architecture method needed? 
Given that th only thing implementing this will be the above GNU/Linux 
thread-db library, and GDB's linux thread code will know to call that 
directly.

BTW, what happens if the target doesn't have execution (i.e. a corefile).

Andrew

(Use thread_local_static rather than thr_tls in function names)

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Berlin <dberlin@dberlin.org> writes:
> > The function one may need to invoke to find thread-local storage,
> > __tls_get_addr, is an actual native code function, in the dynamic
> > linker.  The DW_OP_call_* operations allow a Dwarf expression to call
> > another Dwarf expression like a function.  But you can't use the
> > DW_OP_call_* operations to invoke machine-language functions in the
> > inferior.
> 
> You've assumed you need to.
> If you can transform tls_get_addr into a dwarf expression, there you go.
> You can deref memory, you just can't store into it.
> Since the TLS address is just a location somewhere, computed without 
> modifying anything, one should be able to transform it pretty easily.
> 
> Not that this is the best idea, but it's a possibility.
> :)

We did try to find a way to just express this as a Dwarf expression,
before we resorted to a custom opcode and a libthread_db function.

One objection was that this would embed knowledge about the
implementation of TLS in the executable's debugging info.  The way to
find TLS can change depending on which dynamic linker and thread
library you happen to be (dynamically) linking against.  The process
for finding TLS really should be tightly coupled with the actual
dynamic linker and thread library in use, the way libthread_db is.

One could put the right Dwarf expression in the thread library or
dynamic linker's debugging info, and use DW_OP_call* to invoke it that
way --- that would get the coupling right.  But GDB doesn't apply
dynamic relocs to its debugging info (and it's hard to see exactly how
it could without a lot more help from the dynamic linker --- see Uli's
TLS paper).  This makes it hard to get the right operand for the
DW_OP_call4/8/whathaveyou.

There is also another problem I didn't mention.  You need to know the
module number in order to look up its TLS.  The dynamic linker doesn't
assign the module a number until it's loaded.  But perhaps the Dwarf
expression could actually get that from a GOT entry.

Re: GDB support for thread-local storage

[Daniel Berlin]

On 19 Jun 2002, Jim Blandy wrote:

> 
> Daniel Berlin <dberlin@dberlin.org> writes:
> > > Unfortunately, Dwarf 2 location expressions cannot perform function
> > > calls in the inferior. 
> > 
> > Errr, buzz.
> > 
> > See DW_OP_call_*  in dwarf3
> 
> (As I wrote that sentence, I was wondering whether I should clarify
> this point.)
> 
> The function one may need to invoke to find thread-local storage,
> __tls_get_addr, is an actual native code function, in the dynamic
> linker.  The DW_OP_call_* operations allow a Dwarf expression to call
> another Dwarf expression like a function.  But you can't use the
> DW_OP_call_* operations to invoke machine-language functions in the
> inferior.

You've assumed you need to.
If you can transform tls_get_addr into a dwarf expression, there you go.
You can deref memory, you just can't store into it.
Since the TLS address is just a location somewhere, computed without 
modifying anything, one should be able to transform it pretty easily.

Not that this is the best idea, but it's a possibility.
:)

 > 
> > It's not just turing complete anymore, one could probably write useful 
> > application extensions in dwarf3.
> > Scary.
> 
> I thought so too, but then I noticed that there are no memory store
> operations.  You can do stuff on the stack, but you can't modify
> memory, or do any I/O.  Grave omissions, which should be rectified
> immediately.

I'm on it.
It also needs a DW_OP_fix_bug
> 

Re: GDB support for thread-local storage

[Jim Blandy]

Daniel Berlin <dberlin@dberlin.org> writes:
> > Unfortunately, Dwarf 2 location expressions cannot perform function
> > calls in the inferior. 
> 
> Errr, buzz.
> 
> See DW_OP_call_*  in dwarf3

(As I wrote that sentence, I was wondering whether I should clarify
this point.)

The function one may need to invoke to find thread-local storage,
__tls_get_addr, is an actual native code function, in the dynamic
linker.  The DW_OP_call_* operations allow a Dwarf expression to call
another Dwarf expression like a function.  But you can't use the
DW_OP_call_* operations to invoke machine-language functions in the
inferior.

> It's not just turing complete anymore, one could probably write useful 
> application extensions in dwarf3.
> Scary.

I thought so too, but then I noticed that there are no memory store
operations.  You can do stuff on the stack, but you can't modify
memory, or do any I/O.  Grave omissions, which should be rectified
immediately.

Re: GDB support for thread-local storage

[Daniel Berlin]

On Wed, 19 Jun 2002, Jim Blandy wrote:

> 
> I'd like to extend GDB to support thread-local variables.  Richard
> Henderson, Ulrich Drepper and I have come up with some pieces of the
> solutions; pretty much everything outside GDB has been settled, but
> I'm still trying to figure out how GDB will pull the pieces together.
> 
> This post describes:
> - the feature we're trying to support,
> - the parts we've worked out so far, and
> - the parts in GDB that I'm still trying to sort out.
> 
> Some implementations of C and C++ support a ``__thread'' storage
> class, for variables that occupy distinct memory in distinct threads.
> For example, the definition:
> 
>        __thread int foo;
> 
> declares an integer variable named ``foo'' which has a separate value
> and address in each thread, much as a variable declared ``auto'' has a
> separate value and address in each invocation of the function
> containing its declaration.  Creating a new thread creates a new
> instance of ``foo'', and when the thread exits, the storage for
> ``foo'' is freed.
> 
> Typically, a program includes an ``initialization image'' --- a block
> of memory containing the initial values for any thread-local variables
> it defines.  When the program creates a new thread, the run-time
> system allocates a fresh block of memory for those thread-local
> variables, and copies the initialization image into it to give the
> variables their initialized values.
> 
> A dynamically loaded library may also define thread-local variables.
> Some implementations delay allocating memory for such variables until
> the thread actually refers to them for the first time.  This avoids
> the overhead of allocating and initializing the library's thread-local
> storage for all the threads present in a program when the library is
> loaded, even though only a few threads might actually use the library.
> 
> Thread-local storage requires support in the ABI, and support in the
> dynamic linker, if you want reasonable performance.  There's a
> complete description of how it's done on the IA-32, IA-64, and SPARC
> at http://people.redhat.com/drepper/tls.pdf.  This is based on
> specifications already written for the IA-64 and SPARC; I think the
> IA-32 implementation is Ulrich Drepper's work.
> 
> For GDB, the first question is: how should the debugging information
> describe the location of a thread-local variable?  We generally answer
> this sort of question by looking at how the code generated by the
> compiler finds the variable, and then emitting debugging information
> that matches that.
> 
> To allow the run-time system to allocate thread-local storage on
> demand, the ABI in certain circumstances requires the compiler to emit
> a call to a function, __tls_get_addr, to find the address of a
> thread-local variable for the current thread and a particular module.
> This function looks up the address in a table, allocates and
> initializes the storage if necessary, and returns its address.
> 
> Unfortunately, Dwarf 2 location expressions cannot perform function
> calls in the inferior. 

Errr, buzz.

See DW_OP_call_*  in dwarf3


It's not just turing complete anymore, one could probably write useful 
application extensions in dwarf3.
Scary.

--Dan

GDB support for thread-local storage

[Jim Blandy]

I'd like to extend GDB to support thread-local variables.  Richard
Henderson, Ulrich Drepper and I have come up with some pieces of the
solutions; pretty much everything outside GDB has been settled, but
I'm still trying to figure out how GDB will pull the pieces together.

This post describes:
- the feature we're trying to support,
- the parts we've worked out so far, and
- the parts in GDB that I'm still trying to sort out.

Some implementations of C and C++ support a ``__thread'' storage
class, for variables that occupy distinct memory in distinct threads.
For example, the definition:

       __thread int foo;

declares an integer variable named ``foo'' which has a separate value
and address in each thread, much as a variable declared ``auto'' has a
separate value and address in each invocation of the function
containing its declaration.  Creating a new thread creates a new
instance of ``foo'', and when the thread exits, the storage for
``foo'' is freed.

Typically, a program includes an ``initialization image'' --- a block
of memory containing the initial values for any thread-local variables
it defines.  When the program creates a new thread, the run-time
system allocates a fresh block of memory for those thread-local
variables, and copies the initialization image into it to give the
variables their initialized values.

A dynamically loaded library may also define thread-local variables.
Some implementations delay allocating memory for such variables until
the thread actually refers to them for the first time.  This avoids
the overhead of allocating and initializing the library's thread-local
storage for all the threads present in a program when the library is
loaded, even though only a few threads might actually use the library.

Thread-local storage requires support in the ABI, and support in the
dynamic linker, if you want reasonable performance.  There's a
complete description of how it's done on the IA-32, IA-64, and SPARC
at http://people.redhat.com/drepper/tls.pdf.  This is based on
specifications already written for the IA-64 and SPARC; I think the
IA-32 implementation is Ulrich Drepper's work.

For GDB, the first question is: how should the debugging information
describe the location of a thread-local variable?  We generally answer
this sort of question by looking at how the code generated by the
compiler finds the variable, and then emitting debugging information
that matches that.

To allow the run-time system to allocate thread-local storage on
demand, the ABI in certain circumstances requires the compiler to emit
a call to a function, __tls_get_addr, to find the address of a
thread-local variable for the current thread and a particular module.
This function looks up the address in a table, allocates and
initializes the storage if necessary, and returns its address.

Unfortunately, Dwarf 2 location expressions cannot perform function
calls in the inferior.  We could extend it to do this, but inferior
function calls are rather complicated (look at the *_push_arguments
functions and hand_function_call in GDB); I don't think this is a good
idea.

Instead, I've suggested adding a new Dwarf 2 opcode: 

    12. DW_OP_push_tls_address

    The DW_OP_push_tls_address operation pushes the base address of the
    current thread's thread-local storage block.  If the expression occurs
    in the Dwarf information for a dynamically loaded library, then
    DW_OP_push_tls_address pushes the base address of that library's block
    for the current thread.  If the library's storage for the current
    thread has not yet been allocated, a Dwarf consumer may arrange for it
    to be allocated now, or report an error to the user.

When an implementation allocates thread-local storage on demand, this
makes it hard to describe the location of a thread-local variable
using ordinary Dwarf expressions: referencing the storage may entail
allocating memory, copying an initialization image into place,
registering it with the thread, and so on.  A dedicated operation like
DW_OP_push_tls_address leaves this complicated task to the debugger,
which is presumably already familiar with the program's ABI and thread
system, and can handle the request appropriately.

I've posted a note to the Dwarf mailing list, describing the
DW_OP_push_tls_address approach, and saying that we'll experiment with
this as a GNU extension to Dwarf and write back when we've actually
got something working.

For STABS, we can simply invent a new symbol type, whose value is the
offset within the thread-local storage block for the current thread
for the module containing the stab.  I haven't written up a real
proposal for STABS yet.

On Linux, Ulrich Drepper has added the following function to
libthread_db:

/* Get address of thread local variable.  */
extern td_err_e td_thr_tls_get_addr (const td_thrhandle_t *__th,
                                     struct link_map *__map, size_t __offset,
                                     void **__address);

This takes a thread handle, an entry from the dynamic linker's link
map, and an offset, and sets *__address to point to the base of that
thread and module's thread-local storage, plus the offset.  It returns
an error code if the space hasn't been allocated yet.

Note that this interface is not cross-debugging clean.  Actually, none
of the libthread_db interface is --- the underlying proc_service
interface uses the hosts' `paddr_t' type to represent addresses in the
running program, and the top-side interface uses `void *' to represent
the location of thread-local data, and in the function above.  More on
this later.


So now we get to the part which isn't really sorted out yet, in my
opinion.  There's a lot that needs to happen between the point where
GDB reads debugging information for a thread-local variable, and the
point where GDB can find a thread-local variable's value.

GDB already has an address class apparently intended for describing
thread-local data.  In symtab.h:

    enum address_class
      {
        ...

        /* Value is at a thread-specific location calculated by a
           target-specific method. */

        LOC_THREAD_LOCAL_STATIC,

        ...
      };

It would be more proper for that comment to say that the location is
calculated by an ABI-specific method.  There needs to be a new gdbarch
method:

  /* return a `struct value' for the object of type TYPE at OFFSET in
     the thread-local storage block for THREAD and MODULE.  If the
     thread-local storage block hasn't been allocated yet, raise an
     error.  */
  struct value *gdbarch_tls_get_value (struct thread_info *thread,
                                       struct objfile *module,
                                       LONGEST offset,
                                       struct type *type);

In order for this to reach the thread layer where we can call
libthread_db, there will need to be a new target stack method as well,
which the gdbarch method can invoke if it pleases.  Something similar
to the gdbarch method:

    struct value *(*to_tls_get_addr) (struct thread_info *thread,
                                      struct objfile *module,
                                      LONGEST offset,
                                      struct type *type);

The default implementation will raise an error, saying we don't know
how to find thread-local storage on this system.  The libthread_db
target will override that default with something that calls
td_thr_tls_get_addr.

If you're not convinced it should be a target method, consider this:
Remember that libthread_db isn't clean for cross-debugging.  It's a
target library.  So at the moment, there are cases where gdbserver
loads and uses libthread_db, not GDB itself.  In those cases, the
tls_get_addr request needs to be sent across the network connection to
gdbserver, td_thr_tls_get_addr needs to be invoked there, and the
answer needs to be sent back.  By making tls_get_addr a target method,
it's easy for the remote protocol layer to provide its own definition
of the method and send a packet across for the request.