From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1899 invoked by alias); 24 Mar 2005 22:54:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1812 invoked by alias); 24 Mar 2005 22:54:14 -0000 Date: Thu, 24 Mar 2005 22:54:00 -0000 Message-ID: <20050324225414.1807.qmail@sourceware.org> From: "zack at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050324112142.20617.amylaar@gcc.gnu.org> References: <20050324112142.20617.amylaar@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg02953.txt.bz2 List-Id: ------- 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" 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