public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Tom Tromey <tromey@redhat.com>,
	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: Thu, 15 Mar 2012 12:51:00 -0000	[thread overview]
Message-ID: <20120315125107.GB3076@redhat.com> (raw)
In-Reply-To: <CAN9gPaGSZcyxu5n_xnD3cgt-LEuAnLyQBR8hpagfWGPNrmV0eQ@mail.gmail.com>

Daniel Jacobowitz wrote:
> There's also a lot of room for profiling to identify bad algorithms;
> I think we spend a lot of time reading the solib list from the
> inferior (something I thought I and others had fixed thoroughly
> already...) and I routinely hit inefficient algorithms e.g. during
> "next".

I did some work on this recently.  On my setup (with gdb and the
inferior on the same machine) it was spending a huge chunk of time
regenerating symbol tables every time the solib_event_breakpoint
hit.  The final patch I committed is here:

  http://www.cygwin.com/ml/gdb-patches/2011-10/msg00068.html

If you're seeing some sort of qsort comparison function at the top
of the profile it could be that something is bypassing this.

If you find the time is taken up mostly with transferring data from
the inferior to gdb (I never tried remote, for instance) then you
might be interested in some work I did last year on a SystemTap based
interface between glibc and gdb that should be able to be extended to
allow selective reading of the solib list.  That's waiting on Sergio's
SystemTap stuff... also the glibc maintainers seem hostile to the
idea of us inserting SystemTap probes in there.  I can dig up the code
I had for this if you're interested.

I also had a patch floating around that disabled the solib event
breakpoint under certain conditions, but I think the ambiguous
linespec stuff makes this patch invalid as you always have to be
looking out for new functions turning up.  If you're interested the
thread is http://www.cygwin.com/ml/gdb-patches/2011-09/msg00156.html
but it's probably useless :(

Cheers,
Gary

-- 
http://gbenson.net/

      parent reply	other threads:[~2012-03-15 12:51 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
2012-03-15 12:51         ` Gary Benson [this message]

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=20120315125107.GB3076@redhat.com \
    --to=gbenson@redhat.com \
    --cc=archer@sourceware.org \
    --cc=drow@false.org \
    --cc=jakub@redhat.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=tromey@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).