[RFC] Add C11 threads.h support.

My apologies for being off this long. I have finally made this work,
and I'm not getting errors with conform or linknamespace tests but I
had to exports some symbols like this.


I don't know if I'm actually allowed to do that, but I think it makes sense.

I think the whole patch set is ready for C11 threads.h (Including
manual and tests), but I don't expect it to make it for version 2.22
since it's frozen. Should I just send my patches here for a deep
review?

Cheers.

2015-07-01 2:22 GMT+09:00 Joseph Myers <joseph@codesourcery.com>:
> On Tue, 30 Jun 2015, Juan Manuel Torres Palma wrote:
>
>> I get all of your points now, it's unbelievable how much I'm learning
>> during the process, thanks for your guidance.
>>
>> After running the testsuite I'm getting error regarding the
>> linknamespace test and conform test. Conform tests errors don't make
>> me worry that much because they seem to appear on other headers too
>> and are being ignored. However, in linknamespace test appear a lot of
>> new functions that I didn't even think about that seem to be in user's
>> namespace.
>>
>> I attach my threads.h-data, linknamespace.out and conform.out for some
>> feedback.
>
> Most conform tests failures should be straightforward to fix.  Note that
> the results are currently clear for all ISO C versions; it's only other
> standards for which they haven't been fully cleaned up yet.  You have
> errors for the types of thrd_create and thrd_exit.  So check the types in
> both the header and the expectations.
>
> In the case of thrd_create, it seems you have the wrong type for the first
> argument in threads.h-data.  In the case of thrd_exit, there may be a
> trickier issue involved - try declaring it in the header using
> __attribute__ ((__noreturn__)) as done for other non-returning functions
> in standard headers, instead of _Noreturn - this is compatible with C11
> _Noreturn but the conform tests avoid it causing problems with typeof (for
> GNU C typeof, non-returning counts as part of the function's type, which
> affects how the tests for types of functions work).
>
> For the linknamespace tests, you'll need to investigate why all the lines
> such as
>
> [initial] thrd_create
>
> appear - this indicates something odd going on with the testsuite.
> Functions such as thrd_create should, given the makefile changes to add
> threads.h to the headers for C11, appear in the generated symlist-ISO11 as
> being in the implementation namespace for C11.  So you'll need to look at
> why list-header-symbols.pl, passed a list of headers including threads.h,
> failed to generate output indicating that those symbols are allowed (or
> why, if listed as allowed, they still show up as failing).
>
> Then, having resolved that issue so that linknamespace.out only lists
> symbols (the last symbol listed on each line is the one that the testsuite
> thinks is problematic) that reflect genuine bugs, each of those will need
> resolving, by making the relevant code call implementation-namespace
> versions.  For example, pthread_create will need to call various
> __pthread_* functions instead of plain pthread_*.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

On Sat, 1 Aug 2015, Juan Manuel Torres Palma wrote:

> +  GLIBC_2.22 {
> +    __mmap; __munmap; __mprotect;
> +  }
>    GLIBC_2.3 {
>      # f*
>      fgetxattr; flistxattr; fremovexattr; fsetxattr;
> 
> I don't know if I'm actually allowed to do that, but I think it makes sense.

If a symbol only needs exporting for use in other shared libraries, not 
for inline functions in public headers, functions from libc_nonshared.a 
etc., then it should be exported at version GLIBC_PRIVATE.

> I think the whole patch set is ready for C11 threads.h (Including
> manual and tests), but I don't expect it to make it for version 2.22
> since it's frozen. Should I just send my patches here for a deep
> review?

Yes.