This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Always link against static libgcc on hppa-linux
- From: Mark Mitchell <mark at codesourcery dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: "dje at watson dot ibm dot com" <dje at watson dot ibm dot com>, "rth at redhat dot com" <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 13 Feb 2002 15:45:49 -0800
- Subject: Re: Always link against static libgcc on hppa-linux
> The millicode routines implement some basic arithmetic functions
> and $$dyncall for indirect calls. The millicode routines have a
> special calling convention that require static linkage. The
> shared version of libgcc on hppa-linux contains the millicode
> routines but these are only used internally, and they are not
> visible to code outside the library.
OK, I think I understand. I will restate to be sure:
1. There are some special support routines required on hppa-linux.
2. They can only be called from within the same shared object
(treating the main program here as a special case of shared
object) because of their calling convention.
3. Historically, these routines were in libgcc. Since libgcc was
linked statically into every shared object, there was no issue.
4. Now, we have a shared libgcc. On most platforms, one wants to
link with either the static libgcc, or the shared version, but
not both -- that can cause a variety of known EH problems, one
of which David seems to have (re)discovered. However, on
hppa-linux, if we don't link with the static libgcc, we are
missing the critical support routines.
The solution that seems best to me (perhaps naively) would be to put
these routines in the crt*.o files. Do you use those on hppa-linux?
Those files are linked in with every shared object, so you would get
the routines automatically, and statically as you require.
I believe that David's patch makes sense conceptually; we should only
be linking in one copy of libgcc in each executable.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com