Ramana Radhakrishnan writes:
> On 17 August 2011 15:07, Joseph S. Myers 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_L
On 17 August 2011 15:07, Joseph S. Myers 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
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
jos...@codes
On 17/08/11 11:48, Ramana Radhakrishnan wrote:
> On 17 August 2011 08:59, Richard Sandiford
> 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 al
On 17 August 2011 08:59, Richard Sandiford 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
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