This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Enhanced language support for Modula-2
- From: Gaius Mulley <gaius at glam dot ac dot uk>
- To: "Jim Blandy" <jimb at red-bean dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 02 Mar 2006 08:54:29 +0000
- Subject: Re: Enhanced language support for Modula-2
- References: <87vevg9puv.fsf@j228-gm.comp.glam.ac.uk> <8f2776cb0602151619w5fd8f043u3e7227e27f3567a9@mail.gmail.com> <20060220150513.GB14155@nevyn.them.org> <8f2776cb0602201322o3791841dv2916e53181e9f308@mail.gmail.com> <87lkw5qaa9.fsf@j228-gm.comp.glam.ac.uk> <8f2776cb0602211055t572223ecs93e37d5575a31ce@mail.gmail.com> <87wtfjfwmu.fsf@j228-gm.comp.glam.ac.uk> <8f2776cb0602252137q7e716ffaibd7b88eeb0d16e43@mail.gmail.com> <87mzgc9rug.fsf@j228-gm.comp.glam.ac.uk> <8f2776cb0602272243y25582156x16534fd14028898c@mail.gmail.com>
"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