Patchwork Prefixes for libgcc symbols (C6X 9.5/11)

login
register
mail settings
Submitter Bernd Schmidt
Date May 25, 2011, 1:52 p.m.
Message ID <4DDD09AD.6080602@codesourcery.com>
Download mbox | patch
Permalink /patch/97345/
State New
Headers show

Comments

Bernd Schmidt - May 25, 2011, 1:52 p.m.
On 05/25/2011 01:45 PM, H.J. Lu wrote:
> On Wed, May 25, 2011 at 6:42 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 05/25/2011 01:37 PM, H.J. Lu wrote:
>>
>>> I think it may have caused:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49160
>>
>> Looks like it. Not quite sure how to fix it yet. Do you know what files
>> such as i386/64/_divtc3.c are trying to achieve?
>>
> 
> It provides backward compatibility with symbol versioning:
> 
> [hjl@gnu-4 64]$ readelf -s /lib64/libgcc_s.so.1| grep __powitf2
>     52: 0000003e8a80d170   167 FUNC    GLOBAL DEFAULT   12 __powitf2@@GCC_4.3.0
>     54: 0000003e8a80d170   167 FUNC    GLOBAL DEFAULT   12 __powitf2@GCC_4.0.0
> [hjl@gnu-4 64]$

That leaves me as clueless as before. Why does i386/64 need this but not
other targets (such as i386/32), and why only those three functions
(from the ones in libgcc)?

Anyhow, below is one possible way of fixing it.


Bernd
PR bootstrap/49160
	* libgcc2.h (__powisf2, __powidf2, __powitf2, __powixf2,
	__mulsc3, __muldc3, __mulxc3, __multc3, __divsc3, __divdc3,
	__divxc3, __divtc3): Wrap definitions in #ifndef.
Jakub Jelinek - May 25, 2011, 2:45 p.m.
On Wed, May 25, 2011 at 01:52:45PM +0000, Bernd Schmidt wrote:
> On 05/25/2011 01:45 PM, H.J. Lu wrote:
> > On Wed, May 25, 2011 at 6:42 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> >> On 05/25/2011 01:37 PM, H.J. Lu wrote:
> >>
> >>> I think it may have caused:
> >>>
> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49160
> >>
> >> Looks like it. Not quite sure how to fix it yet. Do you know what files
> >> such as i386/64/_divtc3.c are trying to achieve?
> >>
> > 
> > It provides backward compatibility with symbol versioning:
> > 
> > [hjl@gnu-4 64]$ readelf -s /lib64/libgcc_s.so.1| grep __powitf2
> >     52: 0000003e8a80d170   167 FUNC    GLOBAL DEFAULT   12 __powitf2@@GCC_4.3.0
> >     54: 0000003e8a80d170   167 FUNC    GLOBAL DEFAULT   12 __powitf2@GCC_4.0.0
> > [hjl@gnu-4 64]$
> 
> That leaves me as clueless as before. Why does i386/64 need this but not
> other targets (such as i386/32), and why only those three functions
> (from the ones in libgcc)?

The comment in config/i386/libgcc-glibc.ver explains it:

# Those symbols had improper versions when they were added to gcc 4.3.0.
# We corrected the default version to GCC_4.3.0.  But we keep the old
# version for backward binary compatibility.

It is not just 3 symbols, but 6 -
__netf2/__gttf2/__lttf2/__divtc3/__multc3/__powitf2.

	Jakub
H.J. Lu - May 25, 2011, 4:38 p.m.
On Wed, May 25, 2011 at 6:52 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 05/25/2011 01:45 PM, H.J. Lu wrote:
>> On Wed, May 25, 2011 at 6:42 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>> On 05/25/2011 01:37 PM, H.J. Lu wrote:
>>>
>>>> I think it may have caused:
>>>>
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49160
>>>
>>> Looks like it. Not quite sure how to fix it yet. Do you know what files
>>> such as i386/64/_divtc3.c are trying to achieve?
>>>
>>
>> It provides backward compatibility with symbol versioning:
>>
>> [hjl@gnu-4 64]$ readelf -s /lib64/libgcc_s.so.1| grep __powitf2
>>     52: 0000003e8a80d170   167 FUNC    GLOBAL DEFAULT   12 __powitf2@@GCC_4.3.0
>>     54: 0000003e8a80d170   167 FUNC    GLOBAL DEFAULT   12 __powitf2@GCC_4.0.0
>> [hjl@gnu-4 64]$
>
> That leaves me as clueless as before. Why does i386/64 need this but not
> other targets (such as i386/32), and why only those three functions
> (from the ones in libgcc)?
>
> Anyhow, below is one possible way of fixing it.

It fixed the libgcc failure.  Can you check it in?

Thanks.
Bernd Schmidt - May 25, 2011, 4:42 p.m.
On 05/25/2011 04:38 PM, H.J. Lu wrote:
> On Wed, May 25, 2011 at 6:52 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> Anyhow, below is one possible way of fixing it.
> 
> It fixed the libgcc failure.  Can you check it in?

I suppose it is reasonably obvious. Done.


Bernd

Patch

Index: gcc/libgcc2.h
===================================================================
--- gcc/libgcc2.h	(revision 174187)
+++ gcc/libgcc2.h	(working copy)
@@ -324,23 +324,48 @@  typedef int shift_count_type __attribute
 #define __parityDI2	__NDW(parity,2)
 
 #define __clz_tab		__N(clz_tab)
+#define __bswapsi2		__N(bswapsi2)
+#define __bswapdi2		__N(bswapdi2)
+#define __udiv_w_sdiv		__N(udiv_w_sdiv)
+#define __clear_cache		__N(clear_cache)
+#define __enable_execute_stack	__N(enable_execute_stack)
+
+#ifndef __powisf2
 #define __powisf2		__N(powisf2)
+#endif
+#ifndef __powidf2
 #define __powidf2		__N(powidf2)
+#endif
+#ifndef __powitf2
 #define __powitf2		__N(powitf2)
+#endif
+#ifndef __powixf2
 #define __powixf2		__N(powixf2)
-#define __bswapsi2		__N(bswapsi2)
-#define __bswapdi2		__N(bswapdi2)
+#endif
+#ifndef __mulsc3
 #define __mulsc3		__N(mulsc3)
+#endif
+#ifndef __muldc3
 #define __muldc3		__N(muldc3)
+#endif
+#ifndef __mulxc3
 #define __mulxc3		__N(mulxc3)
+#endif
+#ifndef __multc3
 #define __multc3		__N(multc3)
+#endif
+#ifndef __divsc3
 #define __divsc3		__N(divsc3)
+#endif
+#ifndef __divdc3
 #define __divdc3		__N(divdc3)
+#endif
+#ifndef __divxc3
 #define __divxc3		__N(divxc3)
+#endif
+#ifndef __divtc3
 #define __divtc3		__N(divtc3)
-#define __udiv_w_sdiv		__N(udiv_w_sdiv)
-#define __clear_cache		__N(clear_cache)
-#define __enable_execute_stack	__N(enable_execute_stack)
+#endif
 
 extern DWtype __muldi3 (DWtype, DWtype);
 extern DWtype __divdi3 (DWtype, DWtype);