mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Ian Lance Taylor <iant@golang.org>,
	Andi Kleen <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Mikael Pettersson <mikpelinux@gmail.com>,
	Russ Cox <rsc@golang.org>, Linux API <linux-api@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>
Subject: Re: [RFC 0/2] __vdso_findsym
Date: Fri, 20 Jun 2014 12:07:08 -0400	[thread overview]
Message-ID: <20140620160708.GY179@brightrain.aerifal.cx> (raw)
In-Reply-To: <CALCETrWnQyCk5vhDj-yAhRdAFOtFKSU6H-E_=LBC+FbA2REhrg@mail.gmail.com>

On Fri, Jun 20, 2014 at 08:55:01AM -0700, Andy Lutomirski wrote:
> On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker <dalias@libc.org> wrote:
> > On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:
> >> On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen <andi@firstfloor.org> wrote:
> >> >> 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.

My comments were in the context of musl, which doesn't use unwinding
internally whatsoever, but if you're asking about the usefulness of
being able to see the vdso's elf/dwarf2/etc. stuff for various
outside-of-libc purposes, then yes. My statement "for the sake of gdb"
was just a poor substitute for this concept (debugging/introspective
use in general).

Rich

  reply	other threads:[~2014-06-20 16:08 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-14 18:16 Andy Lutomirski
2014-06-14 18:16 ` [RFC 1/2] uapi: Add some missing dynamic table-related definitions to elf.h Andy Lutomirski
2014-06-14 18:16 ` [RFC 2/2] [NOT READY] x86/vdso: Add __vdso_findsym Andy Lutomirski
2014-06-14 21:30 ` [RFC 0/2] __vdso_findsym Rich Felker
2014-06-14 22:38   ` Andy Lutomirski
2014-06-14 23:36     ` H. Peter Anvin
2014-06-15  3:59       ` H. Peter Anvin
2014-06-15  6:49         ` Andy Lutomirski
2014-06-15 14:25 ` Mikael Pettersson
2014-06-15 14:35   ` Rich Felker
2014-06-15 15:47     ` Andy Lutomirski
2014-06-15 17:05     ` H. Peter Anvin
2014-06-15 17:40       ` Andy Lutomirski
2014-06-15 17:57         ` H. Peter Anvin
2014-06-15 18:20           ` Andy Lutomirski
2014-06-15 18:39             ` H. Peter Anvin
2014-06-15 18:54               ` Andy Lutomirski
2014-06-15 19:14                 ` H. Peter Anvin
2014-06-15 19:22                   ` Ian Lance Taylor
2014-06-15 19:31                     ` H. Peter Anvin
2014-06-15 19:50                       ` Ian Lance Taylor
2014-06-15 19:56                         ` H. Peter Anvin
2014-06-15 20:53                           ` Andy Lutomirski
2014-06-15 21:13                             ` H. Peter Anvin
2014-06-16  0:55                   ` Rich Felker
2014-06-16  2:36             ` Andi Kleen
2014-06-16  3:49               ` Rich Felker
2014-06-16 14:08               ` Ian Lance Taylor
2014-06-16 14:38                 ` Andi Kleen
2014-06-16 14:58                   ` Rich Felker
2014-06-16 15:31                   ` Ian Lance Taylor
2014-06-16 15:42                     ` Rich Felker
2014-06-20 15:55                       ` Andy Lutomirski
2014-06-20 16:07                         ` Rich Felker [this message]
2014-06-16 14:56                 ` Rich Felker
2014-06-15 18:20         ` H. Peter Anvin
2014-06-15 18:22           ` Andy Lutomirski
2014-06-16  6:39             ` Rich Felker
2014-06-16  1:06       ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140620160708.GY179@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=iant@golang.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mikpelinux@gmail.com \
    --cc=rsc@golang.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®