search for: symbolrecord

...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)) > > >> >&...

...t there are other 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/Objec...

...> 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)) >> &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

...>>> >>>> if (File.hasPDBGlobalsStream() && File.getPDBGlobalsStream()) { >>>> GSIStreamBuilder &builder = this->getGsiBuilder(); >>>> GlobalsStream &stream = *File.getPDBGlobalsStream(); >>>> SymbolStream &SymbolRecords = cantFail(File.getPDBSymbolStream()); >>>> >>>> for (uint32_t PubSymOff : stream.getGlobalsTable()) { >>>> CVSymbol Sym = SymbolRecords.readRecord(PubSymOff); >>>> builder.addGlobalSymbol(Sym); >>>> } >>>>...

...;> if (File.hasPDBGlobalsStream() && File.getPDBGlobalsStream()) { >>>>>> GSIStreamBuilder &builder = this->getGsiBuilder(); >>>>>> GlobalsStream &stream = *File.getPDBGlobalsStream(); >>>>>> SymbolStream &SymbolRecords = cantFail(File.getPDBSymbolStream()); >>>>>> >>>>>> for (uint32_t PubSymOff : stream.getGlobalsTable()) { >>>>>> CVSymbol Sym = SymbolRecords.readRecord(PubSymOff); >>>>>> builder.addGlobalSymbol(Sym); >&gt...

...l 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))...

...>>>>>>>>>> to be fixed up. LLD already has code to do this, you can probably borrow a >>>>>>>>>>>> similar algorithm with some slight modifications (lldb/COFF/PDB.cpp, search >>>>>>>>>>>> for mergeSymbolRecords) >>>>>>>>>>>> >>>>>>>>>>>> 3) Merge in the new section contributions and section map. See >>>>>>>>>>>> LLD again for how to modify these. Hopefully the object file you exported >>&gt...