libgcc: use linker script for libgcc_s.so on xtensa

Submitted by Baruch Siach on Jan. 19, 2014, 9:21 a.m.

Details

Message ID 9378e9d8b82241f494b682ad796dcd41acfe6b6b.1390123290.git.baruch@tkos.co.il
State New
Headers show

Commit Message

Baruch Siach Jan. 19, 2014, 9:21 a.m.
The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement
__builtin_frame_address. This symbol is local/hidden in libgcc. This is not a
problem when linking against static libgcc. But g++ defaults to
-shared-libgcc, thus breaking link against C++ shared libraries that are using
__builtin_frame_address as follows:

ld: test: hidden symbol `__xtensa_libgcc_window_spill' in .../libgcc.a(lib2funcs.o) is referenced by DSO

Make libgcc_s.so a linker script that links in unresolved symbols from the
static libgcc, similar to the ARM and PowerPC ports.

libgcc/
	* config.host (tmake_file): add t-slibgcc-libgcc for xtensa*-*-linux*.
---
 libgcc/config.host | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Sterling Augustine Jan. 20, 2014, 8:06 p.m.
On Sun, Jan 19, 2014 at 1:21 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement
> __builtin_frame_address. This symbol is local/hidden in libgcc. This is not a
> problem when linking against static libgcc. But g++ defaults to
> -shared-libgcc, thus breaking link against C++ shared libraries that are using
> __builtin_frame_address as follows:

This is OK for mainline. I assume your copyright assignment is on file?

Thanks!
Chris Zankel Jan. 20, 2014, 8:26 p.m.
Hi Sterling,

Given that you are the maintainer on file and I think you have signed 
the copyright assignment, you should be able to just take it. AFAIK a 
copyright assignment is only required for large(r) patches.

Thanks,
-Chris

On 1/20/14, 12:06 PM, Sterling Augustine wrote:
> On Sun, Jan 19, 2014 at 1:21 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement
>> __builtin_frame_address. This symbol is local/hidden in libgcc. This is not a
>> problem when linking against static libgcc. But g++ defaults to
>> -shared-libgcc, thus breaking link against C++ shared libraries that are using
>> __builtin_frame_address as follows:
> This is OK for mainline. I assume your copyright assignment is on file?
>
> Thanks!
Baruch Siach Jan. 21, 2014, 5:46 a.m.
Hi Sterling,

On Mon, Jan 20, 2014 at 12:06:59PM -0800, Sterling Augustine wrote:
> On Sun, Jan 19, 2014 at 1:21 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement
> > __builtin_frame_address. This symbol is local/hidden in libgcc. This is not a
> > problem when linking against static libgcc. But g++ defaults to
> > -shared-libgcc, thus breaking link against C++ shared libraries that are using
> > __builtin_frame_address as follows:
> 
> This is OK for mainline.

Thanks. This is needed for the 4.7 and 4.8 branches as well.

> I assume your copyright assignment is on file?

According to 
https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html, only 
"legally significant" contributions of more than 15 lines of code "or so" 
require copyright assignment.

baruch
Sterling Augustine Jan. 21, 2014, 5:53 a.m.
On Mon, Jan 20, 2014 at 9:46 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Sterling,
>> This is OK for mainline.
>
> Thanks. This is needed for the 4.7 and 4.8 branches as well.
>
>> I assume your copyright assignment is on file?
>
> According to
> https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html, only
> "legally significant" contributions of more than 15 lines of code "or so"
> require copyright assignment.

Yes, I understand the policy reasonably well.  While this particular
one is not legally significant, only you know if you intend to submit
more significant patches. And therefore if you should get started on
the legal side of the equation.
Baruch Siach Jan. 21, 2014, 6:01 a.m.
Hi Sterling,

On Mon, Jan 20, 2014 at 09:53:36PM -0800, Sterling Augustine wrote:
> On Mon, Jan 20, 2014 at 9:46 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > According to
> > https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html, only
> > "legally significant" contributions of more than 15 lines of code "or so"
> > require copyright assignment.
> 
> Yes, I understand the policy reasonably well.  While this particular
> one is not legally significant, only you know if you intend to submit
> more significant patches. And therefore if you should get started on
> the legal side of the equation.

Thanks for the head up. Though I'd really like to make more significant 
contributions to gcc (and the xtensa port could use some), chances for this 
actually materializing look slim at the moment. But anyway, I'll keep that in 
mind going forward.

Thanks,
baruch
Sterling Augustine Jan. 21, 2014, 7:45 p.m.
On Mon, Jan 20, 2014 at 9:46 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Sterling,
>
> On Mon, Jan 20, 2014 at 12:06:59PM -0800, Sterling Augustine wrote:
>> On Sun, Jan 19, 2014 at 1:21 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement
>> > __builtin_frame_address. This symbol is local/hidden in libgcc. This is not a
>> > problem when linking against static libgcc. But g++ defaults to
>> > -shared-libgcc, thus breaking link against C++ shared libraries that are using
>> > __builtin_frame_address as follows:
>>
>> This is OK for mainline.
>
> Thanks. This is needed for the 4.7 and 4.8 branches as well.

Checked in on all three branches.

Cheers.

Patch hide | download patch | download mbox

diff --git a/libgcc/config.host b/libgcc/config.host
index 75a17e3..178f6d9 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1181,7 +1181,7 @@  xtensa*-*-elf*)
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 xtensa*-*-linux*)
-	tmake_file="$tmake_file xtensa/t-xtensa xtensa/t-linux"
+	tmake_file="$tmake_file xtensa/t-xtensa xtensa/t-linux t-slibgcc-libgcc"
 	md_unwind_header=xtensa/linux-unwind.h
 	;;
 am33_2.0-*-linux*)