Various fixes from the getsentry/pdb issue tracker

[DanielT]

This is a bundle of various fixes I gathered from the getsentry/pdb issue tracker:

• Add support for small MSF file format getsentry/pdb#150 by @camden-smallwood
• Add updated SourceLanguage variants getsentry/pdb#157 by @Walnut356
• Add support for C++20's char8_t getsentry/pdb#147 by @ergrelet
• Implement managed procedures and local var slots getsentry/pdb#146 by @michal-kapala
• Add DebugInformation::is_stripped to easily query to see if PDB is stripped getsentry/pdb#143 by @DrChat
• Implement VirtualFunctionTable / VirtualTableShape getsentry/pdb#141 by @CouleeApps
• Add remaining FieldAttribute values getsentry/pdb#136 by @TrinityDevelopers
• Implement AliasType getsentry/pdb#134 by @TrinityDevelopers
• Fix clippy and rustdoc lints getsentry/pdb#152 by @Swatinem

[DanielT]

There are also two pull requests for getsentry/pdb which I intentionally did not include in this bundle:

• Synthesize sections from section map (fixes #153) getsentry/pdb#154 by @vvuk:
  1. I don't understand the use-case and am not sure this is correct
  2. @vvuk has already submitted this pull request separately
• Fix is_pure_virtual not recognizing pureintro functions getsentry/pdb#135 by @TrinityDevelopers
  I was not sure this is correct

[vvuk]

For getsentry#154 -- the PDB files in question come from dotnet built with crossgen2, which is a dotnet tool that pre-JITs assemblies for faster startup. These PDB files contain debug info for that pre-JITted code, and are needed for (in the particular use case) samply to identify any useful info about stacks that contain that code.

The PDB files seem to be very minimal -- they're generated by crossgen2 directly, and as such don't contain the same info that pdb files generated by cl or similar contain. The solution in that PR was the simplest that got the desired results when working with these files. I don't think it would ever really be hit in any other use case, because typically the section headers will be present otherwise.

[afranchuk]

There are a few minor issues/questions I'd like addressed, otherwise it looks good!

[DanielT]

Thanks for the review!

As noted in the description, this is a bundle of changes by other people from the pdb issue tracker.
I have some changes of my own to support various section types used by LLVM for Rust code that I will create pull request for later, but I started on the basis of all of these changes. Once we've reached a consensus about this, I'll rebase my code and send you that too.

As a result I can't really say anything about the original intention of each author.
From my perspective your review comments look like good improvements.

How would you prefer that I address them - should I amend the original commits, or add a "fixes" commit to the pull request?

[afranchuk]

I would normally say to amend the commits, but as they are pulled from elsewhere a fixes commit would be more appropriate. Most of these are minor, the important ones are probably #2 (comment) and #2 (comment).

[CouleeApps]

If you're taking my one PR you may want the various other changes I made since then. See https://github.com/Vector35/pdb-rs/commits/master/

Is there a consensus on which version of this repo is maintained? The v35 one is not super active and the getsentry one has been effectively untouched for 2+ years. Would love to have somewhere to contribute changes back to, but I don't think I have the time to maintain it myself through my work.

[afranchuk]

If you're taking my one PR you may want the various other changes I made since then. See https://github.com/Vector35/pdb-rs/commits/master/

Is there a consensus on which version of this repo is maintained? The v35 one is not super active and the getsentry one has been effectively untouched for 2+ years. Would love to have somewhere to contribute changes back to, but I don't think I have the time to maintain it myself through my work.

This one is published to crates.io as pdb2 since I could not get the pdb owners to respond to me. For the time being, I can maintain it. However, if they choose to in the future, they may take the changes here back in.

[DanielT]

@michal-kapala and @CouleeApps - should I remove your changes from this PR?
If you want to submit your changes yourself, then that would be ideal from my point of view, but I'll proceed if you don't have time.

[CouleeApps]

If you want to submit your changes yourself, then that would be ideal from my point of view, but I'll proceed if you don't have time.

You're welcome to include any changes I've made (they are under the MIT/Apache2 license after all) but I don't forsee getting much time at work to maintain this in the near future.

[michal-kapala]

If you want to submit your changes yourself, then that would be ideal from my point of view, but I'll proceed if you don't have time.

I'd appreciate a merge with the typo fixes, my PR was self-contained and stable, just an occasional one from me

[DanielT]

If you want to submit your changes yourself, then that would be ideal from my point of view, but I'll proceed if you don't have time.

You're welcome to include any changes I've made (they are under the MIT/Apache2 license after all) but I don't forsee getting much time at work to maintain this in the near future.

That's not necessarily an argument against merging your changes. Otherwise, by that logic, we should discard most of the pdb code, since the original authors at sentry.io are no longer maintaining it.
Meanwhile it seems I've been duplicating work you already did: I see you added support for S_FRAMEPROC, which I also did a few days ago. That shows that it would be much better to have one "definitive" crate with all of the features.

[michal-kapala]

@DanielT here's the pdb file i based my pr on way back if you want to experiment with my changes, comes from this repo

QuazalWV.zip

[DanielT]

As far as I can tell I've addressed the open points with the updated PR

[DanielT]

Hi, do you need anything else from me?
It's been a week, and I want to be sure you're not waiting for input from me.