[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHgaXdKGJFh8jO44gwCqe0cijoztf39bK9k8ioBtYDjzb4vvZw@mail.gmail.com>
Date: Wed, 21 Jun 2017 19:56:34 +0530
From: Shubham Bansal <illusionist.neo@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Kees Cook <keescook@...omium.org>,
Network Development <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Alexei Starovoitov <ast@...nel.org>,
Russell King <linux@...linux.org.uk>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH v2] arm: eBPF JIT compiler
Hi Daniel,
>
> So my question would be, why can't the JIT imitate something
> similar to what we do in the interpreter as well? So looking
> at the disasm of what gcc compiles for the interpreter when it's
> doing the above call could help as well in going forward. Not
> sure if that answers your question, but perhaps not sure if I
> understand your question yet?
I just looked at the code again and I think I completely misunderstood
the logic of BPF_JMP | BPF_CALL.
I think each helper function is working like this.
____helper_function(u32 a1, u32 a2){
}
helper_function(u64 a1, u64 a2){
____helper_function((u32 *)a1, (u32 *)a2);
}
So ultimately, we call helper_function which takes u64 as arguments
only. I know its asking a lot, but can you please confirm this asap? I
would like to start implementing it.
>
> Cheers,
> Daniel
-Shubham
Powered by blists - more mailing lists