On Tue, Mar 22, 2011 at 3:17 PM, Ian Lance Taylor <i...@google.com> wrote: > "Ulrich Weigand" <uweig...@de.ibm.com> writes: > >> Ian Lance Taylor wrote: >>> Andrew Pinski <pins...@gmail.com> writes: >>> > On Tue, Mar 22, 2011 at 9:42 AM, Ian Lance Taylor <i...@google.com> 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. >>> >>> That is a fair question. It does seem to me that it must be broken in >>> some cases. _Unwind_GetGRPtr will return &context->reg[index], which is >>> a void** cast to void*. We will then pass that to _Unwind_SetGRPtr. If >>> we later call _Unwind_SetGR on that register, it will write a value of >>> size _Unwind_Word through that pointer. Similarly if we call >>> _Unwind_GetGR, it will read a value of size _Unwind_Word. In both >>> cases, we will be accessing a 4-byte field as an 8-byte value. >>> >>> If MIPS N32 works today, then something must be ensuring that that >>> sequence can never occur, or that for some reason it never matters. >> >> Well, the whole problem only occurs when using the "by value" mechanism, >> which is only triggered by DW_CFA_val_... CFI statements, which are new >> in Dwarf-3 and seem to be very rarely used: they are apparently never >> generated by GCC, and the only files I could find in current glibc that >> create such CFI by hand are Intel-specific. > > I see, thanks. > > H.J., what is the failure mode that you are seeing?
Yes, those come from hand written CFI statements for signal handler. > 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 process? -- H.J.
