From: Tom Tromey <tromey@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
archer@sourceware.org, Jakub Jelinek <jakub@redhat.com>
Subject: Re: Inter-CU DWARF size optimizations and gcc -flto
Date: Mon, 05 Mar 2012 22:03:00 -0000 [thread overview]
Message-ID: <8762eivh7r.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAN9gPaGSZcyxu5n_xnD3cgt-LEuAnLyQBR8hpagfWGPNrmV0eQ@mail.gmail.com> (Daniel Jacobowitz's message of "Sun, 4 Mar 2012 19:25:39 -0500")
Daniel> I have no idea. One thing I'd like to revisit is your work on
Daniel> threaded symbol load; I have plenty of cores available, and the
Daniel> machine is pretty much useless to me until my test starts.
This might help, it would be worth trying at least.
I am mildly skeptical about it working well with a very big program.
It seems like you could get into memory trouble, which would need a
different sort of scaling approach.
Also, with .gdb_index, in my tests the startup time of gdb is dominated
by minsym reading, even banal stuff like sorting them. I think you'd
have to insert some threading bits in there too... easy though.
Daniel> There's
Daniel> also a lot of room for profiling to identify bad algorithms; I think
Daniel> we spend a lot of time reading the solib list from the inferior
Daniel> (something I thought I and others had fixed thoroughly already...) and
Daniel> I routinely hit inefficient algorithms e.g. during "next".
Yeah, I hadn't even gotten to thinking about anything other than the
symbol tables.
Tom> First, and simplest, punt. Make the user disable automatic reading of
Tom> shared library debuginfo (or even minsyms) and make the user explicitly
Tom> mention which ones should be used -- either by 'sharedlibrary' or by a
Tom> linespec extension.
Daniel> I am hugely unexcited by this.
Yeah, me too. It would "work" but the user experience would be not be
good.
Daniel> Something I've been thinking about is that incrementalism is hard in
Daniel> GDB because the symbol tables are so entwined... adding any sort of
Daniel> client/server interface would force us to detangle them, and then
Daniel> individual objects could have a longer life.
The symbol tables are my least favorite part of gdb right now, wresting
the crown from linespec this year. Though maybe that is just because I
don't know all parts equally well ;)
Tom
next prev parent reply other threads:[~2012-03-05 22:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 13:23 Jan Kratochvil
2012-02-01 13:32 ` Jakub Jelinek
2012-02-22 21:56 ` Tom Tromey
2012-02-26 15:09 ` Daniel Jacobowitz
2012-03-03 2:54 ` Tom Tromey
2012-03-05 0:25 ` Daniel Jacobowitz
2012-03-05 22:03 ` Tom Tromey [this message]
2012-03-15 12:51 ` Gary Benson
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=8762eivh7r.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=archer@sourceware.org \
--cc=drow@false.org \
--cc=jakub@redhat.com \
--cc=jan.kratochvil@redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).