Re: Enhanced language support for Modula-2

[Gaius Mulley <gaius at glam dot ac dot uk>]

"Jim Blandy" <jimb@red-bean.com> writes:

> On 21 Feb 2006 10:24:46 +0000, Gaius Mulley <gaius@glam.ac.uk> wrote:
> > here is a reworking of my patch which includes a new version of the
> > set reading code in gdb/dwarf2read.c. Also contained is a patch to
> > gdb/doc/gdb.texinfo reflecting the enhancements to the Modula-2 mode.
> 
> Okay.  That solves that problem.  :)
> 
> I'm a little concerned about the change to dwarf2read.c where you
> create a TYPE_CODE_CHAR type for DW_ATE_signed_char and
> DW_ATE_unsigned_char.  GDB uses TYPE_CODE_INT for C 'char' types.  I
> have vague memories of something going wrong with printing or
> evaluation or something if you actually use TYPE_CODE_CHAR, and after
> discussion deciding to stick with TYPE_CODE_INT.
> 
> But this patch causes no test suite regressions?

Hi,

thanks for all your suggestions/feedback about the patch, I'll
incorporate these changes, polish it and resubmit. Re:
regressions.. hmm, yes it does cause some regression failures, so I'll
retract the TYPE_CODE_CHAR type for DW_ATE_signed_char and
DW_ATE_unsigned_char in dwarf2read.c.

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.

Or is there a better/cleaner way?

regards,
Gaius