Subject: Re: softfloat fixuns woes
To: None <tech-toolchain@netbsd.org>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: tech-toolchain
Date: 11/02/2003 17:41:12
[uwe: cc to current-users dropped, as this follow-up concerns toolchain
technicalities and is not of much interest to current users]

On Sat, Nov 01, 2003 at 11:19:16 +0000, Richard Earnshaw wrote:

> 2) It completely breaks when using the new assembler/linker and a FSF 
> build of gcc-3.4, where libgcc is built with all the support functions 
> marked as .hidden (libraries are clearly intended to be built 
> self-contained or linked against the shared libgcc.so).  And the latest 
> versions of ld enforce this correctly.

Uh, oh.  Now I'm totally confused.

When I discussed the sh3 problem documented in toolchain/22452 with
Kaz Kojima, he mentioned this approach to me, i.e. mark them .hidden,
link -lgcc{,_pic} everywhere (however I didn't realize that in gcc-3.4
all symbols in libgcc are marked as .hidden).

At about the same time we had a PR about C++ exception handling not
working properly with shared libraries and Nick Hudson fixed it by
*NOT* linking -lgcc_pic into shared libraries.  However, note, that
our -lgcc_pic doesn't yet have its symbols .hidden - so may be that's
causing that PR about exceptions.  [sorry about being unspecific, but
I don't have the PR number written down and our web interface to gnats
sucks]

If marking all libgcc symbols .hidden, including the exception
handling code &c makes the exceptions work when libgcc_pic is linked
into every shared library - this will make both PRs (toolchain/22452
and the one about exceptions) fixed at once and also will save us the
trouble of doing all these dances with "libgcc0" (as I called the
library of .hidden symbols that is safe to link into each shared lib
&c).


PS: We provide some of the libgcc functions in libc (to make it
"self-contained"), we will need to move them to libgcc.

. libc no longer provides an interface it used to provide - a major bump?

. if we want to keep our implementations for those libgcc functions we
  will be linking our sources and libgcc sources, so we need to ensure
  the licenses are compatible (e.g. no ad clause, etc).


SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen