PDB symbol reader supports C++ only?

Hi!

I’ve been investigating why LLDB refuses to set breakpoints in Rust source files when using PDB debug info on Windows… This seems to stem from a couple of checks here and here.

I am wondering, what is the backstory there? Are those still necessary? I tried disabling them and Rust debugging worked just fine…

Various parts of lldb require knowing the source language. It’s possible that things will mostly work if you report that the language is c++, but you’ll probably get errors in other areas. It goes all the way down to the CodeView level, where certain cv records indicate the original source language. Can you check cvconst.h (ships with DIA SDK) and look for the enumeration corresponding to source language? Does it have a value for Rust? I’m guessing it doesn’t. When you generate PDBs for Rust you probably need to put something unique value there, then we could properly set the language in lldb

Would you mind going into a bit more detail on what sort of problems an unknown language could cause? I’d like to understand the issue before jumping in to fix anything. AFAIK, in the case of DWARF symbols, debug info for unknown languages is still used, so it wouldn’t be the first for LLDB…

Also, the second fragment checks for specific file extensions, which is an unreliable method, IMO, since there’s more extensions in use for c++ alone. Code could also be generated by a template engine, which will probably use a different extension, etc. I’d rather not just hardcode ‘.rs’ for Rust.

I was hoping Aaron could commend on why this is necessary (i.e. why not just trust the language flag?)

Thanks!

I think Aaron added that code for when the language is not set, but he can clarify.

Off the top of my head I guess it helps with demangling symbols. Eg you can’t demangle symbols from a TU without knowing what the language is. There could be other reasons though. For example each language is going to have an ABI with respect to the generated code. This is used for unwinding, stepping, jitting code to run in the target, etc. all of those could be affected by the language.

Maybe someone else can chime in with more reasons

Would you mind going into a bit more detail on what sort of
problems an unknown language could cause? I'd like to understand
the issue before jumping in to fix anything. AFAIK, in the case
of DWARF symbols, debug info for unknown languages is still used,
so it wouldn't be the first for LLDB...

LLDB checks for DW_LANG_Rust and uses the C++ plugin in this case.

The Rust lldb (https://github.com/rust-lang-nursery/lldb/commits/rust-release-70)
removes this.

If you get something working, let me know. I'd like to incorporate it
into the Rust lldb.

Tom

These two changes ([1] [2]) appear to be sufficient to enable debugging of Rust binaries with pdb debug info (make sure that msdia140.dll is somewhere lldb can find it).

At a cursory glance, I did not observe any ill effects of disabling that language check, so I’m still not sure whether it was truly necessary, or more of “Let’s disable code paths we did not test”.

As for allocating a language code for Rust, does Microsoft even have a procedure for this? In any case, looks like D folks had already staked out 0x44 for themselves. I suggest we claim 0x27 :slight_smile: