"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 <l...@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 <evstu...@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
