[llvm-dev] Query/Suggestions on upgrading macro infrastructure.

[David Blaikie via llvm-dev]

On Thu, Jan 2, 2020 at 6:03 AM Sourabh Singh Tomar <sourav0311 at gmail.com>
wrote:

> Hello Everyone,
>
>
>
> I would like to have your thoughts on this.
>
>
>
> Overview of the problem
>
> ===================
>
> While implementing support for the DWARFv5 debug_macro section support in
> LLVM. I came across these holes:
>
>    -  The macros infrastructure in CLANG/LLVM is inherently tied to a
>    particular version(v4 macinfo). For instance, consider this snippet from
>    CLANG:
>
> Gen->getCGDebugInfo()->CreateMacro(getCurrentScope(), llvm::dwarf::DW_MACINFO_define,
>> location, Name.str(), Value.str()).
>
>
>    - So, let's say you want to add support for a new form
>       /DW_MACRO_define_strx/, with existing infrastructure, you can't do this
>       without polluting code with lot of if-else. This is just to highlight the
>       problem, there are numerous areas where we will have to add if-else.
>       -  DWARF  forms[DW_MACINFO*] are unnecessarily hard-coded in CLANG,
>    resulting in a false dependence of CLANG/LLVM on entire generation phase of
>    debug info for macros, even when they don't have to.
>    -  To worsen the problem even more, we have some DWARF forms sharing
>    same encoding. Currently, we have 4-forms that share same encoding with
>    previous DWARFv4.
>
>
4 forms that share the same encoding in DWARFv4 - you mean the define,
define_strp, define_strx, and define_sup?

I think that the solution here is probably not to change the IR
representation - IR doesn't have the semantics that necessitate
strip/strx/sup encodings (there's no indexed string section at the IR level
- string sharing is a lower level implementation detail at the IR Level
that's not apparent at the IR Level). These are choices the backend would
make about how to efficiently encode the strings into the final output.

All this is to say that I agree with you about the semantics of your
proposal, but I think the /syntax/ of the IR can remain the same, just with
the semantics you're describing. (ie: that DW_MACINFO_define in the IR
doesn't necessarily mean you'll get a DW_MACINFO_define in the output (you
might get a DW_MACINFO_define, maybe a DW_MACINFO_define_strx, etc, etc... )


>
>
>  High Level Summary of Solution
>
> ========================
>
> To deal with this and to facilitate addition of new future DWARF forms
> and other stuff, I propose following changes to be done:
>
> ·  Segregate CLANG entirely from macro debug info part. This has been
> done by introducing a new Generic Macro Types. Since macro information can
> be  broadly classified into 4 categories:
>
> 1.     Definition
>
> 2.     Un-definition
>
> 3.     File inclusion
>
> 4.     File termination
>
> So I propose to introduce 4 new Generic Macro Types  to be used as types,
> with no dependence to various DWARFv5/v4 forms.
>
>
>    1. MACRO_definition
>    2. MACRO_undef
>    3. MACRO_start_file
>    4. MACRO_end_file
>
>
> - Previous infrastructure uses DWARF forms as types in metadata --
>
>> !DIMacro(type: DW_MACINFO_define, line: 9, name: "Name", value: "Value")
>
> And the production part will query this and emits the form
> present[hardcoded].
>
>
>
> Upgraded infrastructure will be using something like --
>
>> !DIMacro(type: MACRO_definition, line: 9, name: "Name", value: "Value")
>
> Now production part will query the Generic Macro Type present in metadata
> and based on the version of DWARF specified, it will emit forms accordingly.
>
>
>
> - Now this should cater to all our needs of LLVM and debug-info
> production-consumption WRT to macro.
>
>
>
> This approach solves the problem highlighted above and simplifies the
> code, increases code/infrastructure reuse for building DWARFv5 macro and
> future additons.
>
>
> I have a patch[implementing this] ready, currently supporting DWARFv4
> macro only. Planning to build rest of DWARFv5 on top of this. Could you
> guys let me know your thoughts and how to proceed forward with this. Should
> we need an RFC for it have a better discussion?
>
>
>
> Thanks in anticipation,
>
> Sourabh.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200102/47a7077f/attachment.html>