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>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 17 Jun 2017 15:42:17 +0200
- Subject: Re: [PATCH 1/2] Add private_function for private functions within glibc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.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 D72DA61BB2
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D72DA61BB2
- References: <20170617130612.GA14641@gmail.com>
On 06/17/2017 03:06 PM, H.J. Lu wrote:
> since shadow stack doesn't match return stack. We need to use register
> indirect branch via %ecx. That means only 2 parameters can be passed
> in registers for external function calls with lazy binding. However,
> internal_function, which should be used only with hidden function, is
> defined as
>
> # define internal_function __attribute__ ((regparm (3), stdcall))
>
> and used with private function calls between different shared objects of
> glibc. We introduce private_function for such purpose:
>
> # define private_function __attribute__ ((regparm (2), stdcall))
>
> so that %ecx can be used by _dl_runtime_resolve as scratch register.
>
> Any comments?
I have previously suggested to get rid of internal_function. For
example, applying it to static functions is generally unnecessary, but
we still do that a lot. (I know the static linkage case isn't what you
are after here.)
I wonder what the change in code size due to a change from 3 to 2 to 0
register parameters is.
But even if we fix glibc's own use of register parameters, we risk
running into bugs like bug 21265. I'm not sure if this is worth the
trouble at this point, especially since i386 has to be considered a
legacy architecture at this point.
Thanks,
Florian