EpicGamesExt
Linux build support
I started doing this but i figured it'd be a good idea to ask here before I get too deep in it. Are there any plans to support Linux as an official build target? I'm working slowly on my fork and I've finally got metadesk kinda running (tho it's still segfaulting) so I'm happy to make a PR if/when I get it fully running.
The readme states
The RAD Debugger is a native, user-mode, multi-process, graphical debugger. It currently only supports local-machine Windows x64 debugging with PDBs, with plans to expand and port in the future. In the future we'll expand to also support native Linux debugging and DWARF debug info.
Yeah, Linux support is the next big thing on our roadmap after the initial alpha phase of testing, bullet-proofing, & cleanup on the Windows side.
Getting the metaprogram running on Linux (and getting a build.sh which can build things in the same way as the build.bat) would be a great first step; this is only held back currently by the staleness of the Linux backend implementation in os/core/linux. That should implement the same API as the implementation in os/core/win32. Then, it needs to be duplicated in the metagen layer (which has a separate, older copy of the OS layer, to prevent being destabilized from changes in the main codebase OS layer). At that point, the metaprogram should be up and running on Linux.
@ErrorOnUsername My guess of the segfault on your branch (without testing anything) is
https://github.com/ErrorOnUsername/raddebugger/commit/fc0c2143ddfd7e6b1414ce12793e0b23c7321f62#diff-e597e9a7df6027bc72185929f8885b87010da6a82543afeadd49170b4bee437dL902
returns 0 may cause some other code not allocating/reserving memory correctly.
would it still be using that even though os_large_pages_enabled returns false? (edit: tested in the debugger and os_large_page_size doesn't get hit, so the investigation continues unfortunately)
Small update: I was able to get metagen running and I added a build.sh! I'm fairly certain that segfault was just some weird difference in the process memory layout on linux, but I'm not 100% on that.
Could these changes be upstreamed? I've been working on a linux port as well for fun/learning, but if it would benefit the project it could make sense to consolidate the different efforts. But if rad is just working on their own port internally, that makes sense too. Edit: I just read more carefully that you were already planning on submitting a pr for this, nvm
@IvyTheGreat01 maybe you can coordinate with @ErrorOnUsername and help out over at their branch if agreed?
We'll be carefully putting together the Linux port a bit later, but honestly the more research & reference implementations we have that do working Linux ports of parts of the codebase, the better, because such things can come in handy when we're doing the "official" one later, so any work that is spent doing such things will be greatly appreciated & will not go to waste (although I think many things have to be solidified & made more robust before we start having actual ports formally coming into the codebase).
Given that this is a highly-anticipated part of the project, I've outlined the main porting tasks that are necessary for local x64 Linux debugging here.
