Subject: Re: softfloat fixuns woes
To: None <tech-toolchain@netbsd.org>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: tech-toolchain
Date: 11/10/2003 01:09:38
On Sun, Nov 02, 2003 at 17:41:12 +0300, Valeriy E. Ushakov wrote:
> 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).
So, any comments on the technical side of this (ignore the GPL for the
moment). I really hate to pester you, folks, but this is *the*
problem that prevents gcc3 switch being flipped for sh3.
SY, Uwe
--
uwe@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen