* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
@ 2005-03-24 17:01 ` mmitchel at gcc dot gnu dot org
2005-03-24 17:06 ` mmitchel at gcc dot gnu dot org
` (21 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2005-03-24 17:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
2005-03-24 17:01 ` [Bug target/20617] [4.0/4.1 regression] " mmitchel at gcc dot gnu dot org
@ 2005-03-24 17:06 ` mmitchel at gcc dot gnu dot org
2005-03-24 17:31 ` schwab at suse dot de
` (20 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2005-03-24 17:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
2005-03-24 17:01 ` [Bug target/20617] [4.0/4.1 regression] " mmitchel at gcc dot gnu dot org
2005-03-24 17:06 ` mmitchel at gcc dot gnu dot org
@ 2005-03-24 17:31 ` schwab at suse dot de
2005-03-24 18:06 ` joern dot rennecke at st dot com
` (19 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: schwab at suse dot de @ 2005-03-24 17:31 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (2 preceding siblings ...)
2005-03-24 17:31 ` schwab at suse dot de
@ 2005-03-24 18:06 ` joern dot rennecke at st dot com
2005-03-24 18:17 ` joern dot rennecke at st dot com
` (18 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: joern dot rennecke at st dot com @ 2005-03-24 18:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (3 preceding siblings ...)
2005-03-24 18:06 ` joern dot rennecke at st dot com
@ 2005-03-24 18:17 ` joern dot rennecke at st dot com
2005-03-24 18:46 ` zack at codesourcery dot com
` (17 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: joern dot rennecke at st dot com @ 2005-03-24 18:17 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (4 preceding siblings ...)
2005-03-24 18:17 ` joern dot rennecke at st dot com
@ 2005-03-24 18:46 ` zack at codesourcery dot com
2005-03-24 19:36 ` mrs at apple dot com
` (16 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: zack at codesourcery dot com @ 2005-03-24 18:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (5 preceding siblings ...)
2005-03-24 18:46 ` zack at codesourcery dot com
@ 2005-03-24 19:36 ` mrs at apple dot com
2005-03-24 21:08 ` joern dot rennecke at st dot com
` (15 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: mrs at apple dot com @ 2005-03-24 19:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (6 preceding siblings ...)
2005-03-24 19:36 ` mrs at apple dot com
@ 2005-03-24 21:08 ` joern dot rennecke at st dot com
2005-03-24 21:25 ` joern dot rennecke at st dot com
` (14 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: joern dot rennecke at st dot com @ 2005-03-24 21:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (7 preceding siblings ...)
2005-03-24 21:08 ` joern dot rennecke at st dot com
@ 2005-03-24 21:25 ` joern dot rennecke at st dot com
2005-03-24 22:48 ` kkojima at gcc dot gnu dot org
` (13 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: joern dot rennecke at st dot com @ 2005-03-24 21:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (8 preceding siblings ...)
2005-03-24 21:25 ` joern dot rennecke at st dot com
@ 2005-03-24 22:48 ` kkojima at gcc dot gnu dot org
2005-03-24 22:53 ` geoffk at gcc dot gnu dot org
` (12 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: kkojima at gcc dot gnu dot org @ 2005-03-24 22:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (9 preceding siblings ...)
2005-03-24 22:48 ` kkojima at gcc dot gnu dot org
@ 2005-03-24 22:53 ` geoffk at gcc dot gnu dot org
2005-03-24 22:54 ` zack at codesourcery dot com
` (11 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2005-03-24 22:53 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC|geoffk at geoffk dot org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (10 preceding siblings ...)
2005-03-24 22:53 ` geoffk at gcc dot gnu dot org
@ 2005-03-24 22:54 ` zack at codesourcery dot com
2005-03-24 23:49 ` joern dot rennecke at st dot com
` (10 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: zack at codesourcery dot com @ 2005-03-24 22:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (11 preceding siblings ...)
2005-03-24 22:54 ` zack at codesourcery dot com
@ 2005-03-24 23:49 ` joern dot rennecke at st dot com
2005-03-24 23:54 ` zack at codesourcery dot com
` (9 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: joern dot rennecke at st dot com @ 2005-03-24 23:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (12 preceding siblings ...)
2005-03-24 23:49 ` joern dot rennecke at st dot com
@ 2005-03-24 23:54 ` zack at codesourcery dot com
2005-03-25 0:30 ` kkojima at gcc dot gnu dot org
` (8 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: zack at codesourcery dot com @ 2005-03-24 23:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (13 preceding siblings ...)
2005-03-24 23:54 ` zack at codesourcery dot com
@ 2005-03-25 0:30 ` kkojima at gcc dot gnu dot org
2005-03-29 11:54 ` joern dot rennecke at st dot com
` (7 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: kkojima at gcc dot gnu dot org @ 2005-03-25 0:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (14 preceding siblings ...)
2005-03-25 0:30 ` kkojima at gcc dot gnu dot org
@ 2005-03-29 11:54 ` joern dot rennecke at st dot com
2005-03-29 12:43 ` kkojima at gcc dot gnu dot org
` (6 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: joern dot rennecke at st dot com @ 2005-03-29 11:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (15 preceding siblings ...)
2005-03-29 11:54 ` joern dot rennecke at st dot com
@ 2005-03-29 12:43 ` kkojima at gcc dot gnu dot org
2005-04-06 19:32 ` amylaar at gcc dot gnu dot org
` (5 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: kkojima at gcc dot gnu dot org @ 2005-03-29 12:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (16 preceding siblings ...)
2005-03-29 12:43 ` kkojima at gcc dot gnu dot org
@ 2005-04-06 19:32 ` amylaar at gcc dot gnu dot org
2005-04-06 20:03 ` zack at codesourcery dot com
` (4 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: amylaar at gcc dot gnu dot org @ 2005-04-06 19:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (17 preceding siblings ...)
2005-04-06 19:32 ` amylaar at gcc dot gnu dot org
@ 2005-04-06 20:03 ` zack at codesourcery dot com
2005-07-06 14:28 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: zack at codesourcery dot com @ 2005-04-06 20:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (18 preceding siblings ...)
2005-04-06 20:03 ` zack at codesourcery dot com
@ 2005-07-06 14:28 ` pinskia at gcc dot gnu dot org
2005-07-16 3:46 ` zack at codesourcery dot com
` (2 subsequent siblings)
22 siblings, 0 replies; 32+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-07-06 14:28 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (19 preceding siblings ...)
2005-07-06 14:28 ` pinskia at gcc dot gnu dot org
@ 2005-07-16 3:46 ` zack at codesourcery dot com
2005-07-16 20:14 ` pinskia at gcc dot gnu dot org
2005-09-27 16:14 ` [Bug target/20617] [4.0/4.1 Regression] " mmitchel at gcc dot gnu dot org
22 siblings, 0 replies; 32+ messages in thread
From: zack at codesourcery dot com @ 2005-07-16 3:46 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC|zack at codesourcery dot com|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (20 preceding siblings ...)
2005-07-16 3:46 ` zack at codesourcery dot com
@ 2005-07-16 20:14 ` pinskia at gcc dot gnu dot org
2005-09-27 16:14 ` [Bug target/20617] [4.0/4.1 Regression] " mmitchel at gcc dot gnu dot org
22 siblings, 0 replies; 32+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-07-16 20:14 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/20617] [4.0/4.1 Regression] shared SH libgcc is exporting too many symbols
2005-03-24 11:22 [Bug target/20617] New: " amylaar at gcc dot gnu dot org
` (21 preceding siblings ...)
2005-07-16 20:14 ` pinskia at gcc dot gnu dot org
@ 2005-09-27 16:14 ` mmitchel at gcc dot gnu dot org
22 siblings, 0 replies; 32+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2005-09-27 16:14 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.0.2 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
^ permalink raw reply [flat|nested] 32+ messages in thread