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. -- H.J.
