[PATCH 2/2] btrace: avoid symbol lookup
Jan Kratochvil
jan.kratochvil@redhat.com
Mon Mar 24 08:37:00 GMT 2014
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
More information about the Gdb-patches
mailing list