[UVTD] Preferred organization for PDB/DWARF readers and shared generators

[tc-imba]

Current progress

I have a working branch that builds UVTD on Linux and generates member layouts, Sol bindings, and primary Itanium vtables from LLVM DWARF while preserving the existing Windows raw_pdb path; I have not opened a PR yet.

Context

The existing Windows UVTD code combines metadata extraction and generated-file emission in several places. To reuse the established output format from Linux, the current prototype makes the following targeted extractions:

Symbols.hpp
  platform-neutral metadata types -> TypeMetadata.hpp
  Windows Symbols/raw_pdb class    -> remains in Symbols.hpp

MemberVarsDumper.cpp
  PDB member extraction            -> remains in MemberVarsDumper
  generate_files()                 -> MemberVarsOutputGenerator

VTableDumper.cpp
  PDB vtable extraction            -> remains in VTableDumper
  method-key helpers               -> VTableMethodNames
  generate_files()/cleanup         -> VTableOutputGenerator

The resulting flow is:

Windows PDB reader  --\
                      -> TypeContainer -> shared output generators
Linux DWARF reader  --/

This keeps one implementation of the member, vtable, virtual-integration, and Sol output formats. It also makes the diff look larger because Git shows moved code as deletions from the original Windows files and additions to new shared files. For example, the Symbols class itself remains unchanged; only its platform-neutral data structures move out of the PDB-heavy header.

Questions

Which organization would you prefer for an eventual PR?

1. Keep the current shared pipeline: separate PDB and DWARF readers populate a common TypeContainer, followed by shared generators. This moves existing output code, but minimizes duplicated behavior and makes Windows/Linux output consistency testable.

2. Minimize movement in the existing Windows files and implement Linux-specific generation separately. This produces a smaller-looking diff, but duplicates member/vtable output and method-naming logic that could drift later.

3. Introduce a deeper reader abstraction and reorganize the source tree, for example:

   UVTD/src/Metadata/Windows/
   UVTD/src/Metadata/Linux/
   UVTD/src/Generators/
   

   This gives the clearest separation but would move considerably more existing code and seems contrary to a minimum-change PR.

More specifically:

• Is extracting the platform-neutral structures from Symbols.hpp into a small shared header acceptable, or would you prefer keeping Symbols.hpp as the common type header with platform guards around the raw-PDB class?
• Is moving only generate_files() out of MemberVarsDumper and VTableDumper the preferred boundary, or should the existing Windows classes remain completely untouched?
• Would you prefer new files to remain in the current flat UVTD/include/UVTD and UVTD/src layout, or should platform readers and shared generators have subdirectories?

My preference is the first option because it keeps platform-specific code limited to metadata extraction while using the existing Windows emitter as the single source of truth, but I would like to align the code layout with maintainer expectations before cleaning the branch and opening a PR.

[wildcherry2]

#1 sounds better to me, but it would be better to get some input from the people who know that code base better than I do.

Also, it seems that Palworld is wanting people to immediately see Linux support for UE4SS. It's great to have more people helping out, especially since we only have 1 maintainer that natively uses Linux and can do development for it, but stability is crucial for this kind of project, even more so than most other kinds of software development projects, meaning that we can't rush this and expect a stable, extensible, maintainable result in the end. I like this kind of post because it shows that you're trying to think things through and make a plan that can integrate with the project, while others have been just submitting massive, rushed, monolithic AI-generated changes without any thought or discussion over the past several months. In other words, you're on the right track. And while I get that there is demand for this, which encourages just getting a result out as quickly as possible, we can hurry, but not rush, if that makes any sense. I would encourage any new people that want to work on Linux support to work together so that efforts aren't duplicated and code gets more scrutiny. We do have a discord (https://discord.com/invite/7qhRGHF9Tt) that can be used for collaboration and communicating with other maintainers and contributors.

It's worth noting that I'm working on something to completely replace our need for UVTD (at least for the way it's being used now) that code gens off of each version of the unreal source code, and will be able to generate a more complete representation of the engine types to replace the current UEPseudo, but it will take a little while to do it right (https://github.com/wildcherry2/UEMeta). It should also be able to handle Linux-side codegen at the same time. I'd say its around 35% of the way through though, as I've been too busy over the last few weeks to work on it

[tc-imba]

I've actually already built a working version for Palworld with GPT-5.6. It's pretty dirty, but the Palworld folks might be able to use it as a stopgap. I'm planning to put it out as a test release while I work on a proper port of UE4SS to Linux.

I'm an AI game developer (UE/Godot) working across native Windows, Linux, and macOS. A working Linux port is hard, but getting it to production quality is even harder. There are so many Linux distributions, and things can behave very differently across them. I'd be glad to join your Discord (my ID is liuyh615) to discuss further.

I've read through the core of UVTD and looked into it more deeply. The current approach in UVTD relies on a platform-dependent Visual Studio tool, which isn't portable to Linux or macOS. My DWARF dumper is built on LLVM and its tooling, and LLVM can run on Windows, Linux, and macOS to generate the files for any of those targets. It looks like your new UEMeta project uses a similar idea, but it isn't well documented yet, so I'll need some time to understand it.