Thread (39 messages) 39 messages, 6 authors, 2014-06-20

Re: [RFC 0/2] __vdso_findsym

From: H. Peter Anvin <hidden>
Date: 2014-06-15 19:14:43
Also in: lkml

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 how glibc manages transitions.



On June 15, 2014 11:54:10 AM PDT, Andy Lutomirski [off-list ref] wrote:
On Sun, Jun 15, 2014 at 11:39 AM, H. Peter Anvin [off-list ref] wrote:
quoted
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_clock_gettime ABI without
renaming the function?  If we want to preserve that ability, I can
keep support for versions, but it seems odd.

I don't buy the weak symbol argument at all.  We currently expose a
strong symbol __vdso_clock_gettime and a weak alias clock_gettime.  I
agree that, if glibc treats us as a real DSO, then clock_gettime can't
be strong, but I don't see why it should exist at all (other than for
backwards compatibility).

--Andy
-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help