Previously we were just writing an empty globals stream. I hypothesized that fixing this would fix the last remaining known issue with using WinDbg, which is that we could not display local variables. Unfortunately this patch only gets us halfway there. Previously when displaying locals you would get an error message saying that private symbol information could not be found, and running the "lm" command in WinDbg would say that only public symbols were available. After this patch, the lm command reports that private symbols are present, but attempting to display a local variable still reports the same error. So there is something else missing.
This isn't really "computing" the name, it just gets it. getSymbolName seems more appropriate. It should also return a StringRef. This also needs to be really fast, because we do it on every external symbol. Setting up a deserialization pipeline is probably too much work.
Do any of these require any more work than knowing the offset of the name member of the symbol record? I'm thinking we might want to switch to compute the offset, and do the StringRef.split('\0') trick to find the null terminator.
We do this a lot, this is going to happen once per record. It would be nice to avoid copying the bytes before we hash them.
LLVM frequently factors large switches like this into separate functions. In this case, you can return the offset or some sentinel value like 0 or -1. This saves duplication of Sym.content().drop_front(Offset) and break becomes return 35.
Ouch, I was hoping all names were at constant offsets. We can put this in a separate if to implement the previously suggested refactoring.
IMO it would be nicer to avoid the use of the lambda. We have alternatives like strnlen and .split('\0').