public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* [maint] The GDB maintenance process
@ 2003-02-17 18:07 Daniel Jacobowitz
  2003-02-17 21:01 ` Elena Zannoni
                   ` (6 more replies)
  0 siblings, 7 replies; 101+ messages in thread
From: Daniel Jacobowitz @ 2003-02-17 18:07 UTC (permalink / raw)
  To: gdb

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

^ permalink raw reply	[flat|nested] 101+ messages in thread
* GDB support for thread-local storage
@ 2002-06-19  9:00 Jim Blandy
  2002-06-19 10:08 ` Daniel Berlin
                   ` (2 more replies)
  0 siblings, 3 replies; 101+ messages in thread
From: Jim Blandy @ 2002-06-19  9:00 UTC (permalink / raw)
  To: gdb


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.

^ permalink raw reply	[flat|nested] 101+ messages in thread
end of thread, other threads:[~2003-10-11  2:21 UTC | newest]

Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1024952640.13693.ezmlm@sources.redhat.com>
2002-06-25  1:48 ` GDB support for thread-local storage James Cownie
2002-06-25  8:05   ` Daniel Jacobowitz
2002-06-25  8:31     ` James Cownie
2002-06-25  8:42       ` Daniel Jacobowitz
2002-06-25  8:53         ` James Cownie
2002-06-25  8:56           ` Daniel Jacobowitz
2002-06-25  9:11             ` James Cownie
2002-06-25  9:29               ` Daniel Jacobowitz
2002-06-25 10:44             ` Andrew Cagney
2002-06-25 10:02               ` Daniel Jacobowitz
2002-06-26 12:45                 ` Jim Blandy
2002-06-26 19:31                   ` Andrew Cagney
2002-06-26 21:57                     ` Jim Blandy
2002-06-27  8:13                       ` Andrew Cagney
2002-08-19  9:05                       ` Daniel Jacobowitz
2003-02-17 18:07 [maint] The GDB maintenance process Daniel Jacobowitz
2003-02-17 21:01 ` Elena Zannoni
2003-02-19  1:49   ` Daniel Jacobowitz
2003-02-19  2:26     ` Joel Brobecker
2003-02-19 15:43       ` Andrew Cagney
2003-02-19 16:29         ` Daniel Jacobowitz
2003-02-19 22:04           ` Andrew Cagney
2003-02-19 13:24     ` Daniel Berlin
2003-02-19 15:51       ` Andrew Cagney
2003-02-19 14:50     ` Andrew Cagney
2003-02-19 17:33       ` David Carlton
2003-02-19 17:57         ` Kevin Buettner
2003-02-19 18:56           ` Andrew Cagney
2003-02-19 20:39             ` Christopher Faylor
2003-02-19 23:17               ` Jason Molenda
2003-02-20  1:53                 ` Christopher Faylor
2003-02-19 19:35           ` David Carlton
2003-02-20 18:32       ` Richard Earnshaw
2003-02-22  0:53         ` Andrew Cagney
2003-02-19 15:12     ` Andrew Cagney
2003-02-19 15:21       ` Daniel Jacobowitz
2003-02-19 16:24         ` Andrew Cagney
2003-02-19 18:36           ` Christopher Faylor
2003-02-19 23:36           ` Jason Molenda
2003-02-19 23:52             ` Andrew Cagney
2003-02-19 23:59               ` Jason Molenda
2003-02-20  0:16                 ` Elena Zannoni
2003-02-20  0:21                 ` Andrew Cagney
2003-02-18  2:39 ` Andrew Cagney
2003-02-18  4:28 ` Andrew Cagney
2003-02-19  3:49   ` Jim Blandy
2003-02-19 16:14     ` Andrew Cagney
2003-02-19 16:31       ` Daniel Jacobowitz
2003-02-19  2:24 ` Jim Blandy
2003-02-19 16:33   ` Andrew Cagney
2003-02-19 22:24     ` Jim Blandy
2003-02-19 22:39       ` Christopher Faylor
2003-02-19 22:53         ` Andrew Cagney
2003-02-19 23:53       ` Elena Zannoni
2003-02-20  1:27         ` Andrew Cagney
2003-02-20  2:48   ` Andrew Cagney
2003-02-21 23:43   ` Andrew Cagney
2003-02-21 23:57   ` Andrew Cagney
2003-02-19  6:05 ` David Carlton
2003-02-23 23:26 ` Mark Kettenis
2003-02-24  7:18   ` Andrew Cagney
     [not found] ` <drow@mvista.com>
2003-02-17 18:58   ` Kevin Buettner
2003-10-10 15:30   ` Unambiguously specifying source locations Daniel Jacobowitz
2003-10-10 15:44     ` David Ayers
2003-10-10 15:46       ` Daniel Jacobowitz
2003-10-11  2:21     ` Felix Lee
  -- strict thread matches above, loose matches on Subject: below --
2002-06-19  9:00 GDB support for thread-local storage Jim Blandy
2002-06-19 10:08 ` Daniel Berlin
2002-06-19 12:20   ` Jim Blandy
2002-06-19 13:12     ` Daniel Berlin
2002-06-19 13:40       ` Jim Blandy
2002-06-20 18:35 ` Andrew Cagney
2002-06-20 18:48   ` Daniel Jacobowitz
2002-06-21 10:18     ` Andrew Cagney
2002-06-21 10:32       ` Daniel Jacobowitz
2002-06-21 13:08         ` Jim Blandy
2002-06-21 13:18           ` Daniel Jacobowitz
2002-06-21 13:54             ` Jim Blandy
2002-06-21 14:03               ` Daniel Jacobowitz
2002-06-21 14:46                 ` Andrew Cagney
2002-06-21 14:55                   ` Daniel Jacobowitz
2002-06-21 15:31                     ` Andrew Cagney
2002-06-21 22:59                       ` Daniel Jacobowitz
2002-06-22  8:22                         ` Andrew Cagney
2002-06-24  7:53                           ` Daniel Jacobowitz
2002-06-21 16:14                     ` Jim Blandy
2002-06-21 22:57                       ` Daniel Jacobowitz
2002-06-26 12:37                         ` Jim Blandy
2002-06-21 13:20           ` Daniel Jacobowitz
2002-06-21 15:37             ` Jim Blandy
2002-06-21 23:00               ` Daniel Jacobowitz
2002-06-21 12:34   ` Jim Blandy
2002-06-21 12:49   ` Jim Blandy
2002-06-21 18:10     ` Jim Blandy
2002-06-21 20:24       ` Andrew Cagney
2002-06-21 21:09         ` Jim Blandy
2002-06-22  8:31           ` Andrew Cagney
2002-06-21 15:04 ` Andrew Cagney
2002-06-21 15:41   ` Jim Blandy
2002-06-21 15:59     ` Andrew Cagney
2002-06-21 16:08   ` Jim Blandy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).