[m-rev.] for review: rename the .ll_debug grade component for hlc grades to .c_debug

Peter Wang novalazy at gmail.com
Wed Dec 21 12:04:55 AEDT 2022


On Wed, 21 Dec 2022 11:29:20 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> 
> 
> On Wed, 21 Dec 2022, Peter Wang wrote:
> 
> > On Tue, 20 Dec 2022 22:41:25 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >> For review by anyone.
> >> 
> >> I am particularly seeking opinions on the XXX in the log file:
> >> the treatment of the --c-debug option to mgnuc.
> >
> > It's pretty confusing.
> >
> > Looking at the thread that prompted this change,
> > I don't really see how renaming .ll_debug to .c_debug helps.
> >
> > How about renaming .ll_debug to .rt_debug, .debug_runtime,
> > or something like that?
> 
> To me that makes it seems as though it's for debugging the runtime.  (I
> guess you meant runtime in a broader context though?) The intent of both
> the .ll_debug grades and the --c-debug option is to compile things in
> way that is suitable for use with tools like gdb or valgrind. That goes
> for the runtime code, C code generated by the compiler and handwritten C
> code in foreign_proc or foreign_code blocks.
> 
> --c-debug is the older of the two, and IIRC the .ll_debug component
> was introduced (at least partly) because it was fiddly to set
> things up consistently using --c-debug (i.e. ensure that -g -O0 was
> passed to gcc everywhere it needs to be).

Ok, I got confused. The .c_debug name makes sense then.

I think we should leave the mmc/mgnuc --c-debug (-g) option alone.

Can we drop any options to add or remove the .c_debug grade component
(previously .ll_debug)? If you want to use such a grade, just specify it
directly.

Peter


More information about the reviews mailing list