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
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 22 Jun 2017 16:41:10 +0200
- Subject: Re: [PATCH 1/2] Add private_function for private functions within glibc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com EC173C04D2B7
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EC173C04D2B7
- References: <20170617130612.GA14641@gmail.com> <8e5d92f2-cc2c-2042-7438-56436e8fa1d0@redhat.com> <CAMe9rOopa-+2ZoS2K5bQtMXPjuZQLRWAqDpz7+kQN8p3EAH=Fw@mail.gmail.com> <9cdb9636-292e-e411-5517-f1544dcab1be@redhat.com> <CAMe9rOphqvDKy5sJNyp+XRpPG5o7kmS+GdmJs+KE8ZTAnwYi3g@mail.gmail.com>
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.
Florian