------- 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" <[EMAIL PROTECTED]> 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
