Re: [PATCH] Introduce abi_word_mode

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Ian Lance Taylor wrote:

> "Ulrich Weigand" <uweigand@de.ibm.com> writes:
> > This is clearly a property of the ABI, so if we have two configurations
> > of GCC that purport to support the same ABI, but need to use differing
> > definitions of word_mode internally because they use differently-sized
> > general purpose registers, then we need a new target-defined mode that
> > the middle-end can use to implement attribute ((mode (word))).
> 
> That makes sense to me.  Thanks.  I do need to mention that you are
> talking about an unusual case.  You want to be able to link together
> different code compiled with different register sizes but using the
> same ABI.

Yes, exactly.  We want to generate code the fully conforms to the 32-bit
ABI, but is running under a 64-bit kernel and thus has access internally
to the full 64-bit registers and operations.  I understand that at least
on some PPC configurations, the same setup makes sense.

> For what it's worth, the EH data structures already use #ifdefs to
> pick the right size for a particular target--see unwind-generic.h.
> TARGET_EH_RETURN_FILTER_MODE exists to make the definition of
> _Unwind_Word match the way the value is used in except.c.  Something
> like this will be required if you want to compile new code that uses a
> different word size and wants to link against an existing libgcc_eh.so.

I'm not sure I follow you here -- the #ifdef in unwind-generic.h 
appears to be related to HPUX/IA64 being unhappy with the definition
of attribute ((mode (pointer))), not attribute ((mode (word))).

In fact, there is nothing right now that ensures the right size is
picked in unwind-generic.h -- it only works for rs6000 because they
*build* libgcc_eh in normal 32-bit mode, not the "64-bit register
32-bit ABI" mode.  They use TARGET_EH_RETURN_FILTER_MODE to allow
a program using execptions to work with such a libgcc_eh, even if
it is built in 64-bit register mode.

The solution Andreas and I are proposing would allow either libgcc_eh
or any program using it to be built in either 32-bit mode *or* 64-bit
register 32-bit ABI mode, such that any combination would work.

To summarize that solution:

- Define a new abi_word_mode (from the target's UNITS_PER_ABI_WORD)
  that is to represent the mode of attibute ((mode (word))).

- Do not change unwind-generic.h -- its data structures will now
  automatically correspond to the abi_word_mode.

- Explicitly use abi_word_mode in except.c when refering to data
  structures also manipulated by libgcc_eh code.

- This obsoletes TARGET_EH_RETURN_FILTER_MODE.

> I'm willing to look at a patch which fixes those cases only.

Just to clarify, is the solution outlined above what you
intended, or did I misunderstand?

> > Then, there may be a couple of uses of word_mode that are simply
> > erroneous and should be fixed (e.g. the errno case, or most likely
> > the STACK_SIZE_MODE case).
> 
> Yes, and to be clear, they should not change to abi_word_mode.

Agreed.

> > Finally, I agree that there are a number of remaining cases (like the
> > libcall return mode) that do not naturally fall into the abi_word_mode
> > case -- then again, maybe this particular case does if we consider
> > those libcall functions to be declared as having return type
> > int attribute ((mode (word))) ...  :-)
> 
> Actually, the libcall return mode does get covered by your definition
> of abi_word_mode; see the use of word_type in libgcc2.c.

OK, I see.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com