public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [0/7] RFC: read DWARF psymtabs in the background
@ 2010-06-14 18:22 Tom Tromey
  2010-06-14 21:27 ` Michael Snyder
  2010-06-22 20:06 ` Mark Kettenis
  0 siblings, 2 replies; 6+ messages in thread
From: Tom Tromey @ 2010-06-14 18:22 UTC (permalink / raw)
  To: gdb-patches

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

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

* Re: [0/7] RFC: read DWARF psymtabs in the background
  2010-06-14 18:22 [0/7] RFC: read DWARF psymtabs in the background Tom Tromey
@ 2010-06-14 21:27 ` Michael Snyder
  2010-06-15  3:00   ` Tom Tromey
  2010-06-22 20:06 ` Mark Kettenis
  1 sibling, 1 reply; 6+ messages in thread
From: Michael Snyder @ 2010-06-14 21:27 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches

Tom Tromey wrote:
> 
> 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.

Just curious; which platform without threads have you tested on?

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

* Re: [0/7] RFC: read DWARF psymtabs in the background
  2010-06-14 21:27 ` Michael Snyder
@ 2010-06-15  3:00   ` Tom Tromey
  0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2010-06-15  3:00 UTC (permalink / raw)
  To: Michael Snyder; +Cc: gdb-patches

>>>>> "Michael" == Michael Snyder <msnyder@vmware.com> writes:

>> 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.

Michael> Just curious; which platform without threads have you tested on?

I haven't run the test suite threadless at all.

However, I did build it without thread support (on Linux) and then
smoke-tested it by running it on itself.

I'm thinking of adding a --disable-threads or something so that people
who don't want this can turn it off.

Tom

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

* Re: [0/7] RFC: read DWARF psymtabs in the background
  2010-06-14 18:22 [0/7] RFC: read DWARF psymtabs in the background Tom Tromey
  2010-06-14 21:27 ` Michael Snyder
@ 2010-06-22 20:06 ` Mark Kettenis
  2010-06-25 21:03   ` Tom Tromey
  1 sibling, 1 reply; 6+ messages in thread
From: Mark Kettenis @ 2010-06-22 20:06 UTC (permalink / raw)
  To: tromey; +Cc: gdb-patches

> From: Tom Tromey <tromey@redhat.com>
> Date: Mon, 14 Jun 2010 12:21:58 -0600
>
> I realize that threads are unpopular in many quarters, so this is an RFC.

Sorry, but this is pretty much a no-go for OpenBSD.  We have a
userland threads implementation that puts file descriptors in
non-blocking mode such that it can switch to another thread if I/O to
that filedescriptor would block.  This has side effects if these file
descriptors are shared with child processes :(.

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

* Re: [0/7] RFC: read DWARF psymtabs in the background
  2010-06-22 20:06 ` Mark Kettenis
@ 2010-06-25 21:03   ` Tom Tromey
  2010-06-25 21:36     ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2010-06-25 21:03 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

>>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:

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

Mark> Sorry, but this is pretty much a no-go for OpenBSD.  We have a
Mark> userland threads implementation that puts file descriptors in
Mark> non-blocking mode such that it can switch to another thread if I/O to
Mark> that filedescriptor would block.  This has side effects if these file
Mark> descriptors are shared with child processes :(.

If that is your only objection, it is no trouble to disable this code on
a per-host basis.  All that is missing for that is some of the
configury; all the code is designed to allow single-threaded operation.

Tom

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

* Re: [0/7] RFC: read DWARF psymtabs in the background
  2010-06-25 21:03   ` Tom Tromey
@ 2010-06-25 21:36     ` Daniel Jacobowitz
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2010-06-25 21:36 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Kettenis, gdb-patches

On Fri, Jun 25, 2010 at 03:03:14PM -0600, Tom Tromey wrote:
> >>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> 
> Tom> I realize that threads are unpopular in many quarters, so this is an RFC.
> 
> Mark> Sorry, but this is pretty much a no-go for OpenBSD.  We have a
> Mark> userland threads implementation that puts file descriptors in
> Mark> non-blocking mode such that it can switch to another thread if I/O to
> Mark> that filedescriptor would block.  This has side effects if these file
> Mark> descriptors are shared with child processes :(.
> 
> If that is your only objection, it is no trouble to disable this code on
> a per-host basis.  All that is missing for that is some of the
> configury; all the code is designed to allow single-threaded operation.

FWIW, I think this is a reasonable thing to do.  I also think that
loading your future proposed indexes in the background would be a nice
feature.  For one thing, that lets us do them in parallel - great for
a task likely to be I/O dominated.  And on Windows hosts we already
use threads, so it'd win there too.

-- 
Daniel Jacobowitz
CodeSourcery

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

end of thread, other threads:[~2010-06-25 21:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-14 18:22 [0/7] RFC: read DWARF psymtabs in the background Tom Tromey
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

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).