This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Add private_function for private functions within glibc
On Thu, Jun 22, 2017 at 7:41 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/22/2017 04:38 PM, H.J. Lu wrote:
>> On Thu, Jun 22, 2017 at 6:40 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/17/2017 03:59 PM, H.J. Lu wrote:
>>>> Here parameters are passed to _dl_init in registers. I want to minimize
>>>> changes to avoid any potential issues.
>>>
>>> Well, as a rule of thumb, if we do something that breaks our own code,
>>> it is pretty much guaranteed to wreak havoc across the board (because
>>> our test coverage is somewhat poor).
>>>
>>> I see a lot of use of regparm (3). For example:
>>>
>>> $ echo '#include <Qt/qchar.h>' | g++ -m32 -E -x c++ - | grep regparm
>>> static Category __attribute__((regparm(3))) category(uint ucs4);
>>> static Category __attribute__((regparm(3))) category(ushort ucs2);
>>> static Direction __attribute__((regparm(3))) direction(uint ucs4);
>>> static Direction __attribute__((regparm(3))) direction(ushort ucs2);
>>> static Joining __attribute__((regparm(3))) joining(uint ucs4);
>>> …
>>>
>>> I think these calls actually cross DSO boundaries.
>>
>> I don't think so. See "static ...".
>
> It's C++ code, so it just means there's no this pointer.
>
Compiler should issue an error if SHSTK is enabled when compiling
this code. Only regparm (2) or less is allowed on public functions
with SHSTK.
--
H.J.