This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Removing internal_function
- From: Florian Weimer <fweimer at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 3 Apr 2017 17:06:55 +0200
- Subject: Removing internal_function
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.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 90C448046B
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 90C448046B
Should we remove internal_function? It's only used on i386 and causes
portability hazards due to the i386-specific build failures it can
introduce. (Unlike attribute_hidden and most other function attributes,
internal_function has to be repeated on both declaration and definition.)
internal_function specifies an alternative calling convention. For
static functions, GCC has been doing similar optimizations for a long
time. I assume internal_function could disable those optimizations by
explicitly specifying a different (less optimal) calling convention.
The original intent was that internal_function would not be used across
DSO boundaries (because the non-ABI calling convention), but we no
longer stick to that.
Disabling internal_function appears to increase the text size of
libc.so.6 by about 8K, or 0.45%. Considering the relative importance of
the i386 target today, I think this is a reasonable trade-off for the
avoidance of spurious build failures.
Comments?
Thanks,
Florian