Debugging custom-generated machine code
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
Hi everyone.
I'm building a compiler which generates directly Intel x86 machine code. From time to time I need to debug the code which I have generated. Unfortunately GDB is hard to use in this respect (very inconvenient, I have to type and retype a lot of things).
I tried DevC++ and it debugs pretty well the C-code of the compiler, but I cannot figure out how to debug the machine code that I have generated.
Is there such functionality in DevC++? I saw there is a CPU dissassemle window, but did not manage to use it for debugging.
My dream-debugger is like the one in Delphi -- I want to be able to easily jump into CPU-debugging mode and debug instruction by instruction. And I want to do this to code for which there is no any source.
Best regards.
Lhogho
(I searched the forum and checked the DevC++ site, but did not find any info that can indicate whether such functionality exists in DevC++)
> As a JIT compiler ...
I see, sorry, yes you did mention that before.
> Lhogho is Open Source ...
Ok, a project name and a link help your credibility.
> I came here looking for help, and now I'm going away
> as an accused or suspected malware-writer.
I take it back. However, I would suggest that it was cautious scepticism and not intended as an insult.
> Being my last post and last visit here,...
Well you just established your credibility and then left. Why were you not up-front in teh first instance. Besides I have a possible solution:
For debug purposes, why not just write the raw machine code to a file, disassemble it, and then assemble the disassembly to a stand-alone executable and debug that. That will test your code generation and enable you to debug it normally.
Clifford
> I tried DevC++ and it debugs pretty well the C-code of the compiler
Really!? You are easily pleased - it sucks.
Dev-C++ merely provides a thin wrapper around the bost basic GDB functionality, and it is buggy.
A better solution is to use Insight - a stand alone symbolic debugger. It is also GDB based, but with a Tcl GUI wrapper, and it exposed far more GDB functionality (as well as having a command window). It will display source and assembly simultaneously. If you use -gdwarf3 option for gas (the GNU Assembler) you can debug as the source level rather than the object code disassembly level. If you use the inline assembler within C or C++, you get that in any case.
Get the MinGW distributeion of Insight at: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82725
An even better alternative is to use Microsoft VC++2008 Express Edition. The VC++ debugger is second to none (including Borland's).
Clifford
"Really!? You are easily pleased."
Actually I use GDB envoked from XEMACS for my C-debugging. I tried Dev-C++ only to see whether I can debug at lower-than-C level.
I'm now trying to build Insight under Cygwin/XP SP2 and under Mandriva -- the linker keeps crying "Error 1". On another mashine I'm also testing the prebuilt Insight binary.
Most likely "Microsoft VC++2008 Express Edition" is not an option, unless I can use it under Linux.
Anyway, thanks for the Insight/insight tips...
Just tried Insight. I did not manage to debug custom generated assembly code. When I exited the C-generated code and entered directly generated code the disassembly window just went blank with a short note at the top saying to select a function to disassemble. However, there is no corresponding function that I can select.
When compiling C-code there is no problem -- I can view both the C and the asm and both of them mixed.
The code which I genarate is via directly writing the machine instructions in memory - I'm not inlining ASM statements. I need this for the JIT-compiling mode of my compiler -- it compiles into memory and then executes the compiled code.
I will try Insight a bit longer, though I'm a little bit pessimistic now.
As for the Dev-C++, I still do not know whether it can help me.
In the worst case I will continue to use GDB, although it causes me a pain in the a**.
> I'm now trying to build Insight under Cygwin/XP SP2
I suggest that you are on your own if you are attempting to build Insight from source. It is not within the scope on this forum. However, the linker may throw Error 1, but I doubt whether that is the only diagnostic message. You do need to have installed all its dependencies. Insight used Tcl/Tk for example.
> Most likely "Microsoft VC++2008 Express Edition" is not an option, unless I can use it under Linux.
As this is the Bloodshed forum, that too is not within the scope of this forum. But you can't.
> When I exited the C-generated code and entered directly generated code the
> disassembly window just went blank with a short note at the top saying to
> select a function to disassemble.
That is because the on-the-fly generated code has no associated debug information or symbol table. I cannot remember but does it not show the disassembly if you select "ASM" only display mode?
> As for the Dev-C++, I still do not know whether it can help me.
Probably not because a) ffrom a debug point of view it is merely a GDB wrapper (as is Insight) so if GDB is no use, then neither are these. and b) it does not run in Linux and you gave that as a reason for not using MSVC++.
> In the worst case I will continue to use GDB, although it
> causes me a pain in the a*
Insight is GDB, but perhaps only slightly less of a pain. The command console in Insight is the GDB command line.
Clifford
> so if GDB is no use
I can use GDB, but it gets extremely uncomfortable when debugging sourceless machine code.
For example, to find where to set a breakpoint I first need to disassemble the code. To do this I have to type:
disass 0x??????? 0x????????
where ????? are some hex addresses.
then I have to scroll until I find the place (if not, then I have to disassemble but with a wider address range)
When I find the break point I have to type:
b *0x???????
That is why using GDB is a pain. 80% of the debugging time is spent in typing addresses, and more addresses, and yet more addresses. Needless to say, for every debug session these addresses are different.
I was curious whether Dev-C++ can help me to eliminate all this waste of time. I don't need something which is not in GDB, I just need it in a more comfortable way.
I'm sorry if my posts tend to be off-topic, but I'm still looking for at least a "yes-no" answer in respect to Dev C++.
Thanks, cpns, for your replies. Much appreciated.
> The code which I genarate is via directly
> writing the machine instructions in memory
You mean at runtime!? That being the case I cannot help you any further. You may have a legitimate reason for doing this, but is also smells like a malware technique. Even if it is legitimate, I would not have your code running on my computer!
My suggestion is if you want to generate code on the fly is that you generate assembly code to a file, invoke an assembler/linker to build it then execute that.
Clifford
> You mean at runtime!? ...
> You may have a legitimate reason for doing this
As a JIT compiler this is exactly what Lhogho is supposed to do. Its primary and sole purpose is to compile into memory and then execute the code.
> but is also smells like a malware technique. ...
> Even if it is legitimate, I would not have your
> code running on my computer!
I'm sorry to hear this, Clifford. Lhogho is Open Source, so anyone can check its sources to make sure there is no any harm hidden in there. And because it is a SourceForge-hosted project, I thought that I'd first look for a debugger among other SF-hosted projects.
I came here looking for help, and now I'm going away as an accused or suspected malware-writer.
Being my last post and last visit here, I wish all the best to the Dev-C++ developers and all its users.
Keep smiling.
Lhogho
http://lhogho.sourceforge.net