lkml.org 
[lkml]   [2014]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC 0/2] __vdso_findsym
On Sun, Jun 15, 2014 at 7:35 AM, Rich Felker <dalias@libc.org> 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 runtimes that don't otherwise implement
>> > ELF loaders to use the vdso.
>> >
>> > Thoughts?
>>
>> I'm opposed to this based on the principle that the kernel should NOT
>> be a dumping ground for random code that user-space can and should
>> implement for itself. As long as the vdso is correctly formatted ELF,
>> then parsing it is easy, and the kernel should not care at all if or
>> how user-space accesses it.
>
> 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 broken API design".

Is the __vdso_findsym(name, version) approach good? I don't know why
the vdso uses symbol versions at all, nor do I know why it uses weak
symbol aliases. The vdso's "clock_gettime" isn't a drop-in
replacement for glibc's: it doesn't touch error, and it returns
negative error codes.

It might make more sense to promise that the vdso will never export to
functions with the same name but different versions and to just get
rid of the version field from __vdso_findsym. I tried implementing
this; it's untested, but the text size is only 230 bytes :)

It might also make sense to look up by number. Yes, it smells like
Windows DLLs, but it also looks awfully like Linux syscalls, which do
just fine using a call-by-number scheme.

--Andy


\
 
 \ /
  Last update: 2014-06-15 18:21    [W:0.211 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site