This is the mail archive of the libc-alpha@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: [RFC] Add C11 threads.h support.


> I'm not sure it's useful without any targets that would define the types
> differently; I think bits/ headers are only needed where there are such
> target-dependencies (so bits/thread-shared-types.h is needed, but maybe
> not bits/threadstypes.h).

I have moved it to nptl/threadstypes.h now.

> You should update libpthread.abilist (all copies).  If you examine the
> diffs from "make check-abi" and confirm they are as expected, you can
> apply them to the copy of libpthread.abilist used in your configuration,
> and then copy the same entries to all other copies.
>
> The patch should also add documentation and testcases for all the
> functions, as well as updating the conform/ tests to cover the new header.

Works well, but it fails. I guess this is what I should expect because
the generated ABI with new symbols doesn't match with the ABI defined
in libpthread.abilist. However I get a symbol that I'm not really sure
of. It's _nl_default_dirname, that was originally defined to 0x12 and
after building it's defined to 0x43. Reading ChangeLog I couldn't
really get an idea of what this symbol is for.

> Each function should have a comment explaining its semantics in the
> header.  Argument names need to be in the implementation namespace (the
> conform/ tests will tell you if you get this wrong, once you've added
> threads.h data to them).  Stray space before ')'.

I have done this too, but I don't understand why argument names need
to be preceded of "__" in this case. I have seen it in other header
files, but why? I thought the assembler only cares about the types
defined in the function prototype.

> You need to call the implementation-namespace names such as
> __pthread_once.  It's not enough that they exist if you then use the other
> names for those functions; you must avoid any strong references (defined
> or undefined) to names outside the C11 and implementation namespaces (and
> any uses of weak undefined symbols outside those namespaces that might get
> executed for conforming code).

I don't get this point either. I thought this code will be executing
inside the library, where __pthread_* symbols are exactly the same
than pthread_* symbols. So, if the user redefines pthread_* symbols
(He's a llowed to do that), won't affect symbols inside library. Am I
wrong?

Thanks for your help.
Cheers.

-- 
Juan Manuel Torres Palma.
Computer Science Student at Universidad de Granada.


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