This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: ARM EABI GNU/Linux libgcc
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org,mark at codesourcery dot com
- Date: Tue, 23 Nov 2004 14:11:14 +0000
- Subject: Re: PATCH: ARM EABI GNU/Linux libgcc
- Organization: CodeSourcery
- References: <200411230053.iAN0r9Bs005985@sirius.codesourcery.com>
On Tuesday 23 November 2004 00:53, Mark Mitchell wrote:
> Paul --
>
> With this patch, we're able to build EABI binaries that actually run.
>
> The simple part of this patch is the libgcc-bpabi.ver patch; we need
> to make more symbols part of the libgcc interface. My only questions
> is:
>
> * Does __gnu_unwind_execute need to have external linkage? It's
> declared "extern" -- but nothing seems to use it outside of the file
> where it's defined. In any case, I've not put it in the version map
> at this point.
This can be made static. I probably made it extern before I invented
__gnu_unwind_frame.
> The trickier part of this patch is support for .init_array. Since the
> EABI wants us to use .init_array, we have to arrange that. That means
> that things like the "-1" and "0" markers that we put in the .ctors
> array on most systems are unnecessary; with .init_array, the dynamic
> loader can compute the bounds.
This is probably the right thing to do, however it breaks arm-none-eabi. This
target doesn't have a dynamic loader, so currently uses the markers
in .init_array. The proper solution may be to somehow teach crtstuff.c about
the .{init,fini}_array sections.
Does teh dynamic loader DTRT with statically linked arm-linux-gnueabi
executables?
Paul