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

[Zoltan Somogyi]

2022-12-27 15:24 GMT+11:00 "Julien Fischer" <jfischer at opturion.com>:
> I don't think .ll_debug (i.e. .c_debug) was ever intentionally restricted to
> the MLDS backend.  It's just much less useful with the low-level C backend (and
> gdb is likely to get *very* confused about some of what we do in those grades).

I modified the text to avoid giving the wrong impression.

> My suspicion is that the original author of the .ll_debug grades wasn't
> fully aware of what defining MR_LOWLEVEL_DEBUG would do.

Mine as well.

>>     Or should we have it also set the value
>>     of the c_debug sh variable, thereby implying the value of this grade
>>     component? The latter seems iffy, but I also can't think of any good
>>     new name for mgnuc's own -c-debug option.
> 
> I suggest something like:
> 
>       --debug-info
>       --include-debug-info
>       --emit-debug-info

I tried this out with --cdebug-info, but the result was less than satisfactory,
due to the fact that the same option names now mean different things
when given to mmc versus when given to mgnuc.

I therefore propose the following scheme:

- Both mmc and mgnuc should accept an option named --c-debug, which
  should cause both to pass -g to the C compiler, *without* affecting the grade.

- Both mmc and mgnuc should accept an option named --c-debug-grade,
  which will add .c_debug to the grade (for hlc grades), and will therefore
  also pass -g to the C compiler.

The internal variables in the compiler and in shell scripts should also follow
this naming scheme, which should

- suggest what the difference between the two options is, and
- should make it easy to fully document that difference in the user guide
  and in help messages.

Any objections, or suggestions for better naming schemes?

> That looks fine otherwise.

Thanks for the review.

Zoltan.