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