On Fri, Apr 19, 2019 at 07:47:18PM +0800, Kairui Song wrote: > On Fri, Apr 19, 2019 at 5:43 PM Peter Zijlstra <[email protected]> wrote: > > > > On Fri, Apr 19, 2019 at 10:17:49AM +0800, Kairui Song wrote: > > > On Fri, Apr 19, 2019 at 8:58 AM Josh Poimboeuf <[email protected]> > > > wrote: > > > > > > > > I still don't like using regs->bp because it results in different code > > > > paths for FP and ORC. In the FP case, the regs are treated like real > > > > regs even though they're fake. > > > > > > > > Something like the below would be much simpler. Would this work? I > > > > don't > > > > know if any other code relies on the fake regs->bp or regs->sp. > > > > > > Works perfectly. My only concern is that FP path used to work very > > > well, not sure it's a good idea to change it, and this may bring some > > > extra overhead for FP path. > > > > Given Josh wrote all that code, I'm fairly sure it is still OK :-) > > > > But also looking at the code in unwind_frame.c, __unwind_start() seems > > to pretty much do what the removed caller_frame_pointer() did (when > > .regs=NULL) but better. > > > > OK, with FP we will also need to do a few more extra unwinding, > previously it start directly from the frame of the trace point, now > have to trace back to the trace point first. > If that's fine I could post another update (that will be pretty much > just copy&paste from the Josh's code he posted :P , is this OK?)
You're right that FP will need to unwind a few extra frames, but I doubt that will make much of a difference performance-wise. I prefer the simpler approach. If you use that patch for the next version then you can add Co-developed-by: Josh Poimboeuf <[email protected]> Thanks. -- Josh
