| Message ID | CAOvf_xxRWG-rskfXsgwqTV=DhzPiBrR+2J1QFfH-+eA1BiL_4A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Missed path in ChangeLog:
2014-12-28 Evgeny Stupachenko <evstupac@gmail.com>
* config/i386/gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
* config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
On Sun, Dec 28, 2014 at 7:46 PM, Evgeny Stupachenko <evstupac@gmail.com> wrote:
> Hi,
>
> The patch removes EBX usage from asm code used in libgcc/crtstuff.c
> It is safe now, but potentially buggy when glibc is rebuild with GCC
> 5.0 as EBX is not GOT register any more.
>
> x86 bootstrap, make check passed.
>
> Is it ok?
>
> Evgeny
>
> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com>
>
> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
>
> diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
> index e1163c9..965673b 100644
> --- a/gcc/config/i386/gnu-user.h
> +++ b/gcc/config/i386/gnu-user.h
> @@ -131,13 +131,6 @@ along with GCC; see the file COPYING3. If not see
>
> /* Used by crtstuff.c to initialize the base of data-relative relocations.
> These are GOT relative on x86, so return the pic register. */
> -#ifdef __PIC__
> -#define CRT_GET_RFIB_DATA(BASE) \
> - { \
> - register void *ebx_ __asm__("ebx"); \
> - BASE = ebx_; \
> - }
> -#else
> #define CRT_GET_RFIB_DATA(BASE)
> \
> __asm__ ("call\t.LPR%=\n" \
> ".LPR%=:\n\t" \
> @@ -148,7 +141,6 @@ along with GCC; see the file COPYING3. If not see
> "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0" \
> "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}" \
> : "=d"(BASE))
> -#endif
>
> #ifdef TARGET_LIBC_PROVIDES_SSP
> /* i386 glibc provides __stack_chk_guard in %gs:0x14. */
> diff --git a/gcc/config/i386/sysv4.h b/gcc/config/i386/sysv4.h
> index 011b228..5167485 100644
> --- a/gcc/config/i386/sysv4.h
> +++ b/gcc/config/i386/sysv4.h
> @@ -52,13 +52,6 @@ along with GCC; see the file COPYING3. If not see
>
> /* Used by crtstuff.c to initialize the base of data-relative relocations.
> These are GOT relative on x86, so return the pic register. */
> -#ifdef __PIC__
> -#define CRT_GET_RFIB_DATA(BASE) \
> - { \
> - register void *ebx_ __asm__("ebx"); \
> - BASE = ebx_; \
> - }
> -#else
> #define CRT_GET_RFIB_DATA(BASE)
> \
> __asm__ ("call\t.LPR%=\n" \
> ".LPR%=:\n\t" \
> @@ -69,4 +62,3 @@ along with GCC; see the file COPYING3. If not see
> "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0" \
> "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}" \
> : "=d"(BASE))
> -#endif
On Mon, Dec 29, 2014 at 4:29 PM, Evgeny Stupachenko <evstupac@gmail.com> wrote: > Missed path in ChangeLog: > > 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> > > * config/i386/gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. > * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. Looks OK, but I'd like to ask Jakub (CC'd) about glibc impact before the patch is approved. Uros. > > On Sun, Dec 28, 2014 at 7:46 PM, Evgeny Stupachenko <evstupac@gmail.com> wrote: >> Hi, >> >> The patch removes EBX usage from asm code used in libgcc/crtstuff.c >> It is safe now, but potentially buggy when glibc is rebuild with GCC >> 5.0 as EBX is not GOT register any more. >> >> x86 bootstrap, make check passed. >> >> Is it ok? >> >> Evgeny >> >> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> >> >> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. >> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. >> >> diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h >> index e1163c9..965673b 100644 >> --- a/gcc/config/i386/gnu-user.h >> +++ b/gcc/config/i386/gnu-user.h >> @@ -131,13 +131,6 @@ along with GCC; see the file COPYING3. If not see >> >> /* Used by crtstuff.c to initialize the base of data-relative relocations. >> These are GOT relative on x86, so return the pic register. */ >> -#ifdef __PIC__ >> -#define CRT_GET_RFIB_DATA(BASE) \ >> - { \ >> - register void *ebx_ __asm__("ebx"); \ >> - BASE = ebx_; \ >> - } >> -#else >> #define CRT_GET_RFIB_DATA(BASE) >> \ >> __asm__ ("call\t.LPR%=\n" \ >> ".LPR%=:\n\t" \ >> @@ -148,7 +141,6 @@ along with GCC; see the file COPYING3. If not see >> "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0" \ >> "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}" \ >> : "=d"(BASE)) >> -#endif >> >> #ifdef TARGET_LIBC_PROVIDES_SSP >> /* i386 glibc provides __stack_chk_guard in %gs:0x14. */ >> diff --git a/gcc/config/i386/sysv4.h b/gcc/config/i386/sysv4.h >> index 011b228..5167485 100644 >> --- a/gcc/config/i386/sysv4.h >> +++ b/gcc/config/i386/sysv4.h >> @@ -52,13 +52,6 @@ along with GCC; see the file COPYING3. If not see >> >> /* Used by crtstuff.c to initialize the base of data-relative relocations. >> These are GOT relative on x86, so return the pic register. */ >> -#ifdef __PIC__ >> -#define CRT_GET_RFIB_DATA(BASE) \ >> - { \ >> - register void *ebx_ __asm__("ebx"); \ >> - BASE = ebx_; \ >> - } >> -#else >> #define CRT_GET_RFIB_DATA(BASE) >> \ >> __asm__ ("call\t.LPR%=\n" \ >> ".LPR%=:\n\t" \ >> @@ -69,4 +62,3 @@ along with GCC; see the file COPYING3. If not see >> "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0" \ >> "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}" \ >> : "=d"(BASE)) >> -#endif
On 12/28/14 09:46, Evgeny Stupachenko wrote: > Hi, > > The patch removes EBX usage from asm code used in libgcc/crtstuff.c > It is safe now, but potentially buggy when glibc is rebuild with GCC > 5.0 as EBX is not GOT register any more. > > x86 bootstrap, make check passed. > > Is it ok? > > Evgeny > > 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> > > * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. > * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. I don't understand the glibc reference above. Ultimately what matters here, AFAICT is the value assigned to the parameter to CRT_GET_RFIB_DATA which should be the base of the data relative relocations. So the comment "It is safe now" seems wrong as well. ISTM this is a critical fix as it would be possible for the PIC pseudo to be assigned to something other than %ebx when compiling libgcc/crtstuff.c. And if that happens, we'll pass in a junk value to register_frame_info_bases. Evgeny, can you clarify why you think things are safe now, but would not be safe if glibc were to be built with the current GCC trunk? Jeff
"frame_dummy" does not use EBX in allocation now as there are enough
other registers (that we don't need to save/restore). So if we do not
modify "frame_dummy" EBX should stay unchanged.
"frame_dummy" does not initialize EBX register at the beginning it
expects that EBX is pic from glibc
"frame_dummy" is called from glibc and while we have glibc compiled by
4.9 or older compiler EBX should come to "frame_dummy" as pic register
Not sure that it is correct right now, but obviously will be
potentially buggy when glibc is recompiled with GCC 5.0.
libgcc (frame_dummy):
static void __attribute__((used))
frame_dummy (void)
{
#ifdef USE_EH_FRAME_REGISTRY
static struct object object;
#ifdef CRT_GET_RFIB_DATA
void *tbase, *dbase;
tbase = 0;
CRT_GET_RFIB_DATA (dbase);
if (__register_frame_info_bases)
__register_frame_info_bases (__EH_FRAME_BEGIN__, &object, tbase, dbase);
#else
if (__register_frame_info)
__register_frame_info (__EH_FRAME_BEGIN__, &object);
#endif /* CRT_GET_RFIB_DATA */
....
On Mon, Jan 5, 2015 at 11:50 PM, Jeff Law <law@redhat.com> wrote:
> On 12/28/14 09:46, Evgeny Stupachenko wrote:
>>
>> Hi,
>>
>> The patch removes EBX usage from asm code used in libgcc/crtstuff.c
>> It is safe now, but potentially buggy when glibc is rebuild with GCC
>> 5.0 as EBX is not GOT register any more.
>>
>> x86 bootstrap, make check passed.
>>
>> Is it ok?
>>
>> Evgeny
>>
>> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com>
>>
>> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
>> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
>
> I don't understand the glibc reference above.
>
> Ultimately what matters here, AFAICT is the value assigned to the parameter
> to CRT_GET_RFIB_DATA which should be the base of the data relative
> relocations. So the comment "It is safe now" seems wrong as well.
>
> ISTM this is a critical fix as it would be possible for the PIC pseudo to be
> assigned to something other than %ebx when compiling libgcc/crtstuff.c. And
> if that happens, we'll pass in a junk value to register_frame_info_bases.
>
> Evgeny, can you clarify why you think things are safe now, but would not be
> safe if glibc were to be built with the current GCC trunk?
>
> Jeff
On Mon, Jan 12, 2015 at 01:36:05PM +0300, Evgeny Stupachenko wrote: > "frame_dummy" does not use EBX in allocation now as there are enough > other registers (that we don't need to save/restore). So if we do not > modify "frame_dummy" EBX should stay unchanged. > "frame_dummy" does not initialize EBX register at the beginning it > expects that EBX is pic from glibc > "frame_dummy" is called from glibc and while we have glibc compiled by > 4.9 or older compiler EBX should come to "frame_dummy" as pic register I also don't understand how is this related to glibc in any way. From my understanding, the macro relied on %ebx being set to _GLOBAL_OFFSET_TABLE_ because the frame_dummy function does access GOT, so before the i?86 PIC reg changes it was computing %ebx. Jakub
Agree, I've missed the usage of the function "__register_frame_info_bases" (frame_dummy assembly had only indirect call when I miss "-pie" in compilation). There is no reference on glibc that way. Sorry for the confusion. So that is potentially buggy right now. On Mon, Jan 12, 2015 at 1:50 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Jan 12, 2015 at 01:36:05PM +0300, Evgeny Stupachenko wrote: >> "frame_dummy" does not use EBX in allocation now as there are enough >> other registers (that we don't need to save/restore). So if we do not >> modify "frame_dummy" EBX should stay unchanged. >> "frame_dummy" does not initialize EBX register at the beginning it >> expects that EBX is pic from glibc >> "frame_dummy" is called from glibc and while we have glibc compiled by >> 4.9 or older compiler EBX should come to "frame_dummy" as pic register > > I also don't understand how is this related to glibc in any way. > From my understanding, the macro relied on %ebx being set to > _GLOBAL_OFFSET_TABLE_ because the frame_dummy function does access > GOT, so before the i?86 PIC reg changes it was computing %ebx. > > Jakub
On 01/12/15 04:56, Evgeny Stupachenko wrote: > Agree, I've missed the usage of the function > "__register_frame_info_bases" (frame_dummy assembly had only indirect > call when I miss "-pie" in compilation). > There is no reference on glibc that way. Sorry for the confusion. > So that is potentially buggy right now. So it seems to me this ought to be installed now. Jeff
Hi Evgeny, > The patch removes EBX usage from asm code used in libgcc/crtstuff.c > It is safe now, but potentially buggy when glibc is rebuild with GCC > 5.0 as EBX is not GOT register any more. > > x86 bootstrap, make check passed. > > Is it ok? > > Evgeny > > 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> > > * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. > * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. this patch broke Solaris 10/x86 bootstrap: when building amd64 crtbegin.o, gas complains crtstuff.s: Assembler messages: crtstuff.s:179: Error: invalid instruction suffix for `pop' crtstuff.s:180: Error: incorrect register `%rdx' used with `l' suffix popl %rdx addl $_GLOBAL_OFFSET_TABLE_+[.-.LPR115],%rdx Rainer
On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: >> The patch removes EBX usage from asm code used in libgcc/crtstuff.c >> It is safe now, but potentially buggy when glibc is rebuild with GCC >> 5.0 as EBX is not GOT register any more. >> >> x86 bootstrap, make check passed. >> >> Is it ok? >> >> Evgeny >> >> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> >> >> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. >> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. > > this patch broke Solaris 10/x86 bootstrap: when building amd64 > crtbegin.o, gas complains Looks like config.gcc error for Solaris x86, amd64 target should not include i386/gnu-user.h but i386/gnu-user64.h Uros.
Uros Bizjak <ubizjak@gmail.com> writes: > On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth > <ro@cebitec.uni-bielefeld.de> wrote: > >>> The patch removes EBX usage from asm code used in libgcc/crtstuff.c >>> It is safe now, but potentially buggy when glibc is rebuild with GCC >>> 5.0 as EBX is not GOT register any more. >>> >>> x86 bootstrap, make check passed. >>> >>> Is it ok? >>> >>> Evgeny >>> >>> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> >>> >>> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. >>> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. >> >> this patch broke Solaris 10/x86 bootstrap: when building amd64 >> crtbegin.o, gas complains > > Looks like config.gcc error for Solaris x86, amd64 target should not > include i386/gnu-user.h but i386/gnu-user64.h The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only the amd64 crtbegin.o is affected, the i386 one is fine. Rainer
On Sat, Jan 17, 2015 at 7:36 PM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: > Uros Bizjak <ubizjak@gmail.com> writes: > >> On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth >> <ro@cebitec.uni-bielefeld.de> wrote: >> >>>> The patch removes EBX usage from asm code used in libgcc/crtstuff.c >>>> It is safe now, but potentially buggy when glibc is rebuild with GCC >>>> 5.0 as EBX is not GOT register any more. >>>> >>>> x86 bootstrap, make check passed. >>>> >>>> Is it ok? >>>> >>>> Evgeny >>>> >>>> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> >>>> >>>> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. >>>> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. >>> >>> this patch broke Solaris 10/x86 bootstrap: when building amd64 >>> crtbegin.o, gas complains >> >> Looks like config.gcc error for Solaris x86, amd64 target should not >> include i386/gnu-user.h but i386/gnu-user64.h > > The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only > the amd64 crtbegin.o is affected, the i386 one is fine. Please split sysv4-common.h out of i386/sysv4.h, similar to how i386/gnu-user.h and gnu-user-common.h are split. Uros.
Uros Bizjak <ubizjak@gmail.com> writes: > On Sat, Jan 17, 2015 at 7:36 PM, Rainer Orth > <ro@cebitec.uni-bielefeld.de> wrote: >> Uros Bizjak <ubizjak@gmail.com> writes: >> >>> On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth >>> <ro@cebitec.uni-bielefeld.de> wrote: >>> >>>>> The patch removes EBX usage from asm code used in libgcc/crtstuff.c >>>>> It is safe now, but potentially buggy when glibc is rebuild with GCC >>>>> 5.0 as EBX is not GOT register any more. >>>>> >>>>> x86 bootstrap, make check passed. >>>>> >>>>> Is it ok? >>>>> >>>>> Evgeny >>>>> >>>>> 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> >>>>> >>>>> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. >>>>> * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. >>>> >>>> this patch broke Solaris 10/x86 bootstrap: when building amd64 >>>> crtbegin.o, gas complains >>> >>> Looks like config.gcc error for Solaris x86, amd64 target should not >>> include i386/gnu-user.h but i386/gnu-user64.h >> >> The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only >> the amd64 crtbegin.o is affected, the i386 one is fine. > > Please split sysv4-common.h out of i386/sysv4.h, similar to how > i386/gnu-user.h and gnu-user-common.h are split. This would break Solaris/SPARC (there's no sparc/sysv4-common.h), and only works on Linux/x86 by accident: * CRT_GET_RFIB_DATA is only defined in i386/gnu-user.h there, but that file is only included for 32-bit-only configurations, not 32-bit-default ones (--enable-targets=all). In the latter case, the macro is not defined for the 32-bit multilib, where it should be. * CRT_GET_RFIB_DATA is only used in libgcc/crtstuff.c and libgcc/unwind-dw2-fde-dip.c (which already has a workaround for it being incorrectly defined for 64-bit Solaris/x86). IMO, the definition has no business living in gcc/config/i386 at all, but should move to libgcc/config instead (together with the one in frv/frv.h). That being probably too intrusive at this stage, I think the best workaround for now is to simply wrap the definition in i386/syv4.h (which is Solaris/x86-only anyway) in __i386__. Rainer
On Tue, Jan 20, 2015 at 10:42 AM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: >>> The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only >>> the amd64 crtbegin.o is affected, the i386 one is fine. >> >> Please split sysv4-common.h out of i386/sysv4.h, similar to how >> i386/gnu-user.h and gnu-user-common.h are split. > > This would break Solaris/SPARC (there's no sparc/sysv4-common.h), and > only works on Linux/x86 by accident: > > * CRT_GET_RFIB_DATA is only defined in i386/gnu-user.h there, but that > file is only included for 32-bit-only configurations, not > 32-bit-default ones (--enable-targets=all). In the latter case, the > macro is not defined for the 32-bit multilib, where it should be. > > * CRT_GET_RFIB_DATA is only used in libgcc/crtstuff.c and > libgcc/unwind-dw2-fde-dip.c (which already has a workaround for it > being incorrectly defined for 64-bit Solaris/x86). > > IMO, the definition has no business living in gcc/config/i386 at all, > but should move to libgcc/config instead (together with the one in > frv/frv.h). That being probably too intrusive at this stage, I think > the best workaround for now is to simply wrap the definition in > i386/syv4.h (which is Solaris/x86-only anyway) in __i386__. Ugh... Considering your explanation and the mess in the unwinder, IMO this should be fixed in the correct way even at this stage. CC RMs for their opinion. Thanks, Uros.
On Tue, Jan 20, 2015 at 10:51:03AM +0100, Uros Bizjak wrote: > On Tue, Jan 20, 2015 at 10:42 AM, Rainer Orth > <ro@cebitec.uni-bielefeld.de> wrote: > > >>> The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only > >>> the amd64 crtbegin.o is affected, the i386 one is fine. > >> > >> Please split sysv4-common.h out of i386/sysv4.h, similar to how > >> i386/gnu-user.h and gnu-user-common.h are split. > > > > This would break Solaris/SPARC (there's no sparc/sysv4-common.h), and > > only works on Linux/x86 by accident: > > > > * CRT_GET_RFIB_DATA is only defined in i386/gnu-user.h there, but that > > file is only included for 32-bit-only configurations, not > > 32-bit-default ones (--enable-targets=all). In the latter case, the > > macro is not defined for the 32-bit multilib, where it should be. > > > > * CRT_GET_RFIB_DATA is only used in libgcc/crtstuff.c and > > libgcc/unwind-dw2-fde-dip.c (which already has a workaround for it > > being incorrectly defined for 64-bit Solaris/x86). > > > > IMO, the definition has no business living in gcc/config/i386 at all, > > but should move to libgcc/config instead (together with the one in > > frv/frv.h). That being probably too intrusive at this stage, I think > > the best workaround for now is to simply wrap the definition in > > i386/syv4.h (which is Solaris/x86-only anyway) in __i386__. > > Ugh... > > Considering your explanation and the mess in the unwinder, IMO this > should be fixed in the correct way even at this stage. > > CC RMs for their opinion. Agreed. Jakub
diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h index e1163c9..965673b 100644 --- a/gcc/config/i386/gnu-user.h +++ b/gcc/config/i386/gnu-user.h @@ -131,13 +131,6 @@ along with GCC; see the file COPYING3. If not see /* Used by crtstuff.c to initialize the base of data-relative relocations. These are GOT relative on x86, so return the pic register. */ -#ifdef __PIC__ -#define CRT_GET_RFIB_DATA(BASE) \ - { \ - register void *ebx_ __asm__("ebx"); \ - BASE = ebx_; \ - } -#else #define CRT_GET_RFIB_DATA(BASE) \ __asm__ ("call\t.LPR%=\n" \ ".LPR%=:\n\t" \ @@ -148,7 +141,6 @@ along with GCC; see the file COPYING3. If not see "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0" \ "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}" \ : "=d"(BASE)) -#endif #ifdef TARGET_LIBC_PROVIDES_SSP /* i386 glibc provides __stack_chk_guard in %gs:0x14. */ diff --git a/gcc/config/i386/sysv4.h b/gcc/config/i386/sysv4.h index 011b228..5167485 100644 --- a/gcc/config/i386/sysv4.h +++ b/gcc/config/i386/sysv4.h @@ -52,13 +52,6 @@ along with GCC; see the file COPYING3. If not see /* Used by crtstuff.c to initialize the base of data-relative relocations. These are GOT relative on x86, so return the pic register. */ -#ifdef __PIC__ -#define CRT_GET_RFIB_DATA(BASE) \ - { \ - register void *ebx_ __asm__("ebx"); \ - BASE = ebx_; \ - } -#else #define CRT_GET_RFIB_DATA(BASE) \ __asm__ ("call\t.LPR%=\n" \
Hi, The patch removes EBX usage from asm code used in libgcc/crtstuff.c It is safe now, but potentially buggy when glibc is rebuild with GCC 5.0 as EBX is not GOT register any more. x86 bootstrap, make check passed. Is it ok? Evgeny 2014-12-28 Evgeny Stupachenko <evstupac@gmail.com> * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. ".LPR%=:\n\t" \ @@ -69,4 +62,3 @@ along with GCC; see the file COPYING3. If not see "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0" \ "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}" \ : "=d"(BASE)) -#endif