This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add private_function for private functions within glibc [BZ #21598]
On Tue, Aug 8, 2017 at 2:12 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Tue, 8 Aug 2017, 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 when shadow
>> stack is enabled. However, internal_function, which should be used only
>> with hidden function within libc.so, are also used with private function
>> calls between different shared objects of glibc.
>
> Should we consider it part of the ABI that users' shared objects, not just
> glibc ones, may export functions with regparm calling convention? It's
> certainly possible at present, but I don't know how widely used it is.
Some libraries do that:
https://sourceware.org/ml/libc-alpha/2017-06/msg01091.html
We have a similar issue on x86-64:
https://sourceware.org/bugzilla/show_bug.cgi?id=21265
CET enabled compiler should disallow __attribute__((regparm(3))) on
i386. When CET is disabled, __attribute__((regparm(3))) is OK.
>> This patch removes USE_REGPARMS from config.h.in. Instead, it defines
>> internal_function and private_function, which is for private function
>> calss between different shared objects, in config.h.in. Currently,
>> sysdeps/i386/configure.ac defines private_function as
>
> I'd expect these definitions to go in a sysdeps header (for which i386 has
> a version overriding the default version), as suggested in
> <https://sourceware.org/ml/libc-alpha/2014-06/msg00784.html>, rather than
> being defined directly from a configure.ac file.
I will do that.
Thanks.
--
H.J.