search for: codeviewtypes

...gt; > So I guess still need to split up DebugInfo/CodeView (assuming the bits > needed by MC don't depend on Object)? Any suggestions? Sink it into > BinaryFormat or name a new library? > > (it's quite a few headers by the looks of it: CodeView.h, Line.h, > SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, > CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, > RecordSerialization.h - maybe some of those aren't needed, if they're > excessive includes or the like (they tend to seep in all over the place)) > > >> >> >>>...

...r tblgen files in LLVM IR, etc. So I guess still need to split up DebugInfo/CodeView (assuming the bits needed by MC don't depend on Object)? Any suggestions? Sink it into BinaryFormat or name a new library? (it's quite a few headers by the looks of it: CodeView.h, Line.h, SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, RecordSerialization.h - maybe some of those aren't needed, if they're excessive includes or the like (they tend to seep in all over the place)) > > >> include/llvm/Object/COFF.h includes...

...is the logical place to do this because only the >> back-end knows the code addresses, data addresses, and stack frame layouts. >> >> >> >> *Representation of CodeView in LLVM IR* >> >> DICompileUnit >> >> + e*xisting fields* >> >> + CodeViewTypes : DICodeViewTypes >> >> >> >> DICodeViewTypes >> >> + TypeRecords : MDString[] >> >> + UDTSymbols : DICodeViewUDT[] >> >> >> >> DICodeViewUDT >> >> + Name : MDString >> >> + TypeIndex : uint32_t >>...

...still need to split up DebugInfo/CodeView (assuming the bits >> needed by MC don't depend on Object)? Any suggestions? Sink it into >> BinaryFormat or name a new library? >> >> (it's quite a few headers by the looks of it: CodeView.h, Line.h, >> SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, >> CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, >> RecordSerialization.h - maybe some of those aren't needed, if they're >> excessive includes or the like (they tend to seep in all over the place)) >> >> >>&gt...

On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: > On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > >> I'm looking at fixing some layering violations in LLVM & came across a >> few in the CodeView handling, specifically: >> >> lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers

...umbers, and source file info for any functions and data defined in the compilation unit. The back-end is the logical place to do this because only the back-end knows the code addresses, data addresses, and stack frame layouts. Representation of CodeView in LLVM IR DICompileUnit + existing fields + CodeViewTypes : DICodeViewTypes DICodeViewTypes + TypeRecords : MDString[] + UDTSymbols : DICodeViewUDT[] DICodeViewUDT + Name : MDString + TypeIndex : uint32_t DIVariable + existing fields + TypeIndex : uint32_t DISubprogram + existing fields + TypeIndex : uint32_t The existing DICompileUnit node will have...

...up DebugInfo/CodeView (assuming the bits >>> needed by MC don't depend on Object)? Any suggestions? Sink it into >>> BinaryFormat or name a new library? >>> >>> (it's quite a few headers by the looks of it: CodeView.h, Line.h, >>> SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, >>> CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, >>> RecordSerialization.h - maybe some of those aren't needed, if they're >>> excessive includes or the like (they tend to seep in all over the place)) >>> >...