[Bug target/20617] New: shared SH libgcc is exporting too many symbols

[Bug target/20617] New: shared SH libgcc is exporting too many symbols

[amylaar at gcc dot gnu dot org]

The SH lib1funcs.asm contains numerous small functions that save code size
for a static link, but still are smaller than the PLT size for all
link-compatible subtargets (1).  Such functions
should never be exported from a shared libgcc.

(1) If, say, there is a function that is large for the SH3, it may make make
sense to export it from the SH3 libgcc.so, and if so, it also has to be in
an sh4-nofpu libgcc.so.  However, that is not a reason to put it into an SH4
libgcc.so, since SH4 libraries use a different ABI.  Functions that are
used/largish only on SH1 are of no concern, because this processor lacks some
instructions usesd for SH PIC code, hence there is no point exporting these
functions.  Likewise, since the SH2 has no MMU, functions that are only needed/
largish for SH2 should stay out of libgcc.so for all OSes that need an MMU.

-- 
           Summary: shared SH libgcc is exporting too many symbols
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: amylaar at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sh*-*-linux*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-24 11:43 -------
I propose to back out the sh specific part of the following patch on
the gcc 4.0 branch.  This should be done before the 4.0 release, in
order to avoid people being stuck with shared objects that
reference symbols in libgcc.so that should never have been exported:

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01346.html

2004-11-16  Zack Weinberg  <zack@codesourcery.com>

        * mkmap-flat.awk, mkmap-symver.awk: If the last version
        assigned to a symbol was '%exclude', do not emit it anywhere.
        If leading_underscore is true, prefix all symbols from the
        version scripts with a leading underscore before comparing
        them with nm output or emitting them.  Remove support for dot
        symbols.
        * config/t-slibgcc-darwin (SHLIB_LINK): Use mkmap-flat.awk.
        (SHLIB_MAPFILES): Use libgcc-std.ver.
        (SHLIB_MKMAP_OPTS): Enable leading-underscore mode.
        (SHLIB_LINK): Add -Wl,-exported_symbols_list,$(SHLIB_MAP).
        * config/sh/t-linux: Use the normal libgcc-std.ver, plus
        libgcc-excl.ver and libgcc-glibc.ver.

        * config/sh/libgcc-excl.ver: New file.
        * config/sh/libgcc-std.ver, libgcc-darwin.ver: Delete.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drow at false dot org,
                   |                            |geoffk at geoffk dot org,
                   |                            |zack at codesourcery dot
                   |                            |com, kkojima at rr dot iij4u
                   |                            |dot or dot jp
      Known to work|                            |3.4.3
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-24 12:12 -------
*** Bug 20616 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|critical                    |normal
   Target Milestone|4.0.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2005-03-24 16:06 -------
Subject: Re:  shared SH libgcc is exporting too many
 symbols


Why not just add the problematic symbols to sh/libgcc-excl.ver?  That
is what it is there for.

zw


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-24 16:24 -------
Subject: Bug 20617

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	amylaar@gcc.gnu.org	2005-03-24 16:24:45

Modified files:
	gcc            : ChangeLog 
	gcc/config/sh  : lib1funcs.asm 

Log message:
	Band aid for PR target/20617:
	* config/sh/lib1funcs.asm (FUNC, ALIAS): Add .hidden directive.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.81&r2=2.7592.2.82
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/lib1funcs.asm.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.40&r2=1.40.34.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-24 16:30 -------
Subject: Re:  shared SH libgcc is exporting too many symbols

pinskia at gcc dot gnu dot org wrote:

>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>                 CC|                            |pinskia at gcc dot gnu dot
>                   |                            |org
>           Severity|critical                    |normal
>   Target Milestone|4.0.0                       |---

Since you are not prepared to take this seriously, I have checked in the attached patch
into the 4.0 branch without testing.  A broken 4.0.0 release is a lesser hazard that to
be stuck with some hundred unwanted exported symbols forever.






2005-03-24  J"orn Rennecke <joern.rennecke@st.com>

	Band aid for PR target/20617:
	* config/sh/lib1funcs.asm (FUNC, ALIAS): Add .hidden directive.

Index: config/sh/lib1funcs.asm
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sh/lib1funcs.asm,v
retrieving revision 1.40
retrieving revision 1.40.34.1
diff -p -r1.40 -r1.40.34.1
*** config/sh/lib1funcs.asm	29 Jul 2004 22:27:43 -0000	1.40
--- config/sh/lib1funcs.asm	24 Mar 2005 16:24:44 -0000	1.40.34.1
*************** Boston, MA 02111-1307, USA.  */
*** 37,45 ****
     ELF local label prefixes by J"orn Rennecke
     amylaar@cygnus.com  */
  
  #ifdef __ELF__
  #define LOCAL(X)	.L_##X
! #define FUNC(X)		.type X,@function
  #define ENDFUNC0(X)	.Lfe_##X: .size X,.Lfe_##X-X
  #define ENDFUNC(X)	ENDFUNC0(X)
  #else
--- 37,55 ----
     ELF local label prefixes by J"orn Rennecke
     amylaar@cygnus.com  */
  
+ #define ALIAS(X,Y)	.global GLOBAL(X); .set GLOBAL(X),GLOBAL(Y)
+ 
  #ifdef __ELF__
  #define LOCAL(X)	.L_##X
! 
! #if 1 /* ??? The export list mechanism is broken, everything that is not
! 	 hidden is exported.  */
! #undef FUNC
! #define FUNC(X)		.type X,@function  .hidden X
! #undef ALIAS
! #define ALIAS(X,Y)	.global GLOBAL(X); .set GLOBAL(X),GLOBAL(Y); .hidden GLOBAL(X)
! #endif
! 
  #define ENDFUNC0(X)	.Lfe_##X: .size X,.Lfe_##X-X
  #define ENDFUNC(X)	ENDFUNC0(X)
  #else
*************** Boston, MA 02111-1307, USA.  */
*** 52,58 ****
  #define	GLOBAL0(U,X)	CONCAT(U,__##X)
  #define	GLOBAL(X)	GLOBAL0(__USER_LABEL_PREFIX__,X)
  
- #define ALIAS(X,Y)	.global GLOBAL(X); .set GLOBAL(X),GLOBAL(Y)
  
  #if defined __SH5__ && ! defined __SH4_NOFPU__ && ! defined (__LITTLE_ENDIAN__)
  #define FMOVD_WORKS
--- 62,67 ----


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] shared SH libgcc is exporting too many symbols

[drow at gcc dot gnu dot org]

------- Additional Comments From drow at gcc dot gnu dot org  2005-03-24 16:49 -------
Joern, why are you committing patches to 4.0 without testing?  The release isn't
_that_ imminent.  Also, did you see Zack's suggestion?  And Mark did ask that
no one add 4.0.0 milestones without talking to him first.

Andrew, why did you downgrade this bug?  I don't understand why you are overriding
target maintainers' decisions on severity.  I am bumping it back up to critical.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com
           Severity|normal                      |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-03-24 17:01 -------
This is a wrong-code regression, and, as such, it's a "critical" bug for 4.0,
except that SH is not a primary or secondary platform.  As such, SH bugs should
never have a target milestone; they should just have [4.0 regression] in their
titles.  I've updated the title.

I'm not sure to what Joern's comment regarding Zack taking things seriously
refers.  I'm sure that Zack would agree that exporting too many symbols is a
serious problem.  It does seem like it would be nice to use the general facility
that Zack created for excluding symbols, unless that does not work.  I don't
know whether there's some good reason it can't work for SH, though.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|shared SH libgcc is         |[4.0/4.1 regression] shared
                   |exporting too many symbols  |SH libgcc is exporting too
                   |                            |many symbols


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-03-24 17:05 -------
Dan points out that Joern was probably referring to Andrew's downgrade, rather
than Zack's comment, when speaking about seriousness.

I'm not sure what prompted Andrew to make that change, but I certainly think
it's reasonable for target maintainers to set the severity for bugs that affect
their ports.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[schwab at suse dot de]

------- Additional Comments From schwab at suse dot de  2005-03-24 17:31 -------
Subject: Re:  shared SH libgcc is exporting too many
 symbols

Joern RENNECKE <joern.rennecke@st.com> writes:

> ! #define FUNC(X)		.type X,@function  .hidden X
                                                 ^^
I think you need a semicolon here.

Andreas.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-24 18:06 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

schwab at suse dot de wrote:

>    
>
>>! #define FUNC(X)		.type X,@function  .hidden X
>>    
>>
>                                                 ^^
>I think you need a semicolon here.
>
Thanks, added.
   



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-24 18:17 -------
Subject: Re:  shared SH libgcc is exporting too many symbols

zack at codesourcery dot com wrote:

>------- Additional Comments From zack at codesourcery dot com  2005-03-24 16:06 -------
>Subject: Re:  shared SH libgcc is exporting too many
> symbols
>
>
>Why not just add the problematic symbols to sh/libgcc-excl.ver?  That
>is what it is there for.
>
Almost all the symbols in config/sh/lib1funcs.asm are problematic.  
Moreover, adding a new function to lib1funcs.asm
can inadvertantly create a new exported symbol.  It is much safer to 
make the symbols by default not exported.

I'm currently working on merging most of the machine-dependent patches 
from our sources into gcc 4.1 - that's a 400 KB patch -
and this will change most of the FUNC definitions in lib1funcs.asm to 
HIDDEN_FUNC, and all the ALIAS defintions
into HIDDEN_ALIAS, and also change the way references to symbols in 
lib1funcs.asm are generated, so that for some
symbols GOT references are made rather than PLT ones when compiling 
pic/PIC code.
   



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2005-03-24 18:46 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
 exporting too many symbols

"joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> writes:

> Almost all the symbols in config/sh/lib1funcs.asm are problematic.
> Moreover, adding a new function to lib1funcs.asm can inadvertantly
> create a new exported symbol.  It is much safer to make the symbols
> by default not exported.

You may want to consider use of LIB1FUNCS_ST instead of LIB1FUNCS, so
that the symbols are not put into libgcc_s.so in the first place.

> I'm currently working on merging most of the machine-dependent
> patches from our sources into gcc 4.1 - that's a 400 KB patch - and
> this will change most of the FUNC definitions in lib1funcs.asm to
> HIDDEN_FUNC, and all the ALIAS defintions into HIDDEN_ALIAS, and
> also change the way references to symbols in lib1funcs.asm are
> generated, so that for some symbols GOT references are made rather
> than PLT ones when compiling pic/PIC code.

This sounds fine.  I want to make sure that you understand the point
of my patch to remove the local copy of libgcc-std.ver.  From time to
time new global symbols are added to libgcc2.c.  Most of those are
appropriately visible from libgcc_s.so; in some cases it can be
essential that they are.  If an architecture has a private copy of the
version file, we have to remember to update it.  I observed that
people were forgetting to update SH's private copy, so I eliminated it.

Note that the private copy that you had, did *not* exclude hundreds of
lib1funcs.asm symbols.  The only symbols not in it, that were in
libgcc-std.ver, and were not due to people forgetting to update it,
are the symbols currently listed in sh/libgcc-excl.ver.

zw


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[mrs at apple dot com]

------- Additional Comments From mrs at apple dot com  2005-03-24 19:36 -------
Subject: Re:  shared SH libgcc is exporting too many symbols

On Mar 24, 2005, at 8:30 AM, Joern RENNECKE wrote:
> ! #if 1 /* ??? The export list mechanism is broken, everything that  
> is not
> !      hidden is exported.  */
> ! #undef FUNC
> ! #define FUNC(X)        .type X,@function  .hidden X
> ! #undef ALIAS
> ! #define ALIAS(X,Y)    .global GLOBAL(X); .set GLOBAL(X),GLOBAL 
> (Y); .hidden GLOBAL(X)
> ! #endif

Could you add a reference to the PR in the code, as the next person  
to play with this will find it useful.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-24 21:08 -------
Subject: Re:  shared SH libgcc is exporting too many symbols

Mike Stump wrote:

>    
> Could you add a reference to the PR in the code, as the next person  
> to play with this will find it useful.
>
>
Done.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-24 21:25 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

zack at codesourcery dot com wrote:

>  You may want to consider use of LIB1FUNCS_ST instead of LIB1FUNCS, so

>that the symbols are not put into libgcc_s.so in the first place.
>
Won't this have the effect that any of the referenced symbols remain 
undefined
in libgc_s.so, and will get a GOT (and in 4.0 even a PLT entry) in 
libgcc.so?
Some functions may not ue the PLT because of register usage.  And most of
the rest is really smaller than a PLT entry, so a copy should be linked 
hidden into
every dso that needs it.  Including libgcc.so .   

>Note that the private copy that you had, did *not* exclude hundreds of
>lib1funcs.asm symbols.  The only symbols not in it, that were in
>libgcc-std.ver, and were not due to people forgetting to update it,
>are the symbols currently listed in sh/libgcc-excl.ver.
>
I didn't say hundreds - I said some hundred.  greps counts 94 hidden 
functions
ans aliases in my current lib1funcs.asm working copy.  The largest 
group, with
40 members,  is probably the set of movstr* and movmem* functions, none of
which was mentioned in libgcc-std.ver (and hence was excluded), and none of
which is mentioned in sh/libgcc-excl.ver (and hence is now included).



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[kkojima at gcc dot gnu dot org]

------- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-24 22:48 -------
I thought that mklibgcc makes such functions hidden if SHLIB_LINK
was defined.  In my daily build of sh4-unknown-linux-gnu, all
movstr* and movmem* are hidden:

     ...
     6: 00000050     4 FUNC    GLOBAL HIDDEN    1 __movmemSI0
     7: 00000010    68 FUNC    GLOBAL HIDDEN    1 __movmemSI64
     8: 00000010    68 FUNC    GLOBAL HIDDEN    1 __movstrSI64
     9: 00000014    64 FUNC    GLOBAL HIDDEN    1 __movmemSI60
     ...

Of course, I don't object Joern's patch.  It seems fine and also
to be safer than the mklibgcc magic for SH lib1funcs.asm.  I'm
simply curious why that magic doesn't work for Joern.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[geoffk at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|geoffk at geoffk dot org    |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2005-03-24 22:54 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
 exporting too many symbols

"joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[LIB1FUNCS_ST]
> Won't this have the effect that any of the referenced symbols remain
> undefined in libgc_s.so, and will get a GOT (and in 4.0 even a PLT
> entry) in libgcc.so? 

You can avoid this problem by including libgcc.a in the final link of
libgcc_s.so.  Every global symbol in libgcc.a is or ought to be hidden
(that being a goal of all the work I put in on libgcc construction
last year) so the effect will be that libgcc_s.so gets private copies
of everything that it actually uses, but nothing more.

> I didn't say hundreds - I said some hundred.  greps counts 94 hidden
> functions ans aliases in my current lib1funcs.asm working copy.  The
> largest group, with 40 members, is probably the set of movstr* and
> movmem* functions, none of which was mentioned in libgcc-std.ver
> (and hence was excluded), and none of which is mentioned in
> sh/libgcc-excl.ver (and hence is now included).

It sounds like you are misunderstanding the way libgcc-excl.ver works?
It subtracts from the set established by libgcc-std.ver, not from the
set of all symbols that could be visible.  (If this is not happening,
there is a problem with your t-fragments or with mklibgcc.)

zw


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-24 23:49 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

kkojima at gcc dot gnu dot org wrote:

>------- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-24 22:48 -------
>I thought that mklibgcc makes such functions hidden if SHLIB_LINK
>was defined.  In my daily build of sh4-unknown-linux-gnu, all
>  
>
Oh, it seems that I misunderstood the role of config/sh/libgcc-excl.ver .
The comment at the top of that file suggested to me that this is the list of
symbols excluded from libgcc.so .  So you are saying this needs to list
only to-be-excluded symbols that are mentioned in libgcc-std.ver, and
all the other symbols from lib1funcs.asm are automatically hidden?

FWIW, __mulsi3 should also not be exported, although that
is not a regression.
   



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2005-03-24 23:54 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
 exporting too many symbols

"joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> writes:

> So you are saying this needs to list only to-be-excluded symbols
> that are mentioned in libgcc-std.ver, and all the other symbols from
> lib1funcs.asm are automatically hidden?

Yes, that is how it is supposed to work.  If it isn't working that
way, either mklibgcc or your t-fragment is buggy.

> FWIW, __mulsi3 should also not be exported, although that is not a
> regression.

Feel free to add it to libgcc-excl.ver...

zw


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[kkojima at gcc dot gnu dot org]

------- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-25 00:30 -------
"joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
> FWIW, __mulsi3 should also not be exported, although that is not a
> regression.

For the efficiency, yes.  Unfortunately, it causes the binary
compatibility problem for the old binaries refering __mulsi3@*.
At least, SH linux has too many such binaries already.

BTW, I could find the use of libgcc-excl.ver in t-linux only.
All targets which make the shared libgcc with the ordinally SH
PIC ABI should use it or similar excl.ver, shouldn't they?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

------- Additional Comments From joern dot rennecke at st dot com  2005-03-29 11:54 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

kkojima at gcc dot gnu dot org wrote:

>------- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-25 00:30 -------
>"joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
>  
>
>>FWIW, __mulsi3 should also not be exported, although that is not a
>>regression.
>>    
>>
>
>For the efficiency, yes.  Unfortunately, it causes the binary
>compatibility problem for the old binaries refering __mulsi3@*.
>At least, SH linux has too many such binaries already.
>
Does it, actually?  The mulsi3_call-1 pattern is only used for SH1 code.   

>
>BTW, I could find the use of libgcc-excl.ver in t-linux only.
>All targets which make the shared libgcc with the ordinally SH
>PIC ABI should use it or similar excl.ver, shouldn't they?
>
Yes, they should.
   



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[kkojima at gcc dot gnu dot org]

------- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-29 12:43 -------
"joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> wrote:
> Does it, actually?  The mulsi3_call-1 pattern is only used for SH1 code.   

Ah, you are right.  Sorry for my mess.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-06 19:32 -------
(In reply to comment #17)
> Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
>  exporting too many symbols
> 
> "joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> [LIB1FUNCS_ST]
> > Won't this have the effect that any of the referenced symbols remain
> > undefined in libgc_s.so, and will get a GOT (and in 4.0 even a PLT
> > entry) in libgcc.so? 
> 
> You can avoid this problem by including libgcc.a in the final link of
> libgcc_s.so.  Every global symbol in libgcc.a is or ought to be hidden
> (that being a goal of all the work I put in on libgcc construction
> last year) so the effect will be that libgcc_s.so gets private copies
> of everything that it actually uses, but nothing more.
> 
I just had a look, and actually there appears to be no variable called
LIB1FUNCS_ST.  There is one called LIB2FUNCS_ST, but that's a place for
machine-independent static libgcc2 parts, and one called
LIB2FUNCS_STATIC_EXTRA.  The latter is actually a list of filenames, no
a list of pieces inside lib1funcs.asm, so I couldn't use it without major
butchery of the SH assembler support functions.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2005-04-06 20:03 -------
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
 exporting too many symbols

"amylaar at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> I just had a look, and actually there appears to be no variable called
> LIB1FUNCS_ST.

... so add one.

zw


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
   Target Milestone|---                         |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|zack at codesourcery dot com|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-16 20:13:43
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 Regression] shared SH libgcc is exporting too many symbols

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 Regression] shared SH libgcc is exporting too many symbols

[pinskia at gcc dot gnu dot org]

------- Comment #25 from pinskia at gcc dot gnu dot org  2005-10-13 19:57 -------
Moving to 4.2 as sh-linux-gnu is not a primary/secondary target.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617

[Bug target/20617] [4.0/4.1 Regression] shared SH libgcc is exporting too many symbols

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P5
   Target Milestone|4.2.0                       |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617