Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: gdb-patches@sourceware.org
Subject: [0/7] RFC: read DWARF psymtabs in the background
Date: Mon, 14 Jun 2010 18:22:00 -0000	[thread overview]
Message-ID: <m34oh51nll.fsf@fleche.redhat.com> (raw)

This is a patch series to implement reading psymtabs for DWARF in the
background.

The motivation for this is a better user experience.  With this series,
gdb starts up dramatically faster, because we can hide much of the
reading in the background:

gdb -batch -nx ./gdb
Without:  2.37user 0.45system 0:03.47elapsed
With:     0.23user 0.04system 0:00.34elapsed

This example measures time-to-the-prompt.  Once at the prompt, if you do
some operation needing psymtabs, gdb will wait until they have been read
in.

It also works when attaching to a program with a lot of objfiles.  Here
is startup for attach to OO.o Writer:

gdb -batch -p NNNN
Without: 40.44user 2.19system 1:36.94elapsed
With:     2.20user 0.24system 0:04.32elapsed

It is not dramatically better in all cases:

gdb -batch -ex "thread apply all bt full" -p NNN
Without: 44.31user 2.31system 1:39.16elapsed
With:    46.01user 2.88system 1:21.92elapsed

In this case we end up waiting for most of the debuginfo to be read.
I have some other changes, coming later, that help with this.


All the code is written so that threads are optional.  On platforms
without threads, everything works as before, albeit in a somewhat more
convoluted way.

There are still some unpolished edges in this series.  I will try to
call these out in the specific patches.

As you might imagine it is rather tough to be certain that this code is
truly thread-safe.  GDB has plenty of hidden global variables, shared
state, etc.  I'll explain my approach to making this as safe as I could
in the appropriate patches.

Note that the patches probably don't build independently.  I didn't
really try that; I just split them up along conceptual lines.


I realize that threads are unpopular in many quarters, so this is an RFC.

I think I regtested this, but it is hard to recall.  Anyway it doesn't
matter -- I will do that when I fix the little problems that remain.

Tom


             reply	other threads:[~2010-06-14 18:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14 18:22 Tom Tromey [this message]
2010-06-14 21:27 ` Michael Snyder
2010-06-15  3:00   ` Tom Tromey
2010-06-22 20:06 ` Mark Kettenis
2010-06-25 21:03   ` Tom Tromey
2010-06-25 21:36     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m34oh51nll.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox