On Sat, 28 Jul 2018 21:11:22 -0400 Rich Felker <dal...@libc.org> wrote:
> On Sat, Jul 28, 2018 at 08:47:33PM +0200, Andreas Schwab wrote: > > On Jul 28 2018, sly...@inbox.ru wrote: > > > > > From: Sergei Trofimovich <sly...@gentoo.org> > > > > > > Cc: Ian Lance Taylor <i...@airs.com> > > > Cc: Jeff Law <l...@redhat.com> > > > Cc: Andreas Schwab <sch...@linux-m68k.org> > > > Signed-off-by: Sergei Trofimovich <sly...@gentoo.org> > > > --- > > > libgcc/config/m68k/lb1sf68.S | 19 ++++++++++++++----- > > > 1 file changed, 14 insertions(+), 5 deletions(-) > > > > > > diff --git a/libgcc/config/m68k/lb1sf68.S b/libgcc/config/m68k/lb1sf68.S > > > index 325a7c17d9b..16c6dc3f5a7 100644 > > > --- a/libgcc/config/m68k/lb1sf68.S > > > +++ b/libgcc/config/m68k/lb1sf68.S > > > @@ -435,7 +435,10 @@ $_exception_handler: > > > .text > > > FUNC(__mulsi3) > > > .globl SYM (__mulsi3) > > > + .globl SYM (__mulsi3_internal) > > > + .hidden SYM (__mulsi3_internal) > > > > No need for extra entry symbols, just mark the real entry point as > > hidden, like in the static library. > > That's clearly not correct or valid, as these are public interfaces. > If you make them hidden they'll be dropped from the dynamic symbol > table of libgcc_s.so. > > Of course for libgcc.a they need to be hidden (it's an ABI bug if > they're not hidden there already but I think there's a separate layer > of the build system that forces them to be hidden). > > Rich Oh, that's a good point! gcc/doc/libgcc.texi also suggests __<symbols> is the libgcc_s API. Would it make sense for gcc/doc/libgcc.texi to be expanded to more explicitly articulate expectation of symbol visibility on ELF platforms? -- Sergei
pgpFr9m_8Gb8s.pgp
Description: Цифровая подпись OpenPGP
