On Sat, 28 Jul 2018 21:11:22 -0400 Rich Felker <[email protected]> wrote:
> On Sat, Jul 28, 2018 at 08:47:33PM +0200, Andreas Schwab wrote: > > On Jul 28 2018, [email protected] wrote: > > > > > From: Sergei Trofimovich <[email protected]> > > > > > > Cc: Ian Lance Taylor <[email protected]> > > > Cc: Jeff Law <[email protected]> > > > Cc: Andreas Schwab <[email protected]> > > > Signed-off-by: Sergei Trofimovich <[email protected]> > > > --- > > > 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
