On 03/15, Ivan Vecera wrote:
----- Stanislav Fomichev sdf@fomichev.me wrote:
On 03/15, Ivan Vecera wrote:
On 15. 03. 19 21:08, Stanislav Fomichev wrote:
On 03/15, Ivan Vecera wrote:
After some experiences I found that urandom_read does not need to be linked statically. When the 'read' syscall call is moved to separate non-inlined function then bpf_get_stackid() is able to find the executable in stack trace and extract its build_id from it.
But why? Do you have some problems with it being linked statically?
Dependency... you don't need to install static glibc to compile the bpf samples. Shared libc is available everytime.
Oh, the distros that do -devel _and_ -static packages :-)
So your patch essentially adds a call, that leaves a trace on the stack with our build-id. I guess that works as well.
Without that additional call this does not work and build_id selftest fails.
Oh, yeah, I was just trying to clarify why it fails without -static and why your patch makes it work for non-static :-) You can put more details in the commit message; you'd have to resubmit whenever net-next/bpf-next opens anyway.
I.