This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
- From: "joern dot rennecke at st dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Mar 2005 11:54:36 -0000
- Subject: [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
- References: <20050324112142.20617.amylaar@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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