From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <drow@false.org>
Subject: Re: [RFA] Improve performance with lots of shared libraries
Date: Fri, 09 Sep 2011 19:41:00 -0000 [thread overview]
Message-ID: <20110909193239.GA23130@host1.jankratochvil.net> (raw)
In-Reply-To: <201109091609.31737.pedro@codesourcery.com> <201109091553.22390.pedro@codesourcery.com>
On Fri, 09 Sep 2011 16:53:22 +0200, Pedro Alves wrote:
> Not according to <http://sourceware.org/ml/gdb-patches/2011-08/msg00032.html>
Oops, I read it but ...
On Fri, 09 Sep 2011 17:09:31 +0200, Pedro Alves wrote:
> ... and I don't think that's entirely true. Yes, GDB will stop
> trying to resolve the spec to a symbol, but at every event gdb will
> still re-set the breakpoint locations. If the new library has
> the _same_ file:lineno compiled in (e.g., we put a breakpoint
> on a c++ template in a header, or an inline function that is
> also used by new library), then we should be getting new locations in
> the new shared library, today.
I would not state it so optimistically, in my experience the watchpoints to
inlined functions (PR 10738) and templates (file:line will break just at the
one instance kind, not all of them) do not work much. But I agree the design
of extensions should not block fixes of these issues.
Maybe the conditionals for "breakpoint can extended into new objfiles" could
be extended so that most common most simple practical use cases do not get
affected.
For example if the breakpoint is function-name kind (not [file:]line), exinst
placement has single location, it is not inlined instance and it is not
template instance? Any other ideas for restrictions?
Thanks,
Jan
next prev parent reply other threads:[~2011-09-09 19:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 14:25 Gary Benson
2011-09-09 14:35 ` Daniel Jacobowitz
2011-09-09 14:51 ` Jan Kratochvil
2011-09-09 15:04 ` Pedro Alves
2011-09-09 19:41 ` Jan Kratochvil [this message]
2011-09-12 12:44 ` Pedro Alves
2011-09-12 16:44 ` Jan Kratochvil
2011-09-14 9:28 ` Gary Benson
2011-10-04 19:46 ` Tom Tromey
2011-09-09 15:11 ` Pedro Alves
2011-09-09 14:53 ` Jan Kratochvil
2011-10-04 20:03 ` Tom Tromey
-- strict thread matches above, loose matches on Subject: below --
2011-09-22 17:35 Gary Benson
2011-07-01 16:51 Gary Benson
2011-07-01 17:19 ` Tom Tromey
2011-07-04 14:10 ` Gary Benson
2011-07-01 17:32 ` Joel Brobecker
2011-07-04 14:21 ` Gary Benson
2011-07-01 17:45 ` Pedro Alves
2011-07-01 17:57 ` Pedro Alves
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=20110909193239.GA23130@host1.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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