Date: Tue, 28 Aug 2012 14:03:22 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] libc: Do not export .cerror Message-ID: <20120828110322.GJ33100@deviant.kiev.zoral.com.ua> In-Reply-To: <20120824221655.GA76607@stack.nl> References: <20120824221655.GA76607@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--o1/0/m+AY5DY8EuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 25, 2012 at 12:16:55AM +0200, Jilles Tjoelker wrote: > For some reason, libc exports the symbol .cerror (HIDENAME(cerror)), > albeit in the FBSDprivate_1.0 version. It looks like there is no reason > for this since it is not used from other libraries. Given that it cannot > be accessed from C and its strange calling convention, it is rather > unlikely that other things rely on it. Perhaps it is from a time when > symbols could not be hidden.=20 Probably, the idea was that the symbol can be interposed. Not sure who wanted such functionality. >=20 > Not exporting .cerror causes it to be jumped to directly instead of via > the PLT. >=20 > The below patch is for i386 only and also takes advantage of .cerror's > new status by not saving and loading %ebx before jumping to it. > (Therefore, .cerror now saves and loads %ebx itself.) Where there was a > conditional jump to a jump to .cerror, the conditional jump has been > changed to jump to .cerror directly (many modern CPUs don't do static > prediction and in any case it is not much of a benefit anyway). Why do you need to save/restore the %ebx at all ? %ebx =3D=3D &__GLOBAL_OFFSET_TABLE__ is only needed when you access GOT, but .cerror only works with PLT, which is addressed using the instruction capable of relative addressing. The old .cerror does not need it as well, but it is just engraved in the function ABI. >=20 > The patch decreases the size of libc.so.7 by a few kilobytes. >=20 > Similar changes could be made to other architectures, and there may be > more symbols that are exported but need not be. Sure, would you handle at least amd64 too ? --o1/0/m+AY5DY8EuM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA8pXoACgkQC3+MBN1Mb4g4agCfVD+hxac270WlKmbGCVnmgtzA bE0AnilyIRW6+t6MVzmA0DPVVVjvoeZ8 =HuxN -----END PGP SIGNATURE----- --o1/0/m+AY5DY8EuM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120828110322.GJ33100>