This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __statfs64() is declared but not defined


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]