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

[Sourabh Singh Tomar via llvm-dev]

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.





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/b69b2ee2/attachment.html>