This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add wcharP.h to hide internal wchar functions [BZ #18822]
On Tue, Dec 12, 2017 at 2:57 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/12/2017 12:40 AM, Joseph Myers wrote:
>>
>> On Mon, 11 Dec 2017, Florian Weimer wrote:
>>
>>> We should enhance the toolchain to do this kind of optimization
>>> automatically
>>> (maybe using LTO?). Or find another way to implement the markup in a
>>> more
>>
>>
>> glibc makes use of being written as "C with ABI boundaries" - that is,
>> code does things that are undefined in C for the program as a whole, but
>> defined on the basis that each separate translation unit must implement
>> the semantics of the functions therein in a way that would be valid for
>> any valid caller. I think supporting LTO for glibc would be hard.
>
>
> Certainly for some parts of the library. But not for high-level routines
> such as fnmatch or wcsxfrm_l.
>
> Anyway, the point I was trying to make is that some optimizations need to
> happen at the compiler or linker level, otherwise the maintenance burden is
> too costly. Functions in the public API already need to be declared in
> three places in many cases, and I think it's unwise to add an arbitrary
> number of architecture-specific header files into the mix.
I don't believe GCC can do it on its own without attribute. Even with
attribute, GCC can't do it properly for builtin functions:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
Since we need to support more than one architecture and each architecture
has different requirements, we can't avoid multiple header files. At minimum,
for each architecture, a public header file, foo.h, may need
1. foo.h. Public header file.
2. include/foo.h. Common internal header file.
3. foo-hidden.h. Architecture specific header file to hide more
internal functions.
Of course, we can just use the public foo.h and pay the price.
>>> It's also not clear why you need to replicate ___atribute_pure__ in those
>>> declarations.
>>
>>
>> Generally, an internal header can avoid repeating a function prototype
>> using typeof, but typeof does not copy attributes, so making an internal
>> declaration share the attributes of a public declaration requires
>> duplicating them in both places.
>
>
> I thought that these attributes were cumulative, so attribute_hidden would
> just be added to the attributes declared in include/wchar.h for those
> internal aliases.
That isn't the case for these attributes.
--
H.J.