libgcc_s.so.1 ASIS won't work with glibc.
Mark Kettenis
kettenis@science.uva.nl
Wed Jul 4 15:13:00 GMT 2001
"H . J . Lu" <hjl@lucon.org> writes:
> Ok. How hard to implement __frame_start_for which is binary
> compatible with g++ v2? If it is implemented out side of gcc,
> do you have to reinvent the wheel? Have you tried to implement
> it? Have you looked at my first attempt to implement it inside
> of gcc?
In principle, it should be possible to construct a v2 compatible
`struct frame_state' from the _Unwind_Context and _Unwind_FrameState
returned by unwind-dw2.c:uw_frame_state_for() from the v3 sources.
>From looking at the sources I deduced that things map as follows:
frame_state.cfa -> ? [1]
frame_state.eh_ptr -> 0 [2]
frame_state.cfa_offset -> _Unwind_FrameState.cfa_offset
frame_state.args_size -> _Unwind_Context.args_size
frame_state.reg_or_offset -> _Unwind_FrameState.regs.reg[REG].loc [3]
frame_state.cfa_reg -> _Unwind_FrameState.cfa_reg
frame_state.retaddr_column -> _Unwind_FrameState.retaddr_column
frame_state.saved[REG] -> _Unwind_FrameState.regs.reg[REG].how [4]
There are some issues:
[1] Seems to be unused, at least the GCC 2.95 stuff doesn't set it.
Looks like we shouldn't touch it.
[2] Not true for "eh" augmentations. These seem to be mishandled by
GCC 3.0. The GCC 3.0 extract_cie_info() expects that an
augmentation is immediately followed by the code and data
alignment and return address column. Whereas the GCC 2.95
extract_cie_info() expects an eh_ptr pointer first.
[3] Actually loc.reg or loc.offset, based on [4].
[4] Only REG_SAVED_REG, REG_SAVED_OFFSET and REG_UNSAVED supported by v2?
What do we do with REG_SAVED_EXP? Right now, if a throw() from
code compiled with GCC 2.95 encounters REG_SAVED_EXP, it will
abort(). Is that a problem?
Hope this helps ...
Mark
More information about the Libc-alpha
mailing list