Re: Function fingerprinting for useful backtraces in absence of debuginfo

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 20 Sep 2011 15:51:17 +0200, Martin Milata wrote:
> On Thu, Sep 15, 2011 at 19:48:31 +0200, Jan Kratochvil wrote:
> > >  (Call graph properties)
> > >  * List of the library functions called.
> > 
> > That is the functions called via .plt section - either from different libraries
> > or within the same library (if it does not use direct calls like glibc does).
> > Hopefully this should not change, I agree.
> 
> Great, this is so far the most important component in the signature

Be aware you have to disassemble the function, relocations are for the .plt
section, functions call PC-relatively the functions in .plt without any
further relocations.


> This unfortunately means that lot of functions that do not call anything
> through .plt have the same fingerprint. Can you think of some other
> properties that we could use in those functions?

As you already have to do the disassembly analysis very similar to the .plt
functions calls you can find references to exported variables due to the .got
section references.


> > >  * Conditional jumps based on equality test/signed comparison/unsigned
> > >    comparison.
> > 
> > This is the exact target of the gcc -fprofile-* optimizations; AFAIK SuSE uses
> > it a lot (I had some negative results trying to apply it for gdb packaging).
> > That is to invert the jump conditional and reshuffle the code around so that in
> > >50% cases it does not jump depending on "random" benchmark data during each
> > >build.
> 
> But we can test if the code contains either of the jX and jnX
> instructions, right?

jX vs. jnX will change depending on the -fprofile-* feedback file and you
probably cannot find out which of the two code paths match which of the former
code paths.  Try yourself -fprofile-generate build, give it two different
external data input for more positive/negative conditional and how you can
match the resulting two -fprofile-use generated executables.

BTW have fun porting the disassemblt analysis to all arches.


[gdbserver]
> Also, if I
> understand correctly, the connection has to be initiated from the host
> machine which might be a problem if there are NATs/firewalls on the way.

The direction of the connection is not relevant IMO, it needs to be tunnelled
for some encryption anyway which can change the way how the connection is
initiated..



Thanks,
Jan