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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Monday, March 24, 2014 9:37 AM


> 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.

No need.  I certainly agree that one can write such an assembly file and that
one can describe this in DWARF but not in ELF.

To describe this in ELF one would split a and b and thus end up with 4 functions -
that's what compilers seem to be doing today.  And they also seem to emit
DWARF that describes it that way.


> Corner cases are the ones most difficult to debug and it is a pity when
> debugger provides incorrect output in such corner cases.

I agree.


> 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.

If you just look hard enough, I guess you will find everything somewhere.

Those who use compilers, on the other hand, may not even be able to
tell the difference - except that it's faster which allows them to use
bigger buffers and thus record longer traces.


> > 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.

The specific problem of btrace is that it needs to do a huge number of symbol
lookups within a single GDB command.  I do not know any other GDB command
that gets anywhere near to that.

Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052