On 03/15, Ivan Vecera wrote: > > ----- Stanislav Fomichev <sdf@xxxxxxxxxxx> 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.
