LibX86+disasm: Support x86-64 (attempt #2)

[supercomputer7]

This is a rebased branch of #13300.

Still need to look into the comments of what the original author had to do and fix to ensure it's ready for merging.

[Hendiadyoin1]

With #15467 around the corner we might be able to remove the 16 bit and 32 bit tables in a future PR.

[supercomputer7]

With #15467 around the corner we might be able to remove the 16 bit and 32 bit tables in a future PR.

I had a discussion about this quite a long time ago, but it might be valuable to keep 16 bit and 32 bit support for the x86 platform, especially because I don't want the Kernel to have such code to emulate BIOS calls, but to let userspace to deal with this. This PR also raises the question - since aarch64 port is quite close, what will happen then? Will UserspaceEmulator will need a LibAArch64 now? that seems tedious to me. Besides finding memory leaks (as far as I remember this is the purpose of this program) what else it does for us currently?

[Hendiadyoin1]

It also detects accesses to out of bounds memory regions, as well as some UB checks

[ADKaster]

It's the equivalent of the memcheck tool from valgrind. With the option to add other tools in the future.

I think we should at least have it working on one architecture, I don't think it's a requirement to port it to every arch. But possibly, yes. Technically with this we could maybe run x86_64 serenity userspace apps on aarch64 serenity, like userspace emulation in qemu.

[supercomputer7]

It's the equivalent of the memcheck tool from valgrind. With the option to add other tools in the future.

I think we should at least have it working on one architecture, I don't think it's a requirement to port it to every arch. But possibly, yes. Technically with this we could maybe run x86_64 serenity userspace apps on aarch64 serenity, like userspace emulation in qemu.

Although the idea of running x86-64 binaries on aarch64 CPU sounds quite nice, I'd advocate against it unless there's a proper way to contain the x86-64 userland somehow so we don't have a mess. Something like simple chroot functionality can do that.

Anyway, I need to find time to finish this. There's one comment left to address in this PR, but I didn't look in the old PR this is based upon, so I might need to work on this a bit more.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[awesomekling]

Let's just bring this in and continue iterating in-tree.