* [ARM] PR 50090: aliases in libgcc.a with default visibility
@ 2011-08-17 9:54 Richard Sandiford
2011-08-17 13:10 ` Ramana Radhakrishnan
2011-08-17 15:40 ` Joseph S. Myers
0 siblings, 2 replies; 6+ messages in thread
From: Richard Sandiford @ 2011-08-17 9:54 UTC (permalink / raw)
To: gcc-patches
EABI functions like __aeabi_f2ulz are defined as aliases of standard
libgcc functions like __fixunssfdi. In libgcc.a, the standard function
gets the correct hidden visibility, but the alias retains default
visibility. This means that DSOs linked against libgcc.a may end
up exporting the libgcc.a definition of __aeabi_f2ulz.
The bug is that bpabi-lib.h uses an asm statement to define an alias,
so the standard ways of forcing hidden visibility at the C level have
no effect. Fixed by using attributes instead.
Tested on arm-linux-gnueabi. Also tested by making sure that libgcc.a
defined no default-visibility symbols. OK for trunk?
What about release branches? I suppose this isn't a regression,
but it is a backwards-compatible ABI fix.
Richard
libgcc/
PR target/50090
* config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
instead of an assembly one.
Index: libgcc/config/arm/bpabi-lib.h
===================================================================
--- libgcc/config/arm/bpabi-lib.h 2011-08-15 16:46:13.000000000 +0100
+++ libgcc/config/arm/bpabi-lib.h 2011-08-15 16:50:39.052030640 +0100
@@ -28,9 +28,8 @@ #define RENAME_LIBRARY_SET ".set"
/* Make __aeabi_AEABI_NAME an alias for __GCC_NAME. */
#define RENAME_LIBRARY(GCC_NAME, AEABI_NAME) \
- __asm__ (".globl\t__aeabi_" #AEABI_NAME "\n" \
- RENAME_LIBRARY_SET "\t__aeabi_" #AEABI_NAME \
- ", __" #GCC_NAME "\n");
+ typeof (__##GCC_NAME) __aeabi_##AEABI_NAME \
+ __attribute__((alias ("__" #GCC_NAME)));
/* Give some libgcc functions an additional __aeabi name. */
#ifdef L_muldi3
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
2011-08-17 9:54 [ARM] PR 50090: aliases in libgcc.a with default visibility Richard Sandiford
@ 2011-08-17 13:10 ` Ramana Radhakrishnan
2011-08-17 15:39 ` Richard Earnshaw
2011-08-17 15:40 ` Joseph S. Myers
1 sibling, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2011-08-17 13:10 UTC (permalink / raw)
To: gcc-patches, richard.sandiford
On 17 August 2011 08:59, Richard Sandiford <richard.sandiford@linaro.org> wrote:
> EABI functions like __aeabi_f2ulz are defined as aliases of standard
> libgcc functions like __fixunssfdi. In libgcc.a, the standard function
> gets the correct hidden visibility, but the alias retains default
> visibility. This means that DSOs linked against libgcc.a may end
> up exporting the libgcc.a definition of __aeabi_f2ulz.
>
> The bug is that bpabi-lib.h uses an asm statement to define an alias,
> so the standard ways of forcing hidden visibility at the C level have
> no effect. Fixed by using attributes instead.
>
> Tested on arm-linux-gnueabi. Also tested by making sure that libgcc.a
> defined no default-visibility symbols. OK for trunk?
This is OK.
>
> What about release branches? I suppose this isn't a regression,
> but it is a backwards-compatible ABI fix.
I can't see why not. That's reason enough for me to consider the
backport but I'd like other maintainers to chime in.
cheers
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
2011-08-17 13:10 ` Ramana Radhakrishnan
@ 2011-08-17 15:39 ` Richard Earnshaw
0 siblings, 0 replies; 6+ messages in thread
From: Richard Earnshaw @ 2011-08-17 15:39 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: gcc-patches, richard.sandiford
On 17/08/11 11:48, Ramana Radhakrishnan wrote:
> On 17 August 2011 08:59, Richard Sandiford <richard.sandiford@linaro.org> wrote:
>> EABI functions like __aeabi_f2ulz are defined as aliases of standard
>> libgcc functions like __fixunssfdi. In libgcc.a, the standard function
>> gets the correct hidden visibility, but the alias retains default
>> visibility. This means that DSOs linked against libgcc.a may end
>> up exporting the libgcc.a definition of __aeabi_f2ulz.
>>
>> The bug is that bpabi-lib.h uses an asm statement to define an alias,
>> so the standard ways of forcing hidden visibility at the C level have
>> no effect. Fixed by using attributes instead.
>>
>> Tested on arm-linux-gnueabi. Also tested by making sure that libgcc.a
>> defined no default-visibility symbols. OK for trunk?
>
> This is OK.
>
>>
>> What about release branches? I suppose this isn't a regression,
>> but it is a backwards-compatible ABI fix.
>
> I can't see why not. That's reason enough for me to consider the
> backport but I'd like other maintainers to chime in.
>
Ok, provided there are no objections from the branch maintainers.
R.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
2011-08-17 9:54 [ARM] PR 50090: aliases in libgcc.a with default visibility Richard Sandiford
2011-08-17 13:10 ` Ramana Radhakrishnan
@ 2011-08-17 15:40 ` Joseph S. Myers
2011-08-18 9:26 ` Ramana Radhakrishnan
1 sibling, 1 reply; 6+ messages in thread
From: Joseph S. Myers @ 2011-08-17 15:40 UTC (permalink / raw)
To: Richard Sandiford; +Cc: gcc-patches
On Wed, 17 Aug 2011, Richard Sandiford wrote:
> libgcc/
> PR target/50090
> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
> instead of an assembly one.
Is RENAME_LIBRARY_SET used at all after this patch or should it be
removed?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
2011-08-17 15:40 ` Joseph S. Myers
@ 2011-08-18 9:26 ` Ramana Radhakrishnan
2011-08-18 14:13 ` Richard Sandiford
0 siblings, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2011-08-18 9:26 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Richard Sandiford, gcc-patches
On 17 August 2011 15:07, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 17 Aug 2011, Richard Sandiford wrote:
>
>> libgcc/
>> PR target/50090
>> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
>> instead of an assembly one.
>
> Is RENAME_LIBRARY_SET used at all after this patch or should it be
> removed?
A patch to remove that is pre-approved provided ofcourse this patch
has been applied :)
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ARM] PR 50090: aliases in libgcc.a with default visibility
2011-08-18 9:26 ` Ramana Radhakrishnan
@ 2011-08-18 14:13 ` Richard Sandiford
0 siblings, 0 replies; 6+ messages in thread
From: Richard Sandiford @ 2011-08-18 14:13 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: Joseph S. Myers, gcc-patches
Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org> writes:
> On 17 August 2011 15:07, Joseph S. Myers <joseph@codesourcery.com> wrote:
>> On Wed, 17 Aug 2011, Richard Sandiford wrote:
>>
>>> libgcc/
>>> PR target/50090
>>> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
>>> instead of an assembly one.
>>
>> Is RENAME_LIBRARY_SET used at all after this patch or should it be
>> removed?
>
> A patch to remove that is pre-approved provided ofcourse this patch
> has been applied :)
Thanks. Here's what I applied after testing on arm-linux-gnueabi.
Based on your and Richard's OKs, I'll backport both patches to the
release branches next week unless a release maintainer objects.
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-08-18 13:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-17 9:54 [ARM] PR 50090: aliases in libgcc.a with default visibility Richard Sandiford
2011-08-17 13:10 ` Ramana Radhakrishnan
2011-08-17 15:39 ` Richard Earnshaw
2011-08-17 15:40 ` Joseph S. Myers
2011-08-18 9:26 ` Ramana Radhakrishnan
2011-08-18 14:13 ` Richard Sandiford
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).