Forum > Debugger
gdb and FpDebug
ccrause:
--- Quote from: Martin_fr on January 28, 2022, 01:10:54 pm ---Yes it is a "bug" or a "known issue".
The dis-assembler in FpDebug is not complete. It only shows partial asm.
--- End quote ---
To add to Martin's comment: Lazarus only requests disassembly of instructions within a certain range of the current instruction. This requires very little storage.
Because the x86 instruction set has variable length encoding, reverse disassembly (disassembling from current address to lower address) is non-deterministic and not perfromed. To improve this, one could search for the function containing the current instruction address and disassemble from the start of the current function.
In contrast, gdb performs a linear sweep of all the memory in an executable section. This gives better coverage, but requires processing time and storage.
Seenkao:
Благодарю за информацию!
Будем надеяться что FPDebug догонит и перегонит GDB в этом направлении! :D
google translate:
Thank you for the information!
Let's hope that FPDebug will catch up and overtake GDB in this direction! :D
440bx:
--- Quote from: Martin_fr on January 28, 2022, 01:10:54 pm ---The dis-assembler in FpDebug is not complete. It only shows partial asm.
--- End quote ---
Just curious... there are a number of open source dis-assemblers out there. Is there some reason (other than most, if not all, are written in C/C++) for not using one of them until the currently used dis-assembler (presumably written in Pascal) is complete ?
PascalDragon:
--- Quote from: 440bx on February 03, 2022, 11:34:11 am ---
--- Quote from: Martin_fr on January 28, 2022, 01:10:54 pm ---The dis-assembler in FpDebug is not complete. It only shows partial asm.
--- End quote ---
Just curious... there are a number of open source dis-assemblers out there. Is there some reason (other than most, if not all, are written in C/C++) for not using one of them until the currently used dis-assembler (presumably written in Pascal) is complete ?
--- End quote ---
The reason is not that the disassembler can't handle the code, but it's the one mentioned by ccrause. This problem would exist with a third party disassembler as well.
Marc:
One could iterate disassembling from a location n-1 and see if the disassemby ends on the current location. You may repeat that for a x amount of bytes before that location until you draw the conclusion that the previous instruction doesn't change anymore.
One could also start to disassemble n+16 bytes before the current location and discard the disassembled statements of the first 16 bytes (16 here is the assumed max size of a single instruction)
Marc
Navigation
[0] Message Index
[#] Next page
[*] Previous page