On Tue, Apr 26, 2011 at 6:07 AM, H.J. Lu wrote:
> On Sat, Apr 9, 2011 at 6:52 PM, H.J. Lu wrote:
>> On Thu, Mar 24, 2011 at 12:15 AM, H.J. Lu wrote:
>>> On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand
>>> wrote:
Richard Henderson wrote:
> Because, really, if we consider the structure
On Sat, Apr 9, 2011 at 6:52 PM, H.J. Lu wrote:
> On Thu, Mar 24, 2011 at 12:15 AM, H.J. Lu wrote:
>> On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand wrote:
>>> Richard Henderson wrote:
Because, really, if we consider the structure truly public, we can't even
change the number of regis
On Thu, Mar 24, 2011 at 12:15 AM, H.J. Lu wrote:
> On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand wrote:
>> Richard Henderson wrote:
>>> Because, really, if we consider the structure truly public, we can't even
>>> change the number of registers for a given port to support new features of
>>> t
On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand wrote:
> Richard Henderson wrote:
>> Because, really, if we consider the structure truly public, we can't even
>> change the number of registers for a given port to support new features of
>> the cpu.
>
> Indeed, and I remember we got bitten by that
Richard Henderson wrote:
> Because, really, if we consider the structure truly public, we can't even
> change the number of registers for a given port to support new features of
> the cpu.
Indeed, and I remember we got bitten by that a long time ago, which is why
s390.h now has this comment:
/* N
On Wed, Mar 23, 2011 at 12:01:37PM -0700, Richard Henderson wrote:
> Guh. The entire point of making _Unwind_Context opaque, and inventing
> libgcc_s,
> was so that we didn't have to think about these things. There's one and only
> one
> copy of the unwind library and all uses of the structure
On 03/23/2011 11:37 AM, Jakub Jelinek wrote:
> E.g. for ppc64 that's 1160 bytes, mmix 2104 bytes, ...
> But if you think the 6 or so conditionals would be too much burden, just
> ignore me.
I suppose we could interpret (a part of?) "version" as a bitmap of features,
rather than a serial number...
On Wed, Mar 23, 2011 at 11:20:24AM -0700, Richard Henderson wrote:
> On 03/23/2011 11:04 AM, Jakub Jelinek wrote:
> > For several targets that would grow the context significantly, do you think
> > we really have to do that for all targets rather than just for the
> > sizeof (_Unwind_Word) > sizeof
On 03/23/2011 11:24 AM, H.J. Lu wrote:
> FWIW, I ran into this on x32, which is totally new and doesn't have
> backward compatibility issue.
I don't care. I'm not going to totally destroy maintainability for
the sake of one target. There shall be a common solution.
r~
On Wed, Mar 23, 2011 at 11:20 AM, Richard Henderson wrote:
> On 03/23/2011 11:04 AM, Jakub Jelinek wrote:
>> For several targets that would grow the context significantly, do you think
>> we really have to do that for all targets rather than just for the
>> sizeof (_Unwind_Word) > sizeof (void *)
On 03/23/2011 11:04 AM, Jakub Jelinek wrote:
> For several targets that would grow the context significantly, do you think
> we really have to do that for all targets rather than just for the
> sizeof (_Unwind_Word) > sizeof (void *) ones? The accessors are wrapped
> in inline functions anyway.
G
On Wed, Mar 23, 2011 at 10:50:35AM -0700, Richard Henderson wrote:
> >>
> >> Sure, that's easy. I think what you are really asking is: will there be
> >> a case where we could call functions from one copy and then pass the
> >> context to the functions from a different copy. I don't know the answ
On 03/22/2011 10:01 PM, H.J. Lu wrote:
>>> Will there be a case where 2 copies of unwind-dw2.c are within the same
>>> process?
>>
>> Sure, that's easy. I think what you are really asking is: will there be
>> a case where we could call functions from one copy and then pass the
>> context to the fu
"H.J. Lu" writes:
> On Tue, Mar 22, 2011 at 9:52 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
This suggests that, at least, when sizeof(_Unwind_Word) > sizeof(void*),
we need to extend _Unwind_Context with a new array at the end, and use
that new array when by_value[REG] i
On Tue, Mar 22, 2011 at 9:52 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> This suggests that, at least, when sizeof(_Unwind_Word) > sizeof(void*),
>>> we need to extend _Unwind_Context with a new array at the end, and use
>>> that new array when by_value[REG] is true.
>>
>> Will there be
"H.J. Lu" writes:
>> This suggests that, at least, when sizeof(_Unwind_Word) > sizeof(void*),
>> we need to extend _Unwind_Context with a new array at the end, and use
>> that new array when by_value[REG] is true.
>
> Will there be a case where 2 copies of unwind-dw2.c are within the same
> proce
On Tue, Mar 22, 2011 at 3:17 PM, Ian Lance Taylor wrote:
> "Ulrich Weigand" writes:
>
>> Ian Lance Taylor wrote:
>>> Andrew Pinski writes:
>>> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>>> >>
>>> >> Any target on which _Unwind_Word is larger than void * is broken today,
>>> >>
"Ulrich Weigand" writes:
> Ian Lance Taylor wrote:
>> Andrew Pinski writes:
>> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>> >>
>> >> Any target on which _Unwind_Word is larger than void * is broken today,
>> >> so I don't think we need to care about that case.
>> >
>> > So a MI
Ian Lance Taylor wrote:
> Andrew Pinski writes:
> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
> >>
> >> Any target on which _Unwind_Word is larger than void * is broken today,
> >> so I don't think we need to care about that case.
> >
> > So a MIPS N32 is broken? Lots of people us
Andrew Pinski writes:
> On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>>
>> Any target on which _Unwind_Word is larger than void * is broken today,
>> so I don't think we need to care about that case.
>
> So a MIPS N32 is broken? Lots of people use that target already and
> nothing l
On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor wrote:
>
> Any target on which _Unwind_Word is larger than void * is broken today,
> so I don't think we need to care about that case.
So a MIPS N32 is broken? Lots of people use that target already and
nothing like this has showed up yet.
Thank
Jakub Jelinek writes:
> On Tue, Mar 22, 2011 at 04:19:46PM +0100, Ulrich Weigand wrote:
>> Ian Lance Taylor wrote:
>> > "H.J. Lu" writes:
>> >
>> > > Here is the updated patch. It has
>> >
>> > This patch is OK if it bootstraps and passes tests.
>>
>> I thought the _Unwind_Context structure w
On Tue, Mar 22, 2011 at 04:19:46PM +0100, Ulrich Weigand wrote:
> Ian Lance Taylor wrote:
> > "H.J. Lu" writes:
> >
> > > Here is the updated patch. It has
> >
> > This patch is OK if it bootstraps and passes tests.
>
> I thought the _Unwind_Context structure was part of the libgcc ABI
> and sh
Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
> > Here is the updated patch. It has
>
> This patch is OK if it bootstraps and passes tests.
I thought the _Unwind_Context structure was part of the libgcc ABI
and should only be changed by appending to the end and/or updating
the version field?
B
"H.J. Lu" writes:
> Here is the updated patch. It has
This patch is OK if it bootstraps and passes tests.
Thanks.
Ian
On Mon, Mar 21, 2011 at 2:55 PM, Ian Lance Taylor wrote:
> On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
>
>> We shouldn't save call frame hard registers as "void *". This patch
>> changes the unwind library to save call frame hard registers as
>> _Unwind_Word. OK for 4.7?
>
>> + PR othe
On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
> We shouldn't save call frame hard registers as "void *". This patch
> changes the unwind library to save call frame hard registers as
> _Unwind_Word. OK for 4.7?
> + PR other/48007
> + * unwind-dw2.c (_Unwind_Context): Save call fram
On Mon, Mar 14, 2011 at 10:49 AM, H.J. Lu wrote:
>>>
>>> We shouldn't save call frame hard registers as "void *". This patch
>>> changes the unwind library to save call frame hard registers as
>>> _Unwind_Word. OK for 4.7?
>>
>> I think this will break the ABI for the MIP
On Sun, Mar 6, 2011 at 4:15 PM, H.J. Lu wrote:
> On Sun, Mar 6, 2011 at 3:40 PM, H.J. Lu wrote:
>> On Sun, Mar 6, 2011 at 3:23 PM, Richard Guenther
>> wrote:
>>> On Sun, Mar 6, 2011 at 10:28 PM, H.J. Lu wrote:
On Sun, Mar 6, 2011 at 1:15 PM, Andrew Pinski wrote:
> On Sun, Mar 6, 2011
On Sun, Mar 6, 2011 at 3:40 PM, H.J. Lu wrote:
> On Sun, Mar 6, 2011 at 3:23 PM, Richard Guenther
> wrote:
>> On Sun, Mar 6, 2011 at 10:28 PM, H.J. Lu wrote:
>>> On Sun, Mar 6, 2011 at 1:15 PM, Andrew Pinski wrote:
On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
> Hi,
>
> We sh
On Sun, Mar 6, 2011 at 3:23 PM, Richard Guenther
wrote:
> On Sun, Mar 6, 2011 at 10:28 PM, H.J. Lu wrote:
>> On Sun, Mar 6, 2011 at 1:15 PM, Andrew Pinski wrote:
>>> On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
Hi,
We shouldn't save call frame hard registers as "void *". This
On Sun, Mar 6, 2011 at 10:28 PM, H.J. Lu wrote:
> On Sun, Mar 6, 2011 at 1:15 PM, Andrew Pinski wrote:
>> On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> We shouldn't save call frame hard registers as "void *". This patch
>>> changes the unwind library to save call frame hard reg
On Sun, Mar 6, 2011 at 1:15 PM, Andrew Pinski wrote:
> On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
>> Hi,
>>
>> We shouldn't save call frame hard registers as "void *". This patch
>> changes the unwind library to save call frame hard registers as
>> _Unwind_Word. OK for 4.7?
>
> I think this
On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu wrote:
> Hi,
>
> We shouldn't save call frame hard registers as "void *". This patch
> changes the unwind library to save call frame hard registers as
> _Unwind_Word. OK for 4.7?
I think this will break the ABI for the MIPS N32 ABI. Not to mention
the MI
Hi,
We shouldn't save call frame hard registers as "void *". This patch
changes the unwind library to save call frame hard registers as
_Unwind_Word. OK for 4.7?
Thanks.
H.J.
commit 4163355471bfb192fdacc5da1ceb9aec5569ff94
Author: H.J. Lu
Date: Sun Mar 6 08:19:25 2011 -0800
Save
35 matches
Mail list logo
