The dis-assembler in FpDebug is not complete. It only shows partial asm.
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 ?
First of all, the issue of only disassembling small part (i.e. not backwards, no scroll) => that is not the actual disassemble code. That is the framework surrounding it. Even when using gdb to disassemble, the backward/scroll sub-address-range calculations are done by the IDE (actually our gdb wrapper code).
Then again, there are other issues, that need fixing too (support for some missing mnemonics).
As for the actual question,
the short answer: There may be some reasons.
(Not sure if there always had been, but in the meantime there may be...)
Most of that dis-ass code was written long ago. I do not know the reasons, why (back then) it was done that way (I was not working on fpdebug then, maybe not even aware of the existence of Lazarus). If you go back on the git history, maybe the logs will tell some bits. But I wouldn't expect too much.
After that, I guess it has just been kept as it is.
Eventually however some changes have been made. And those I referred to above "There may be some reasons".
There are cases, when the debugger makes decisions based on the next asm statement. E.g. when stepping, it needs to know if there is a call or ret. But also some other decisions (looking at various asm instructions).
Originally, the code for single-stepping would take the disassembled asm as text, and parse the text. Now, the dis-assembler returns an enum, representing the statement. That saves the unnecessary creation of a string, and the subsequent parsing of that string.
From where we are now (the above), both paths are open. But I am not sure, if switching to external would be more beneficial.
For any comparison, we have to take out any functionality that goes on top of the actual translation. Translation here being to take a byte sequence "85 C0" and translate it into the text "test eax,eax".
- As for the question: "Maybe there is an existing dis-assembler that can do some of the other stuff needed?"
Unlikely (but feel free to give examples, if you know of any).
Why unlikely? Well, for any of this the dis-ass needs input from us => We need to read the memory of the target process (the external lib would not have access to the debugged process). We then hand over the byte-sequence. For other tasks, we would need to supply additional data (such as access to debug info, and what we want the dis-ass to do with that info) and that would return some of the burden to us. Also, we already have (pre-)parsed debug info (in our own set of classes and structures). The external code would have to parse it again => adding extra resource usage (cpu and mem). Debugging an app, is as it stands already a memory hungry operation.
So, if we compare the remaining functionality (
just translating bytes into mnemonics), then we get:
- Maybe reduce long time maintenance?
Depends, how much work (e.g. C to pas) there will be for each update of the external code. Also relies on continuous existence of the external project.
- As for short term effects: Probably - None -(my guess only).
The time to initially include the 3rd party code, would probably be at least what would be required to fix (most of) the missing bits in our own code.
- Depending on the above (first bullet): Less work for bug fixes.
But if they will be slower or faster is in the hands of someone else. (We do have that with GDB, bug fixes can take for-ever / still waiting => Ok, bug fixes on our own list can have the same wait...)
- More work, adding our own features on top.
We must adhere to whatever API the code uses (and convert any input data we have). We must also parse the result, if we want to add further data, decoration, functionality.
If we add support for more CPU targets to FpDebug, the decision can be reviewed for each such target. If there is no pre-existing pascal code for dis-assembling, the cost/benefit analysis changes.
Though, personally I think, if a Pascal version can be created at low cost (e.g. automatic translation for another language to Pascal) then that should probably be preferred. At least if the results of the pro/contra evaluation are otherwise a close call...