On Fri, Jun 20, 2014 at 08:55:01AM -0700, Andy Lutomirski wrote:
> On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker 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 wrote:
> >> >> I think this issue started when some of the
On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker 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 wrote:
>> >> I think this issue started when some of the Go developers questioned
>> >> why the kernel needed to provide a very co
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 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
On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen 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 func
On Mon, Jun 16, 2014 at 04:38:01PM +0200, Andi Kleen 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
On Mon, Jun 16, 2014 at 07:08:50AM -0700, Ian Lance Taylor wrote:
> On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen wrote:
> >
> > I haven't looked into this in detail, but my initial assumption would
> > be that it wouldn't be useful to add new vdso interfaces just for Go.
> > After all would you rea
> 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
On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen wrote:
>
> I haven't looked into this in detail, but my initial assumption would
> be that it wouldn't be useful to add new vdso interfaces just for Go.
> After all would you really want to force ever Go user to upgrade their
> kernel just to get fast fi
On Sun, Jun 15, 2014 at 11:22:48AM -0700, Andy Lutomirski wrote:
> >>[1] The only comprehensible description of the GNU hash extension that
> >>I could find is on Oracle's blog (!)
> >>
> >
> > Curious about this blog. We do have a GNU hash implementation in Syslinux,
> > too, for another referen
On Mon, Jun 16, 2014 at 04:36:04AM +0200, Andi Kleen wrote:
>
> At least versioning is always useful to have, just to have
> another tool for compatibility if changes are needed.
I disagree. Just like syscalls, vdso functions with new APIs/ABIs
should have new names. For example if a version of
At least versioning is always useful to have, just to have
another tool for compatibility if changes are needed.
Not sure about weak, but it can't hurt. It seems to be standard practice
in glibc.
I haven't looked into this in detail, but my initial assumption would
be that it wouldn't be useful
On Sun, Jun 15, 2014 at 10:05:47AM -0700, H. Peter Anvin wrote:
> On 06/15/2014 07:35 AM, Rich Felker wrote:
> >
> > Arguably, it was a mistake for the kernel to expose a virtual ELF to
> > begin with, and it should just have exposed a "lookup function by
> > name" operation to begin with. Yes thi
On Sun, Jun 15, 2014 at 12:14:04PM -0700, H. Peter Anvin wrote:
> If it doesn't, then you incur an additional indirection penalty. The
> strong __vdso symbol allows the libc wrapper to fall back to the
> vdso implementation, the weak symbol allows three to be no wrapper
> at all. This is good.
No
Yes, but the option exists.
On June 15, 2014 1:53:17 PM PDT, Andy Lutomirski wrote:
>On Sun, Jun 15, 2014 at 12:56 PM, H. Peter Anvin wrote:
>> You can link against vdso.so if you want to; the kernel build
>provides an option to install that image. Doesn't mean that any
>particular libc uses it
On Sun, Jun 15, 2014 at 12:56 PM, H. Peter Anvin wrote:
> You can link against vdso.so if you want to; the kernel build provides an
> option to install that image. Doesn't mean that any particular libc uses it.
I'd be rather surprised if anyone does this, given the generally
spotty state of vds
You can link against vdso.so if you want to; the kernel build provides an
option to install that image. Doesn't mean that any particular libc uses it.
On June 15, 2014 12:50:36 PM PDT, Ian Lance Taylor wrote:
>On Sun, Jun 15, 2014 at 12:31 PM, H. Peter Anvin wrote:
>> The weak symbols are well
On Sun, Jun 15, 2014 at 12:31 PM, H. Peter Anvin wrote:
> The weak symbols are well-known names. The __vdso symbols are strong.
I see. But I don't understand how this is supposed to work. When I
link a program against gettimeofday, I get a reference to gettimeofday
with version GLIBC_2.2.5. A
The weak symbols are well-known names. The __vdso symbols are strong.
On June 15, 2014 12:22:17 PM PDT, Ian Lance Taylor wrote:
>On Sun, Jun 15, 2014 at 12:14 PM, H. Peter Anvin wrote:
>>
>> If it doesn't, then you incur an additional indirection penalty. The
>strong __vdso symbol allows the l
On Sun, Jun 15, 2014 at 12:14 PM, H. Peter Anvin wrote:
>
> If it doesn't, then you incur an additional indirection penalty. The strong
> __vdso symbol allows the libc wrapper to fall back to the vdso
> implementation, the weak symbol allows three to be no wrapper at all. This
> is good.
>
>
If it doesn't, then you incur an additional indirection penalty. The strong
__vdso symbol allows the libc wrapper to fall back to the vdso implementation,
the weak symbol allows three to be no wrapper at all. This is good.
The reason for changing ABI would be shifting types. This is very much
On Sun, Jun 15, 2014 at 11:39 AM, H. Peter Anvin wrote:
> Symbol versioning so we can rev the ABI and still provide backwards
> compatibility. Weak symbols so the libc can override symbols if it considers
> it appropriate. This is a good thing.
Are we ever going to change, say, the __vdso_clo
Symbol versioning so we can rev the ABI and still provide backwards
compatibility. Weak symbols so the libc can override symbols if it considers
it appropriate. This is a good thing.
On June 15, 2014 11:20:41 AM PDT, Andy Lutomirski wrote:
>cc: Andi Kleen, who designed the vdso
>
>On Sun, Jun
On Sun, Jun 15, 2014 at 11:20 AM, H. Peter Anvin wrote:
>
>
> On June 15, 2014 10:40:03 AM PDT, Andy Lutomirski wrote:
>>On Sun, Jun 15, 2014 at 10:05 AM, H. Peter Anvin wrote:
>>> On 06/15/2014 07:35 AM, Rich Felker wrote:
Arguably, it was a mistake for the kernel to expose a virtual
cc: Andi Kleen, who designed the vdso
On Sun, Jun 15, 2014 at 10:57 AM, H. Peter Anvin wrote:
> On 06/15/2014 10:40 AM, Andy Lutomirski wrote:
>>
>> To be clear, I have no desire whatsoever to give the vdso an actual
>> ELF parser or anything else that userspace should be providing itself.
>> I t
On June 15, 2014 10:40:03 AM PDT, Andy Lutomirski wrote:
>On Sun, Jun 15, 2014 at 10:05 AM, H. Peter Anvin wrote:
>> On 06/15/2014 07:35 AM, Rich Felker wrote:
>>>
>>> Arguably, it was a mistake for the kernel to expose a virtual ELF to
>>> begin with, and it should just have exposed a "lookup
On 06/15/2014 10:40 AM, Andy Lutomirski wrote:
>
> To be clear, I have no desire whatsoever to give the vdso an actual
> ELF parser or anything else that userspace should be providing itself.
> I think that a special-purpose vdso parser in the vdso makes some
> sense, though, since userspace might
On Sun, Jun 15, 2014 at 10:05 AM, H. Peter Anvin wrote:
> On 06/15/2014 07:35 AM, Rich Felker wrote:
>>
>> Arguably, it was a mistake for the kernel to expose a virtual ELF to
>> begin with, and it should just have exposed a "lookup function by
>> name" operation to begin with. Yes this can be don
On 06/15/2014 07:35 AM, Rich Felker wrote:
>
> Arguably, it was a mistake for the kernel to expose a virtual ELF to
> begin with, and it should just have exposed a "lookup function by
> name" operation to begin with. Yes this can be done in userspace, but
> I see it more as a matter of "fixing a b
On Sun, Jun 15, 2014 at 7:35 AM, Rich Felker wrote:
> On Sun, Jun 15, 2014 at 04:25:37PM +0200, Mikael Pettersson wrote:
>> Andy Lutomirski writes:
>> > The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
>> > implements __vdso_findsym.
>> >
>> > This would make it easier for
On Sun, Jun 15, 2014 at 04:25:37PM +0200, Mikael Pettersson wrote:
> Andy Lutomirski writes:
> > The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
> > implements __vdso_findsym.
> >
> > This would make it easier for runtimes that don't otherwise implement
> > ELF loaders to
Andy Lutomirski writes:
> The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
> implements __vdso_findsym.
>
> This would make it easier for runtimes that don't otherwise implement
> ELF loaders to use the vdso.
>
> Thoughts?
I'm opposed to this based on the principle tha
On Sat, Jun 14, 2014 at 8:59 PM, H. Peter Anvin wrote:
> On 06/14/2014 04:36 PM, H. Peter Anvin wrote:
>>
>> Now, if we can do this without adding another page then that becomes
>> much more compelling IMO. I suspect we can if you are already down to
>> 488 bytes.
>>
>
> (If it isn't already the
On 06/14/2014 04:36 PM, H. Peter Anvin wrote:
>
> Now, if we can do this without adding another page then that becomes
> much more compelling IMO. I suspect we can if you are already down to
> 488 bytes.
>
(If it isn't already the case, was inteded to be part of that...)
-hpa
--
To u
On 06/14/2014 03:38 PM, Andy Lutomirski wrote:
>
> Hmm. I hadn't thought of this as a size win, but I guess it could be
> if there are static binaries around.
>
That pretty much *is* the win, because this is in effect treating the
kernel vdso as a shared library.
> This patch currently generat
On Sat, Jun 14, 2014 at 2:30 PM, Rich Felker wrote:
> On Sat, Jun 14, 2014 at 11:16:42AM -0700, Andy Lutomirski wrote:
>> The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
>> implements __vdso_findsym.
>>
>> This would make it easier for runtimes that don't otherwise implement
>
On Sat, Jun 14, 2014 at 11:16:42AM -0700, Andy Lutomirski wrote:
> The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
> implements __vdso_findsym.
>
> This would make it easier for runtimes that don't otherwise implement
> ELF loaders to use the vdso.
>
> Thoughts?
>
> If peopl
The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
implements __vdso_findsym.
This would make it easier for runtimes that don't otherwise implement
ELF loaders to use the vdso.
Thoughts?
If people like the basic concept, I'll finish it, write up
documentation and a selftest. I
37 matches
Mail list logo
