Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Fri, Jun 14, 2019 at 08:31:53AM -0700, Alexei Starovoitov wrote:
> On Fri, Jun 14, 2019 at 6:34 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > On Thu, Jun 13, 2019 at 11:00:09PM -0700, Alexei Starovoitov wrote:
> > > > +   if (src_reg == BPF_REG_FP) {
> > > > +           /*
> > > > +            * If the value was copied from RBP (real frame pointer),
> > > > +            * adjust it to the BPF program's frame pointer value.
> > > > +            *
> > > > +            * add dst, -40
> > > > +            */
> > > > +           EMIT4(add_1mod(0x48, dst_reg), 0x83, add_1reg(0xC0, dst_reg),
> > > > +                 0xD8);
> > > > +   }
> > > > +
> > >
> > > That won't work. Any register can point to a stack.
> >
> > Right, but if the stack pointer comes from BPF_REG_FP then won't the
> > above correct it?  Then if the pointer gets passed around to other
> > registers it will have the correct value.  Or did I miss your point?
> 
> At the beginning of the program frame pointer is bpf_reg_fp,
> but later it can be in any register. It can be spilled into stack.
> Some math done on it and that adjusted pointer passed into
> another jited function.
> It's perfectly fine for one bpf program to modify stack of
> another bpf program. The verifier checks the safety bounds, etc.

I still don't get what you're saying.  The above patch attempted to
cover all those scenarios by always subtracting an offset from all movs
and stack accesses relating to BPF_REG_FP.  It might be missing a case
or two but it seems like it should work.  From the program's point of
view, BPF_REG_FP should always show the right value no matter where it
gets moved to.

But anyway, David L's nested frame idea might be a much simpler change.
I'll look at that.

-- 
Josh