RFR: Handle confstr version lookup failures gracefully

David Holmes david.holmes at oracle.com
Wed Apr 12 02:43:57 UTC 2017

On 12/04/2017 12:06 PM, Mikael Vidstedt wrote:
>> On Apr 11, 2017, at 6:58 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>> On 12/04/2017 11:42 AM, Mikael Vidstedt wrote:
>>>> On Apr 11, 2017, at 6:27 PM, David Holmes <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>> On 12/04/2017 10:00 AM, Mikael Vidstedt wrote:
>>>>> During bootstrapping, os::Linux::libpthread_init() tries to
>>>>> discover the versions of (g)libc and libpthread respectively. This
>>>>> is done using confstr(3). However, musl doesn’t implement support
>>>>> for version discovery, so confstr will return 0/EINVAL.
>>>>> This change makes the code handle confstr failures gracefully, and
>>>>> defaults using the string “unknown” if the version information
>>>>> cannot be looked up.
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/glibcversion/webrev.01/hotspot/webrev/
>>>> There was no need to separate out the declaration here:
>>>> 504   size_t n;
>>>> 505
>>>> 506   n = confstr(_CS_GNU_LIBC_VERSION, NULL, 0);
>>>> Overall I don't think this change is quite what we would want in
>>>> that it is wrong to print "unknown" when in fact there is no libc
>>>> (or libpthread?) involved. And we would surely want to see that we
>>>> are using musl.
>>> Since the variable is reused for the second confstr call I prefer to
>>> declare it separately.
>> Declaring uninitialized variables is an anachronism IMHO. :)
>>> In an upcoming change I have added support for adding “-musl” to the
>>> (internal) version string so that we can at least see that it’s a
>>> musl VM instead of a glibc one.
>>> There is a libc - musl. libpthread happens to be part of that same
>>> libc instead of being a separate library, so depending on how you
>>> look at it there is or isn’t a libpthread (it is effectively an
>>> implementation detail of musl). The problem is that there’s no way of
>>> getting the version information at runtime with musl...
>> So if we can detect that we are musl then the libc version should be
>> "musl" and the libpthread version should be "<integrated>" (or
>> something like that.
> That’s fair. My upcoming change will pass in the target C library as an
> explicit compiler define. Detecting it at runtime is AFAICT not
> possible. Once I have the change in place I can go back and update the
> values of these two “versions”.
>> I'm surprised there is no mechanism at all for runtime detection of musl!
>> But musl defines in unistd.h
>> #define _CS_GNU_LIBC_VERSION2
>> so won't those be reported by confstr ??
> Unfortunately not. confstr will return 0/EINVAL for almost all
> arguments. Those two defines are likely only there to make code compile
> at all with musl, but if confstr is actually called at runtime with any
> of those values it will return an error.

I can not make any sense out of:


Quality code - love the clear explanatory comments. :(


> Cheers,
> Mikael
>> Thanks,
>> David
>>> Cheers,
>>> Mikael

More information about the portola-dev mailing list