Hi all,
In an effort to improve compatibility on the CodeView debug info side, we need to output a few new record types on the backend that don’t seem to have the necessary info tracked by the debug info metadata. Specifically:
- For each compile unit, we need to emit a record containing the output file name (e.g. foo.obj)
- For each compile unit, we need to emit a record containing the full command line of the compiler invocation.
AFAICT, none of this information is in the debug info metadata. I’ve done a bunch of work on the backend of emitting debug info, but not so much on the front end. Where would be a good place to get started for looking into this?
Hi all,
In an effort to improve compatibility on the CodeView debug info side, we need to output a few new record types on the backend that don't seem to have the necessary info tracked by the debug info metadata. Specifically:
1) For each compile unit, we need to emit a record containing the output file name (e.g. foo.obj)
It would probably be best to add this as new field to DICompileUnit.
2) For each compile unit, we need to emit a record containing the full command line of the compiler invocation.
When enabled, the clang codegen option CGOpts::DwarfDebugFlags already adds the command line to the DICompileUnit.
AFAICT, none of this information is in the debug info metadata. I've done a bunch of work on the backend of emitting debug info, but not so much on the front end. Where would be a good place to get started for looking into this?
For (1) I would start by looking at the most recent patches that added new fields to DICompileUnit, such as the DebugInfoForProfiling flag.
-- adrian
Hi all,
In an effort to improve compatibility on the CodeView debug info side, we need to output a few new record types on the backend that don’t seem to have the necessary info tracked by the debug info metadata. Specifically:
- For each compile unit, we need to emit a record containing the output file name (e.g. foo.obj)
It would probably be best to add this as new field to DICompileUnit.
Like the name of the dwo file, the name of the object isn’t known at ir generation time - for example in LTO situations. So this probably should be passed down the same way the dwo name is - an MC option (I think that’s what I used) or backend option.
(Though I do have some questions about the need for this cv debug info - as I mentioned on the associated llvm bug - though I don’t recall the PR number)
That’s my guess.
- For each compile unit, we need to emit a record containing the full command line of the compiler invocation.
When enabled, the clang codegen option CGOpts::DwarfDebugFlags already adds the command line to the DICompileUnit.
Agreed.