Re: [PING^3] Re: [PATCH 1/3] Support instrumenting returns of instrumented functions

[Andi Kleen <andi at firstfloor dot org>]

On Wed, Nov 28, 2018 at 05:24:37PM +0100, Jan Hubicka wrote:
> > On Wed, Nov 28, 2018 at 04:59:25PM +0100, Jan Hubicka wrote:
> > > Hi,
> > > I wonder how __return_loc sections work.  In general it would be nice to
> > 
> > You mean how it's used? It's for patching in/out return instrumentation
> > at runtime, and to find them we use the sections.
> > 
> > > avoid direct output of assembler code in favour of adding instructions
> > > to rtl stream which should be possible to insert the call and return.
> > 
> > That would be a full rewrite how all these hooks work. I was 
> > hoping extending the existing frame work would be good enough for now.
> 
> Yep, it is ugly and it hits us ocassionaly as with the CET
> instrumentation, but I suppose we should care about this in stage1.
> > 
> > > __return_loc seems harder, also I wonder if it makes unwind information
> > > possible?
> > 
> > Do we need unwind information for calls? I thought it was only
> > for other stack manipulation.
> 
> I just wonder if backtraces are right if something triggers in the extra
> code.  If you make control flow to jump into separate section, I suppose
> backtraces won't be right.  Not sure if that is necessarily issue?

I don't think it is because the instrumentation only adds calls, and
calls don't get annotated in DWARF. The only issue I could think of
if is something patches in push instructions through the nops, 
but there is really nothing the compiler could do about that.

I tested gdb and it can backtrace through the return instrumentation.

Breakpoint 1, 0x0000000000401182 in __return__ ()
(gdb) bt
#0  0x0000000000401182 in __return__ ()
#1  0x00000000004011a3 in f2 ()
#2  0x00000000004011b7 in main ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

-Andi