This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: __statfs64() is declared but not defined
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Peter TB Brett <peter at peter-b dot co dot uk>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Mon, 14 Apr 2014 04:04:32 -0400
- Subject: Re: __statfs64() is declared but not defined
- Authentication-results: sourceware.org; auth=none
- References: <871tx31s0i dot fsf at harrington dot peter-b dot co dot uk> <CAE2sS1jB56dT4o7L-toEopf7S5EDeXq13cms_N8+OLjfD7URyQ at mail dot gmail dot com> <09256ef4-d209-41f4-9e99-9e8f3a593d93 at email dot android dot com>
On Sat, Apr 12, 2014 at 7:08 PM, Peter TB Brett <peter@peter-b.co.uk> wrote:
> On 12 April 2014 18:02:37 BST, Carlos O'Donell <carlos@systemhalted.org> wrote:
>>On Fri, Apr 11, 2014 at 5:21 PM, Peter TB Brett <peter@peter-b.co.uk>
>>wrote:
>>
>>Internally libc.so.6 may use __statfs64 to avoid PLT indirection and
>>call this function directly for performance reasons and internal
>>consistency reasons. Sometimes we do this to ignore user provided
>>interposed versions of functions where internal consistency is more
>>important e.g. we really really need to stat a file to implement some
>>other API without having the users version of stat get in the way
>>(this decision is made on a case by case basis).
>>
>>However, from librt.so, we must go through the PLT to reach statfs64
>>in libc.so.6 and can't avoid that without providing a GLIBC_PRIVATE
>>version of the symbol for librt.so to call. We don't do that because
>>there is no need.
>>
>>To make a long story short you should just call statfs64.
>>
>>Does that answer your question?
>
> Not entirely.
>
> Why does __statfs() have a GLIBC_PRIVATE version while __statfs64() does not?
The answer to that, like all things in glibc, is that it is complicated.
Firstly let me clarify a couple of things.
The __statfs symbol doesn't have a GLIBC_PRIVATE version, it's
actually exported at version GLIBC_2.2.5 to match the non-internal
statfs@@GLIBC_2.2.5 (we keep the alias matching the real symbol
version), but because it starts with "__" it is in the implementation
namespace (per ISO C) and has no guarantees assured for applications
deciding to call that symbol.
Secondly, and this is the ugly bit.
On a 64-bit machine, in general, the statfs and statfs64 syscalls are the same.
So on x86-64 the statfs64 symbol is actually an alias for __statfs
which is why there is no __statfs64 by default. If it was not an
alias the normal procedures would have given you a __statfs64 you
could call.
What this means is that nobody has ever had a need to call __statfs64
from within libc.so for any reason so it's never been added as a way
to call statfs64 and avoid the PLT indirection / maintain internal
consistency.
Lastly, on x86-64 the statfs function and aliases are built in an
automated fashion from:
sysdeps/unix/sysv/linux/wordsize-64/syscalls.list
You could add a __statfs64 weak name to that list if you wanted to use
__statfs64.
I suggest trying it out to see for yourself how it all builds and fits together.
> What determines whether it is considered worthwhile to provide a GLIBC_PRIVATE version of a symbol?
This is longer than a 60-second response so I wrote this up in our
Style and Conventions guide:
https://sourceware.org/glibc/wiki/Style_and_Conventions#Double-underscore_names_for_public_API_functions
At this point in time the statfs64 function is a public API that might
need changes and appropriate versioning so we would not make it
GLIBC_PRIVATE.
The use GLIBC_PRIVATE version is for internal ABIs where changing the
implementation to match the changes has no user visible consequence.
If you still have questions please keep asking.
Cheers,
Carlos.