This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] btrace: avoid symbol lookup
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, "Pedro Alves (palves at redhat dot com)" <palves at redhat dot com>
- Date: Mon, 24 Mar 2014 09:37:10 +0100
- Subject: Re: [PATCH 2/2] btrace: avoid symbol lookup
- Authentication-results: sourceware.org; auth=none
- References: <1394182665-14164-1-git-send-email-markus dot t dot metzger at intel dot com> <1394182665-14164-3-git-send-email-markus dot t dot metzger at intel dot com> <20140310214252 dot GA3105 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230AA8BFE3 at IRSMSX104 dot ger dot corp dot intel dot com> <20140321172215 dot GA15215 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230C13BFA6 at IRSMSX104 dot ger dot corp dot intel dot com>
On Mon, 24 Mar 2014 08:55:33 +0100, Metzger, Markus T wrote:
> > I do not think providing incorrect behavior for performance reasons is a valid
> > tradeoff. The right way would be to fix the DWARF lookups to be fast
> > enough.
[...]
> The only actual change in functionality I was able to observe was missing
> parens for the main function,
I agree in 99.9% of usecases it will work the same. This still does not prove
it is correct.
I believe I can create a reproducer with two overlapping functions:
0..1: a()
2..3: b()
4..6: a()
7..8: b()
properly describe by DW_AT_ranges which will work with former GDB but which
will no longer work with patched GDB.
This may definitely happen for some user .S code with hand-coded DWARF.
I do not say it necessarilly happens with any real world compiler output.
This may happen for gdb.dwarf2/dw2-objfile-overlap.exp which comes from a real
world case of Linux kernel modules mapping.
But maybe I miss something and I would fail to create the reproducer, if you
do not agree I can create a .S with hand coded DWARF I can try to create one.
Corner cases are the ones most difficult to debug and it is a pity when
debugger provides incorrect output in such corner cases.
As I said maybe this compromise is acceptable as it may not be hit in real
world usage cases but I do not want to make this decision.
> I think the compromise is rather between a nice, general solution that
> benefits everybody and a local solution that only benefits btrace
This is the second reason why I did not agree with the patch. GDB needs to be
faster and if this PC->functionname mapping can be accelerated such way then
it should be done globally.
Regards,
Jan