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

Julien Fischer jfischer at opturion.com
Tue Dec 27 15:24:28 AEDT 2022


Hi Zoltan,

On Tue, 20 Dec 2022, Zoltan Somogyi wrote:

> Rename the .ll_debug grade component to .c_debug.
> 
> runtime/mercury_grade.h:
>     As above. Also rename the C macro that controls the presence or absence
>     of this grade component from MR_LL_DEBUG to MR_C_DEBUG.
> 
> runtime/mercury_conf_param.h:
> runtime/mercury_debug.c:
> runtime/mercury_debug.h:
> runtime/mercury_engine.c:
> runtime/mercury_label.c:
> runtime/mercury_memory_zones.c:
> runtime/mercury_memory_zones.h:
> runtime/mercury_overflow.c:
> runtime/mercury_std.h:
> runtime/mercury_wrapper.c:
>     Rename the MR_LOWLEVEL_DEBUG macro to MR_DEBUG_THE_RUNTIME.
>     Previously, the name of this macro wrongly implied that it had
>     something to do with the old .ll_debug grade component, even though
>
>     - the MR_LOWLEVEL_DEBUG macro was designed to debug LLDS grades,
>       since only these existed when it was created, while
>
>     - the .ll_debug grade component (now .c_debug) applies only to
>       MLDS grades targeting C.

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).

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

...

> scripts/mgnuc.in:
> scripts/mgnuc_file_opts.sh-subr:
>     To avoid a conflict with the three sh subroutines above, which mgnuc uses,
>     rename the sh variable that mgnuc uses to represent the value of its own
>     --c-debug option, which is *completely separate* from the --c-debug
>     option interpreted by the three sh subroutines, from c_debug to
>     c_debug_opt. Likewise rename the associated sh variable holding the
>     C compiler options that c_debug_opt calls for if enable.
>
>     XXX At the moment, how any --c-debug option given to mgnuc will be handled
>     depends on sh's handling of duplicate case labels. Should we rename
>     mgnuc's own --c-debug-option?

Yes.

>     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

(Obviously, the short option '-g' can remain unchanged.)

That looks fine otherwise.

Julien.


More information about the reviews mailing list