Re: [RFC 0/2] __vdso_findsym

On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker [off-list ref] wrote:

On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:

quoted

On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen [off-list ref] wrote:

quoted

quoted

I think this issue started when some of the Go developers questioned
why the kernel needed to provide a very complex interface--parsing an
ELF shared shared library--for very simple functionality--looking up
the address of a magic function.  This approach has required special
support not just in Go, but also in the dynamic linker and gdb, and
does not work well for statically linked binaries.  The support in gdb
is perhaps a good idea, but elsewhere it does not make sense.

So why not provide a simple interface?

What good would it do now that everyone already supports it?

Do statically linked binaries use the vDSO calls?

Under glibc, I believe so (not checked). Under musl, yes, and even in
the dynamic-linked case we use the same code that's used for static
linking rather than trying to get the dynamic linker to do them
correctly. I still have some cruft lying around from where (in the
past) we tried to do it via the dynamic linker, but I'm probably going
to remove that and make the vdso behave as RTLD_LOCAL so that there's
no risk of weird symbols it exports interfering with the application
(applications could still make it global via an explicit dlopen). The
only reason for keeping it around at all in the dynamic linker is for
the sake of gdb.

What about backtrace_symbols, dl_addr, and the unwinder (e.g.
siglongjmp)?  It would be nice to wean the vdso off of frame pointers
some day.

--Andy