| Summary: | [11/12/13/14 Regression] shared SH libgcc is exporting too many symbols | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Jorn Wolfgang Rennecke <amylaar> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | drow, gcc-bugs, kkojima, mark, pinskia, vapier |
| Priority: | P5 | ||
| Version: | 4.0.0 | ||
| Target Milestone: | 11.5 | ||
| Host: | Target: | sh*-*-linux* | |
| Build: | Known to work: | 3.4.3 | |
| Known to fail: | 4.0.4 | Last reconfirmed: | 2005-07-16 20:13:43 |
|
Description
Jorn Wolfgang Rennecke
2005-03-24 11:21:42 UTC
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. *** Bug 20616 has been marked as a duplicate of this bug. *** 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 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 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 ---- 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. 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. 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. 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. 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. 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. 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 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.
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.
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). 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.
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 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.
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 "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? 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. "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. (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. 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 Moving to 4.2 as sh-linux-gnu is not a primary/secondary target. Will not be fixed in 4.1.1; adjust target milestone to 4.1.2. Closing 4.1 branch. Closing 4.2 branch. GCC 4.3.4 is being released, adjusting target milestone. GCC 4.3.5 is being released, adjusting target milestone. 4.3 branch is being closed, moving to 4.4.7 target. 4.4 branch is being closed, moving to 4.5.4 target. GCC 4.6.4 has been released and the branch has been closed. The 4.7 branch is being closed, moving target milestone to 4.8.4. GCC 4.8.4 has been released. The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3. GCC 4.9.3 has been released. GCC 4.9 branch is being closed GCC 6 branch is being closed The GCC 7 branch is being closed, re-targeting to GCC 8.4. GCC 8.4.0 has been released, adjusting target milestone. GCC 8 branch is being closed. GCC 9.4 is being released, retargeting bugs to GCC 9.5. GCC 9 branch is being closed GCC 10.4 is being released, retargeting bugs to GCC 10.5. GCC 10 branch is being closed. |