On Tue, Apr 26, 2011 at 6:07 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > 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. >
Hi Jason, Can you take a look at: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00695.html Thanks. -- H.J.
