Patchwork libgcc: use linker script for libgcc_s.so on xtensa

login
register
mail settings
Submitter Baruch Siach
Date Jan. 19, 2014, 9:21 a.m.
Message ID <9378e9d8b82241f494b682ad796dcd41acfe6b6b.1390123290.git.baruch@tkos.co.il>
Download mbox | patch
Permalink /patch/312367/
State New
Headers show

Comments

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(-)
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

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*)