On Sat, Apr 9, 2011 at 6:52 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Thu, Mar 24, 2011 at 12:15 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand <uweig...@de.ibm.com> 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 a long time ago, which is why >>> s390.h now has this comment: >>> >>> /* Number of hardware registers that go into the DWARF-2 unwind info. >>> To avoid ABI incompatibility, this number must not change even as >>> 'fake' hard registers are added or removed. */ >>> #define DWARF_FRAME_REGISTERS 34 >>> >>>> I don't suppose there's any way that we can declare these old >>>> programs Just Broken, and drop this compatibility stuff? >>> >>> I wouldn't like that ... we did run into this problem in the wild, and >>> some s390 users really run very old programs for some reason. >>> >>> However, I'm wondering: this bug that leaked the implementation of >>> _Unwind_Context only ever affected the *original* version of the >>> structure -- it was fixed before the extended context was ever >>> added, right? >>> >>> If this is true, we'd still need to keep the original context format >>> unchanged, but we'd be free to modify the *extended* format at any >>> time, without ABI considerations and need for further versioning ... >>> >> >> From what I can tell, the issues are: >> >> 1. _Unwind_Context is supposed to be opaque and we are free to >> change it. We should be able to extend DWARF_FRAME_REGISTERS >> to support the new hard registers if needed, without breaking binary >> compatibility. >> 2. _Unwind_Context was leaked and wasn't really opaque. To >> provide backward binary compatibility, we are stuck with what we >> had. >> >> Is that possible to implement something along the line: >> >> 1. Add some bits to _Unwind_Context so that we can detect >> the leaked _Unwind_Context. >> 2. When a leaked _Unwind_Context is detected at run-time, >> as a compile time option, a target can either provide binary >> compatibility or issue a run-time error. > > This is the attempt to implement it. Any comments? > > Thanks. > > -- > H.J. > -- > 2011-04-09 H.J. Lu <hongjiu...@intel.com> > > PR other/48007 > * unwind-dw2.c (UNIQUE_UNWIND_CONTEXT): New. > (_Unwind_Context): If UNIQUE_UNWIND_CONTEXT is defined, add > dwarf_reg_size_table and value, remove version and by_value. > (EXTENDED_CONTEXT_BIT): Don't define if UNIQUE_UNWIND_CONTEXT > is defined. > (_Unwind_IsExtendedContext): Likewise. > (_Unwind_GetGR): Support UNIQUE_UNWIND_CONTEXT. > (_Unwind_SetGR): Likewise. > (_Unwind_GetGRPtr): Likewise. > (_Unwind_SetGRPtr): Likewise. > (_Unwind_SetGRValue): Likewise. > (_Unwind_GRByValue): Likewise. > (__frame_state_for): Initialize dwarf_reg_size_table field if > UNIQUE_UNWIND_CONTEXT is defined. > (uw_install_context_1): Likewise. Support UNIQUE_UNWIND_CONTEXT. >
PING. -- H.J.
