What's the status of this repository?

[riverar]

The README states (emphasis mine):

Simply put ...We will make best efforts to role this foward with the new compilers and tools that we ship every release. We will continue to innovate and change binary API's and ABI's for all the Microsoft platforms and we will try to include the community by keeping this PDB repo in synch with the latest retail products (compilers,linkers,debuggers) just shipped.

We could an update here @AndrewPardoe. 😄

[ljmf00]

@GreatKeeper @AndrewPardoe Any attention on this? char8_t type kind introduced in C++20 is unknown and debuggers/compilers such as the LLVM-based ones that want to export proper type kinds does not currently support it, therefore https://reviews.llvm.org/D66447 is half done.

[zjturner]

As the original author of most/all of LLVM's PDB support, I don't think this repo needs updated in order to properly support types like char8_t. This kind of thing can be figured out relatively easily by using llvm-pdbutil to explore Microsoft-generated PDB files. Unless there are fundamental changes to the nature of the underlying storage format, I think an update here isn't strictly needed.

Note that I don't currently work on LLVM anymore, and Andrew doesn't currently working at Microsoft anymore. Realistically speaking, I think it's unlikely we'll see another update to this repo any time soon (if ever).

But I don't think that's cause for panic, the current LLVM team is more than capable of adding support for small changes in the PDB format, and the same goes for any sufficiently motivated third party willing to understand the LLVM code / file format.

[ljmf00]

As the original author of most/all of LLVM's PDB support, I don't think this repo needs updated in order to properly support types like char8_t. This kind of thing can be figured out relatively easily by using llvm-pdbutil to explore Microsoft-generated PDB files. Unless there are fundamental changes to the nature of the underlying storage format, I think an update here isn't strictly needed.

I know that this information can be easily fetched but I guess either updating this regularly or have other PDB documentation somehow helps the developers figuring things out more easily, especially without requiring MSVC to generate recent PDB files.

Note that I don't currently work on LLVM anymore, and Andrew doesn't currently working at Microsoft anymore. Realistically speaking, I think it's unlikely we'll see another update to this repo any time soon (if ever).

Thanks for that information, I don't really know who to ping tho. If you know, please do :)

But I don't think that's cause for panic, the current LLVM team is more than capable of adding support for small changes in the PDB format, and the same goes for any sufficiently motivated third party willing to understand the LLVM code / file format.

I understand and didn't want to cause panic at all. As a new LLVM contributor and non-Windows user I found this type of documentation userful to be up-to-date. I think this is also useful for clean room implementation of PDB writers/readers.

Also please note that I'm point this out assuming there is no other documentation easily available.

[zjturner]

I think we agree :) I would love it if this repo were updated regularly. I just have the feeling that it isn't going to happen and that they gave us a code dump and moved on. Which I'm very thankful for! It was enough to get the ball rolling. Before I left Google, I did start writing up some documentation on PDB format, which is still here. So I think going forward the best thing to do is add additional documentation there as it's discovered (and also update llvm tools to support new things that are discovered).

It's been a couple years, but I vaguely recall that char8_t actually worked. Easiest thing to do would be to write a program

int main()
{
   char8_t foo my_local_char8_variable;
}

compile this using MSVC and /std:c++20, use llvm-pdbutil to dump the debug info record for the local variable named my_local_char8_variable, and then teach LLVM to emit the same thing. llvm-dev@ is a good place to ask general questions.

[ljmf00]

I think we agree :) I would love it if this repo were updated regularly. I just have the feeling that it isn't going to happen and that they gave us a code dump and moved on. Which I'm very thankful for! It was enough to get the ball rolling. Before I left Google, I did start writing up some documentation on PDB format, which is still here. So I think going forward the best thing to do is add additional documentation there as it's discovered (and also update llvm tools to support new things that are discovered).

It's been a couple years, but I vaguely recall that char8_t actually worked. Easiest thing to do would be to write a program

int main()
{
   char8_t foo my_local_char8_variable;
}

compile this using MSVC and /std:c++20, use llvm-pdbutil to dump the debug info record for the local variable named my_local_char8_variable, and then teach LLVM to emit the same thing. llvm-dev@ is a good place to ask general questions.

Thanks for the valuable information and such useful documentation. If I need to debug something on Windows I can take that moment to add this, otherwise, I guess I'm going to just create an issue and cross-reference this, if someone is interested in getting this supported, because I don't have Windows at all to do that test or I don't know a good tool online to check that either (something like godbolt but for MSVC).

My motivation to write here has because of that. This is such simple addition and taking the effort of using MSVC (for me installing Windows and MSVC toolchain) is not worth it.

[zjturner]

I did a quick glance, and it looks like char8_t is 0x7C, so that needs to be added to the enum in TypeIndex.h, and then all the code that deals with TypeIndexes (e.g. CodeViewDebug.cpp and a few other places), need to be taught about this new value. I probably will not personally make this change (busy with other stuff and I don't even have a clone of llvm anymore), but feel free to add this info to the issue you create.

[ljmf00]

I did a quick glance, and it looks like char8_t is 0x7C, so that needs to be added to the enum in TypeIndex.h, and then all the code that deals with TypeIndexes (e.g. CodeViewDebug.cpp and a few other places), need to be taught about this new value. I probably will not personally make this change (busy with other stuff and I don't even have a clone of llvm anymore), but feel free to add this info to the issue you create.

Thanks for the effort and explanation :)