search for: symbolrecords

It seems a little strange conceptually that object depends on BitcodeReader. Is it possible to break that dependency? On Thu, Mar 29, 2018 at 4:11 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Mar 26, 2018 at 4:52 PM David Blaikie <dblaikie at gmail.com> wrote: > >> On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: >>

On Mon, Mar 26, 2018 at 4:52 PM David Blaikie <dblaikie at gmail.com> wrote: > 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

No, Object is supposed to be an abstraction over real object files and LLVM bitcode object files. Maybe we can break the CodeView -> Object dependency. On Thu, Mar 29, 2018 at 4:23 PM Zachary Turner <zturner at google.com> wrote: > It seems a little strange conceptually that object depends on > BitcodeReader. Is it possible to break that dependency? > On Thu, Mar 29, 2018 at

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

Looks like maybe the CodeView -> Object dependency is out of date/old/not needed any more anyway... (don't see any Object headers included from the CodeView headers or implementation, etc). Will see if going that way internally is viable & loop back if it stumbles across something. On Thu, Mar 29, 2018 at 5:27 PM Reid Kleckner <rnk at google.com> wrote: > No, Object is

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