Re: Enhanced language support for Modula-2

["Jim Blandy" <jimb@red-bean.com>]

On 25 Feb 2006 12:31:05 +0000, Gaius Mulley <gaius@glam.ac.uk> wrote:
> I guess the Modula-2 mode can use a different method. Would it be
> allowable for me to extend the
>
>     #define TYPE_FLAG_xxx
>
> sequence (currently bits 0..15 are used).  So for example:
>
>     #define TYPE_FLAG_LANG_CHAR (1 << 16)
>
> and set this flag if we see DW_ATE_signed_char or
> DW_ATE_unsigned_char.  Later in the Modula-2 language section this bit
> could be tested and the appropriate action taken. Obviously I'd need
> to set this bit in stabsread.c as well. This would also allow Pascal
> to utilise CHAR rather than see a tiny integer.

If Modula-2 has a genuinely distinct character type, then I think
TYPE_CODE_CHAR is the right type for you to use.  It's just that it
isn't for C.  So the code in dwarf2read.c needs to choose the type
code for a given DWARF base type based on the language of the
compilation unit that contains the die.  I think you'll need to test
cu->language, and set the type code appropriately in each case.

That may sound icky, but given that DWARF has decided to represent
different languages' types with a unified set of die tags, it seems
the reasonable way to go.  If, over time, read_base_type gets really
complicated due to this sort of thing, then we could always have some
sort of language-specific hook function.  But since GDB uses the same
approach to types that Dwarf does --- a unified set of type codes used
by all the languages --- we only really have to attend to the cases
where GDB's mappings are different from DWARF's, so I think it should
be okay for now.