Re: [PATCH 2/2] btrace: avoid symbol lookup

[Jan Kratochvil <jan.kratochvil@redhat.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