".gnu_debuglink" ( <= google this name) section in the exe.
Yes, I had seen that but, only paid enough attention to it to determine FPC does not emit one.
It was therefore implemented the same way in FpDebug. (search for "ReadGnuDebugLinkSection")
if I am understanding you correctly, it seems that FpDebug's ultimate goal is not just being a debugger for FPC but also one that could be used for any other GNU language. Is my impression correct ?
If I understand you correct, you start out on an unknown exe. No source, no debug info.
could be either but, in either case the program's goal is to generate very accurate information about the code being analyzed.
You disassemble, you analyse, and you take guesses.
Correct. The basic idea is to validate the consequences of the guesses made by verifying consistency among them.
And then you add that as dwarf, and let the user run it in a debugger, and the user can then inspect the data, and amend the guesses.
I am being very ambitious. One of the reasons I decided to try a new approach is because I'd like the program to do _all_ the work. Yes, that's quite likely unreasonable but, there is no doubt in my mind that the results obtained by IDA Pro (I use that as the benchmark) can be _greatly_ surpassed.
My first "cut" will be fully static. There won't even be a mechanism for the user to provide information/guesses to the analytical engine. Once I have figured out the cases where it is truly impossible for the engine to generate the info then, I'll give a "door" for a user to give some input. Of course, there are cases where it is unavoidable to have the user create decent variable names and provide those to the analytical engine but, even there, I want the analysis to be so thorough and complete that, at least in some cases, the engine will be able to generate genuinely informative variable names which, of course, will become part of the debugging symbols applicable to the program.
Now your plan is to write debug info in an existing format, and use an existing debugger.
I probably won't use an existing debugger because, doing so means I inherit all its limitations. Once I've seen what the analytical engine can figure out then I can write a debugger tailored specifically to enable a human being to figure out what the analytical engine couldn't.
Within FpDebug you have access to controlling an exe in memory (lots of it work without debug info, some wants debug info ... but that does not need to come from a file. (And if/where FpDebug does not have proper separation, that could/should probably be fixed anyhow).
currently, I use FpDebug, VS Studio's debugger and IDA Pro's debugger to acquire knowledge in the various areas needed (such as acquiring a reasonably solid understanding of DWARF.)
One of the downsides of FpDebug (and GDB) which I have mentioned in the past is, neither is really convenient when debugging at the assembly level and, while I don't need that feature right now, as the project progresses, solid assembly code management will become very important (IDA Pro is quite good at that... I want to go beyond that.)
All the "debugging info" either in form of guesses or verified facts will be stored in memory. The program will need a _lot_ of memory.
Thank you for all those thoughts... no doubt I'll have more questions for you as the project advances (it will be slow... probably as long as six months before I have a "proof of concept" I deem satisfactory.)
Stated succinctly, I want to develop a disassembler/debugger/analyzer that is noticeably superior, more capable and easier to use than any other offering at this time. A tall order. That said, I have no intention to make it a tool to reverse engineer malware. It's purpose will be to be used on "normal" software (such as Windows system dlls and/or programs.)