search for: libdebuginfodwarf

...be there, then we should have a very good reason why not. > > BranchProbability shouldn’t be there at all but probably is due to layering, and likely the same goes for TargetRegistry. We should fix that. Same goes for ARM* which should all be in the ARM backend. > Dwarf should be in libDebugInfoDWARF. I think the reason why it isn't there is because lib/DebugInfo is for *consuming* debug info, but these definitions are useful for both reading and writing DWARF. That is not to say that they couldn't be moved somewhere else of course (but probably not lib/DebugInfo in its current form)....

...> debugging on Windows. > > I think the best way to do this is to move all of the code in > lib/DebugInfo to lib/DebugInfo/dwarf, and then make another folder called > lib/DebugInfo/pdb. These would then be compiled into two separate > libraries. > > > so you would have libDebugInfoDWARF and libDebugInfoPDB. Would you still > have libDebugInfo at all? > > I ask because there is the DIContext abstraction that’s not tied to a > particular debug format (It’s used by llvm-symbolizer, and I guess you have > some interest in having that working on windows PDB files). But &...

...t in LLDB for reading PDBs while debugging on Windows. > > I think the best way to do this is to move all of the code in lib/DebugInfo to lib/DebugInfo/dwarf, and then make another folder called lib/DebugInfo/pdb. These would then be compiled into two separate libraries. so you would have libDebugInfoDWARF and libDebugInfoPDB. Would you still have libDebugInfo at all? I ask because there is the DIContext abstraction that’s not tied to a particular debug format (It’s used by llvm-symbolizer, and I guess you have some interest in having that working on windows PDB files). But DIContext.cpp as one meth...

...ing PDBs while debugging on Windows. >> >> I think the best way to do this is to move all of the code in lib/DebugInfo to lib/DebugInfo/dwarf, and then make another folder called lib/DebugInfo/pdb. These would then be compiled into two separate libraries. > > so you would have libDebugInfoDWARF and libDebugInfoPDB. Would you still have libDebugInfo at all? > > I ask because there is the DIContext abstraction that’s not tied to a particular debug format (It’s used by llvm-symbolizer, and I guess you have some interest in having that working on windows PDB files). But DIContext.cpp a...

...If they can’t be there, then we should have a very good reason why not. BranchProbability shouldn’t be there at all but probably is due to layering, and likely the same goes for TargetRegistry. We should fix that. Same goes for ARM* which should all be in the ARM backend. Dwarf should be in libDebugInfoDWARF. *DeltaAlgorithm aren’t even used outside of tests! Anyway, sorry for the brain dump. But yes, this has grown in to something which can be cleaner. Perhaps Support will still exist to wrap posix and friends, hopefully with ADT separately, but we should also move a bunch of things to better suit...

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the

...ly some opportunities to share some code, even if not the whole generator - might be best to refactor those opportunistically, rather than a wholesale "change DWARFLinker to use (all) of lib/CodeGen/AsmPrinter/Dwarf*". Sort of like the approach that's been taken with lldb's use of libDebugInfoDWARF - picking particular features that have high overlap and refactoring them to be reusable between the two different use cases. > Supporting new standard would require rewriting/modification of all these places. In the ideal world, > having single implementation for the DWARF generation allows...

I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic

In my experience the buildsystem works fine in combination with tablegen (at least this aspect of it). The real problem here is that tablegen is just slow. Some of the X86 tables take indeed Last time I looked at it tablegen had still room to optimize the way it resolves class hierarchies and the variables within which it did basically one at a time, so it needed to traverse the hierarchies

Hi Alexey, I should've looked at this earlier. I went through the thread again and I've made some comments, mostly from the dsymutil point of view. > Current DWARFEmitter/DWARFStreamer has an implementation for DWARF > generation, which does not support DWARF5(only debug_names table). At the > same time, there already exists code in CodeGen/AsmPrinter/DwarfDebug.h, > which