Hi Mehdi,
I understand the reasoning for supporting this proposal independently from CodeView support.
However, I do not think that it is needed for supporting CodeView.
When I say that my suggestion is more clean, I was pointing to CodeView support, assuming the changes in LLVM IR/Clang FE indicated in this proposal.
Also, it is not that clear from the proposal what will be shared (generic) between Dwarf and CodeView and what will be specific.
Regards,
Amjad
Hey,
Hi Mehdi,
I understand the reasoning for supporting this proposal independently from CodeView support.
However, I do not think that it is needed for supporting CodeView.When I say that my suggestion is more clean, I was pointing to CodeView support, assuming the changes in LLVM IR/Clang FE indicated in this proposal.
Also, it is not that clear from the proposal what will be shared (generic) between Dwarf and CodeView and what will be specific. <>
It all makes sense.
Thanks,
Mehdi
The split between CodeView and DWARF will happen at the level of type information. So, DIVariable, DISubprogram, DILocation, DILocalScope, etc will all be shared, but records and composite types etc will not.
I will say it one more time, it does not sound a good design to change the IR according to the target debug info format.
Why?
· This breaks the modularity of LLVM compiler, assume we want to support another debug info format in the future? Do you expect us to add another Record/Type specification to the IR?
· This means that we need to modify Clang FE, LLVM MED optimizations, and maybe duplicate/rewrite all related LIT tests , in addition to the expected work in codegen.
As I see it, we can easily separate the FE/MED parts from backend (codegen).
· In FE/MED we should have one representation for all debug info that capture the debug information from the sources (we should not lose information just because some formats, like DWARF, does not need them!)
· In Backend, we should have separate emitters that convert the debug information captured in the IR into suitable data structures that are related to the target debug info format.
In addition, if we think that some information will be much easier to calculate in FE rather than BE, we can create it either always, or according to the target, but in this case it should be defined as optional field in the debug info IR rather than a totally new separate debug info IR.
Regards,
Amjad
I will say it one more time, it does not sound a good design to change the
IR according to the target debug info format.Why?
· This breaks the modularity of LLVM compiler, assume we want to
support another debug info format in the future? Do you expect us to add
another Record/Type specification to the IR?· This means that we need to modify Clang FE, LLVM MED
optimizations, and maybe duplicate/rewrite all related LIT tests , in
addition to the expected work in codegen.
We don't expect to need to modify the middle end optimizations - type
information is generally opaque to them.
This actually reduces the test surface - as we don't have to test
generation of two different flavors of IR metadata as well as two different
flavors of final output. The output is produced only once, in the frontend.
(which we expect to need to modify for new debug info formats with
different features anyway) & some work in the backend (which needs wholely
new support for any new debug info format as well)
As I see it, we can easily separate the FE/MED parts from backend
(codegen).· In FE/MED we should have one representation for all debug info
that capture the debug information from the sources (we should not lose
information just because some formats, like DWARF, does not need them!)
For types in particular, this information is essentially equivalent to ASTs
- it's a lot to generalize over & having a format that can represent them
all (or has the complication of unions over different subsets so as not to
pay the cost of the sum of all debug info format properties) is somewhat
costly. It adds a lot of work to funnel this data through what isn't really
a very general system. Every time we add a new debug info feature (as you
saw with using directives, for example) it's a lot of plumbing through many
layers. The less stuff that has to have a new/separate representation
through all those layers, the better.
· In Backend, we should have separate emitters that convert the
debug information captured in the IR into suitable data structures that are
related to the target debug info format.In addition, if we think that some information will be much easier to
calculate in FE rather than BE, we can create it either always, or
according to the target, but in this case it should be defined as optional
field in the debug info IR rather than a totally new separate debug info IR.
That's partly the issue - the features necessary for the Windows ABI's
debug info in PDB files aren't generic, they're pretty specific, need to be
computed in the frontend and can't really be optional (any more than debug
info in general is optional).
- Dave