Re: [PATCH V2 2/8] bpf: new GCC port

[Richard Sandiford <richard dot sandiford at arm dot com>]

jose.marchesi@oracle.com (Jose E. Marchesi) writes:
>         > +#undef TARGET_PASS_BY_REFERENCE
>         > +#define TARGET_PASS_BY_REFERENCE bpf_pass_by_reference
>         
>         I might have misunderstood, but I thought from an earlier (IRC?)
>         message, it wasn't possible for the callee to access the caller's
>         frame, which was why you had the error about running out of argument
>         registers.  If so, won't passing by reference make the argument
>         inaccessible in practice?  I don't see what you gain by defining
>         the hook, since I'd have assumed (at least after the fix above)
>         that it would be better to pass by value and get an error about
>         having no argument registers left.
>     
>     Yes.  I added that hook before I had the restriction of number of
>     arguments in place.  Removing it.
>
> Happy auto correction :)
>
> A colleague (who actually _uses_ eBPF extensively, ahem) tells me that
> the kernel verifier allows to pass addresses of the caller's stack
> frame, tracking that it is a ptr to a stack location, and it knows which
> stack it came from.  So it is indeed possible for the callee to access
> the caller's frame, and therefore to pass arguments by reference.
>
> On the downside, it is not possible for a callee to access the caller's
> frame applying an offset to its frame pointer, because the stacks are
> disjoint.  This means that most probably I will have to dedicate a real,
> not eliminable register to act as the arg pointer, if I want to get rid
> of the annoying limitation on the number of arguments...  and in order
> to keep ABI compatibility with llvm built objects, this register is
> gonna have to be %r5, i.e. the last register usable to pass arguments,
> but it should be only used for that purpose if the function gets more
> than 5 arguments...  sounds messy, but there is hope, yay!
>
> However, unless someone comes with a magical macro to define or an
> existing target doing the same thing, I am deferring attacking this
> problem for later (TM) and for the time being I will keep both the
> ability of passing aggregates and other big arguments by reference, and
> the limit on number of arguments (this is what clang does.)
>
> I hope that's ok for you people.

Sounds good :-)