Uros Bizjak writes:
>> Yes, the name is better. It would also fit with Solaris.
>
> Bootstrap and regression test was OK.
>
> Committed with following ChangeLogs:
>
> libgcc/ChangeLog:
>
> 2015-01-23 Uros Bizjak
>
> * config/i386/elf-lib.h: New file.
> (CRT_GET_RFIB_DATA): Move definit
On Fri, Jan 23, 2015 at 1:08 PM, Uros Bizjak wrote:
>>> I'm testing the attached patch that moves the definition to libgcc
>>> *and* wraps it in __i386__ to fix multilibs. Rainer, can you please
>>> implement the fix for the Solaris/x86, presumably in the same way?
>>>
>>> libgcc/ChangeLog:
>>>
>
On Fri, Jan 23, 2015 at 1:04 PM, Jakub Jelinek wrote:
> On Fri, Jan 23, 2015 at 12:56:02PM +0100, Uros Bizjak wrote:
>> I'm testing the attached patch that moves the definition to libgcc
>> *and* wraps it in __i386__ to fix multilibs. Rainer, can you please
>> implement the fix for the Solaris/x86
On Fri, Jan 23, 2015 at 12:56:02PM +0100, Uros Bizjak wrote:
> I'm testing the attached patch that moves the definition to libgcc
> *and* wraps it in __i386__ to fix multilibs. Rainer, can you please
> implement the fix for the Solaris/x86, presumably in the same way?
>
> libgcc/ChangeLog:
>
> 20
On Tue, Jan 20, 2015 at 10:58 AM, Jakub Jelinek 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
On Tue, Jan 20, 2015 at 10:51:03AM +0100, Uros Bizjak wrote:
> On Tue, Jan 20, 2015 at 10:42 AM, Rainer Orth
> 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 o
On Tue, Jan 20, 2015 at 10:42 AM, Rainer Orth
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
Uros Bizjak writes:
> On Sat, Jan 17, 2015 at 7:36 PM, Rainer Orth
> wrote:
>> Uros Bizjak writes:
>>
>>> On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
>>> wrote:
>>>
> The patch removes EBX usage from asm code used in libgcc/crtstuff.c
> It is safe now, but potentially buggy when glibc
On Sat, Jan 17, 2015 at 7:36 PM, Rainer Orth
wrote:
> Uros Bizjak writes:
>
>> On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
>> 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
Uros Bizjak writes:
> On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
> 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
On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth
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?
>>
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
>
>
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 r
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, Ja
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 EB
"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_dum
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 Ev
On Mon, Dec 29, 2014 at 4:29 PM, Evgeny Stupachenko wrote:
> Missed path in ChangeLog:
>
> 2014-12-28 Evgeny Stupachenko
>
> * 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
Missed path in ChangeLog:
2014-12-28 Evgeny Stupachenko
* 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 wrote:
> Hi,
>
> The patch removes EBX usage
19 matches
Mail list logo
