[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