Hello, I've grepped through the remaining uses of Unwind_Word in libgcc and the related word_mode uses in gcc and would like to discuss how to go on with these.
One target is to identify more places where we can get rid of _Unwind_Word. Other places exist where we definitely need a data type like _Unwind_Word representing a general purpose register. So we have to find a way to define _Unwind_Word without using the mode(word) attribute. Unfortunately all changes in exception handling data structures have the risk of breaking the ABI. The problem is that there might be unwinding code using the old data structures copied or statically linked to binaries. This binary might be executed together with a language library (like libstdc++) containing a personality function expecting the new data structures and vice versa. So at first all data structures used to interface with the personality function must not be changed. And probably there are several other ABI issues I'm currently not aware of. Here is the list of mode(word) related data types together with a few comments on how I think we might handle those: Within gcc: except.c: word_mode is used in init_eh to define the SjLj_Function_Context data structure. I think the data types can be made matching the unwind-sjlj.c definition using a new target macro. sjlj_emit_dispatch_table emits code accessing the data member of the SjLj_Function_Context using UNITS_PER_WORD to step from one element to the next. This has to match the data type used for the "data" member using the target macro mentioned above. c-common.c: handle_mode_attribute: This word_mode use of course goes away with the mode(word) type attribute. Within libgcc: unwind-dw2.h: Here the _Unwind_FrameState structure is defined. This structure seems to be used locally only. The members using _Unwind_Word types look to me as they can safely use unsigned long instead of _Unwind_Word or _Unwind_Ptr for addresses. _Unwind_Word reg; _Unwind_Sword offset; _Unwind_Sword cfa_offset; _Unwind_Word cfa_reg; _Unwind_Sword data_align; _Unwind_Word code_align; _Unwind_Word retaddr_column; unwind-compat.c: Defines wrapper functions for interfacing with libunwind. Here the data type used by libgcc for registers (_Unwind_Word) has to be translated to the data type used by libunwind (which is unsigned long). These functions must know what libgcc unwinding code considers a register type so we are bound to _Unwind_Word I think. unwind-sjlj.c: The data field of SJLJ_Function_Context contains the data array with 4 _Unwind_Word fields. The data type must match what init_eh uses - which is word_mode. See except.c:init_eh above. unwind-generic.h: Defines the _Unwind_Exception structure. This structure is passed to the language personality function which might be defined in a different shared library. So I think it is not safe to change this structure in any way. The _Unwind_GetGR SetGR functions allow the personality function to manipulate registers during unwinding. I think we are bound to something like _Unwind_Word. unwind-dw2.c: Defines _Unwind_Context. Passed to the personality function so the _Unwind_Exception argument applies here as well. _Unwind_Word is also used in uw_install_context_1 to check whether dwarf registers have pointer or register size. execute_stack_op uses an array representing the registers which are object to dwarf operations. Independenly on whether we can further reduce the _Unwind_Word uses we have to provide a data type to libgcc which is appropriate for holding the value of a general purpose register. I think it can be done the same way we do it for the long double stuff. Define a macro in the <target>.h file which is available for IN_LIBGCC2 only. Comments and suggestions are welcome. Bye, -Andreas-
