Re: Enhanced language support for Modula-2

Gaius Mulley
2006-03-02T08:57:21Z

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

> - You need to post a ChangeLog entry along with your patch.

> I have some futher comments mixed in with the patch below.

ok, will do..

> Adding new references to deprecated variables or functions is frowned
> on. These are bits of interface that we've decided we'd like to get
> rid of over time; every new use is another case that someone trying to
> remove the variable/function needs to consider and understand.

ok,

> Also, this code looks like it's cut-and-paste from c-typeprint.c; does
> HP C (also known as aCC) generate Modula-2 code? Can't all this just
> go away?

yes I think it can..

> In general, I'm surprised at the structure of the type printing code.
> All this varspec prefix and varspec suffix crud is there to deal with
> C's weird pseudo-algebraic type syntax, where the parse tree is the
> reverse of the natural type tree. Surely Modula-2 doesn't imitate
> that --- does it? Couldn't Modula's types be printed with a
> straightforward tree walk? Apologies if you've explained this
> before.

the tree walk approach would be much cleaner - and much shorter - I'll
re-implement m2-typeprint.c accordingly. I originally kept it (cut and
paste) the same as c-typeprint.c, to preserve any debugging
information which Modula-2 does not use, which would allow users to

set lang m2
print s

and see language differences with maybe non m2 constructs written in
C. I now think this idea is ugly :-) and probably serves little
purpose and would cause confusion anyhow. Now that dwarf2read.c takes
a different approach w.r.t CHAR and char the mixed language approach
makes even less sense.

>
> > @@ -6153,25 +6179,29 @@
> > case DW_LANG_C_plus_plus:
> > cu->language = language_cplus;
> > break;
> > + case DW_LANG_Cobol74:
> > + cu->language = DW_LANG_Cobol74;
> > + break;
> > + case DW_LANG_Cobol85:
> > + cu->language = DW_LANG_Cobol85;
> > + break;
>
> Was this code here before? I'm sorry I didn't catch it the first
> time. You can't use DWARF language constants as values for
> cu->language; that's GDB's internal 'enum language'. They're
> completely different enums.

oops terribly sorry, awful mistake..

Thanks for the suggestions about gdb.texinfo and the guidance in
general, - I'll work on all these issues and resubmit in a week or
two.

regards,
Gaius