Re: [PATCH] Add wcharP.h to hide internal wchar functions [BZ #18822]

["H.J. Lu" <hjl.tools@gmail.com>]

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.