- User Since
- May 26 2014, 12:49 PM (256 w, 2 d)
Fri, Apr 19
I just built against trunk with VS 2019 and ran into this exact issue. llvm-tblgen had no command line options. Are more fixes still in the pipeline or was this thought to be sufficient?
Fri, Apr 12
Thu, Apr 11
Wed, Apr 10
Tue, Apr 9
Mon, Apr 8
Fri, Apr 5
Wed, Apr 3
Also remove LLDBTriggerable.py
Add the scheduler back but remove the android builder only.
Tue, Apr 2
Mon, Apr 1
Can't you just write a function that, every time you call it, traces the symbol back to its original compile unit (you can get this from the PdbCompilandSymId), get the CompileUnit item, and ask it for its language? The part that seems unnecessary is the cache.
Is the nature of the PDB different enough that it warrants an entirely new implementation? There's a efw places where we parse decorated / undecorated names, but in general I would imagine most of the stuff is language agnostic no?
Do you have a single PDB with multiple source file languages in it? This seems like it is going to consume a ton of memory if there's one of these for each SymUID
Fri, Mar 29
Nice, does this actually have any performance impact? Since the arrays are smaller and have better cache locality.
Thu, Mar 28
Tue, Mar 26
Mar 21 2019
Mar 20 2019
If we ever wanted more aggressive pruning of dead type information, it probably makes sense to do that as a post-processing step where we re-write the PDB, something like an llvm-pdbutil gc subcommand.
Updated based on suggestions, including removal of the m_dwarf_data member variable which holds the contents of the __DWARF segment on MachO.
Mar 19 2019
I went ahead and just removed the const get version entirely, while changing the other function name to getOrLoad as you suggested. I have another patch while I'll upload after this one that converts all of the rest of the functions (except for the virtual ones required for DWO support), and the const version of the function was literally never needed, except in one place that was itself dead code. So, in the spirit of YAGNI, it's gone until it demonstrates a need.
This LGTM, but let's give it a day to see if anyone else chimes in with comments.
Mar 18 2019
In all cases, I think the question worth asking is not "could it be used for X", but rather "how often is it actually used for X". Otherwise, it's just technical debt IMO. There's a lot of things that are possible in theory, but unless it exhibits value in practice, YAGNI.
Mar 15 2019
"MinidumpNew" is a little bit vague. What's "new" about it? Is there a way we could come up with a better name?
Or better yet, make it a static method on each SB class. E.g. SBTarget::InitializeReproducerRegistry(); etc, one for each class.