[llvm-dev] Query/Suggestions on upgrading macro infrastructure.
Sourabh Singh Tomar via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 2 06:03:26 PST 2020
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
> 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
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:
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.
- 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
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
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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev