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
