This is the mail archive of the
mailing list for the GCC project.
Re: ARM/THUMB long calls stubs
- From: Nick Clifton <nickc at redhat dot com>
- To: Andy Green <andy dot green at oxsemi dot com>
- Cc: rearnshaw at cambridge dot arm dot com, gcc-bugs at gcc dot gnu dot org
- Date: 09 Aug 2002 19:02:03 +0100
- Subject: Re: ARM/THUMB long calls stubs
- References: <3D4FF1FC.email@example.com>
> To anyone who can help(!),
> I have hit an issue with long calls on arm gcc (version 3.0.4 with the
> long-calls patch). I see someone else reported this issue on 30 April,
> has there been a resolution?
> The issue is as follows:
> void FnHi() __attribute__((section("high"))) __attribute__((long_call));
> void FnLo() __attribute__((section("low"))) __attribute__((long_call));
> I can call FnHi() from anywhere within the "low" section, however I
> cannot call FnLo() from the "high" section because the _call_via_rX
> stub is located in "low", and hence the call to _call_via_rX gets
> truncated by the linker.
> Is there a way to get gcc to generate the stubs in all sections?
[Note - this is a GCC bug not a binutils bug, so I am CC'ing this
reply to the GCC bugs list].
As things stand at the moment: "no".
Even if you could, it would not work, because the linker would just
complain about duplicate definitions of the _call_via_rX symbols. What
you would need is for gcc to generate branches to functions called
_call_via_rX_from_section_<foo> and then have it generate weak
versions of these functions in every compiled source file that uses
You might be able to achieve a similar effect through judicious use of
partial linking and special linker scrips. ie you could perform a
partial link of the "high" section code with libgcc.a to resolve all
of the references to __call_via_rX there. (Making sure that the
script used places the object file containing the _call_via_rX symbols
close to the "high" section). You could then do a similar partial
link for the "low" section. The strip out any remaining occurrences of
the _call_via_rX symbols and perform a final link. It *might* work....