disassembler

Feature type

Quality of life

Describe the feature

I would like to be able to use relative paths in the launcher settings file to point to x32dbg.exe and x64dbg.exe respectively. I've already tried editing the file manually and assuming my implementation (.\/\//) isn't wrong, the launcher seemingly refuses the use of relative paths.

My 2GHz Ryzen 7 laptop needs SEVERAL minutes to compile this 2.2MB autogenerated file. the reason is. because its full of spaguetti that the compiler tries to optimise without much luck because its based on binary logic operands and zillions of consecutive conditionals that don't even try to switch/case. So this is 45KLOC of code that almost nobody uses and will live better in extras.

Tl;dr: Use the workaround from https://github.com/pwndbg/pwndbg/pull/322/files only for broken gdb versions

It's currently always using mov rAX,[moffs] but if it fits in an i32, it's shorter to use mov rAX,[m] with a modrm byte.

The generated mov() methods would need to be updated. This is what the generated C# code looks like:

			if (dst.Value == Register.RAX && Bitness == 64 && src.IsDisplacementOnly) {
				code = Code.Mov_RAX_moffs64;

An extra check would need to be adde

pdgsd does not seem to process PUSH EBP very well, the p-code semantics show up as

    (unique,0x12f0,4) = COPY EBP
    ESP = INT_SUB ESP, 0x4
    (unique,0x12f0,4) = STORE ram[ESP]

which doesn't make sense. Last line should be STORE ram[ESP] = (unique,0x12f0,4)

the raw p-code will show you:

STORE (const,0x55fef11636d0,8) (register,ESP,4) (unique,0x1b50,4)

and the

We should create a corpus of tests to verify that CFG recovery is accurate and complete, and there are no regressions.