Home > Archive > Compilers > February 2008 > need ideas on how to debug code generator
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
need ideas on how to debug code generator
|
|
| Ram Bhamidipaty 2008-02-25, 7:22 pm |
| Hi,
I have a small code generator - for 32 bit x86 machines, unfortunately it
has some bugs :-(. My problem is that the generated code fails
"once in a while" sometimes it can go for 20-40 iterations before failing.
I have a collection of test cases where I verify the correctness of
various simple constructs -- things like load, store, add, sub, etc.
Those all pass.
The test case in question generates a code sequence of about 400 bytes. It
fails by seg faulting, unfortunately gdb is unable to print out a
useful stack trace.
What are some techniques that people have used for debugging code
generators?
-Ram
| |
| Thomas Have 2008-02-25, 7:22 pm |
| Hello,
Ram Bhamidipaty wrote:
> The test case in question generates a code sequence of about 400 bytes. It
> fails by seg faulting, unfortunately gdb is unable to print out a
> useful stack trace.
On the windows platform, perhaps windbg (google debugging tools for
windows) could be of use. Especially, I think that adplus in hang mode
could be helpfull. (Windbg has a rather steep learning curve
though. See below also :)).
> What are some techniques that people have used for debugging code
> generators?
Unfortunately I haven't had the pleasure of debugging generated x86
code (but other generators).
Kind regards,
Thomas *thomash* Have.
| |
|
| Ram Bhamidipaty schrieb:
>
> What are some techniques that people have used for debugging code
> generators?
I did a codegenerator for the MIPS4 architecture a year ago. What I
did for debugging was to write a simple emulator for the instruction
set. For MIPS this was easy to do because the instructions are
trivial to decode and simulate. With a bit of work the same can be
done for x86 as well.
My debugging jobs have always been easy because my generated code was
"only" executing rendering loops for graphics. The readable and
writeable memory regions were well defined, so catching page-faults
has been easy.
If you write such a simple emulator, set aside some memory and record
the CPU state for each instruction. This makes it easy to trace back
in time and _exactly_ find out the conditions that caused the page
fault.
Best debugging tool I ever had. The Watcom Debugger that I used 10
years ago had a similar feature. I wonder why we don't have such
useful things built in our tools anymore...
Nils
| |
| Bartc 2008-02-27, 10:22 pm |
| Ram Bhamidipaty wrote:
> I have a small code generator - for 32 bit x86 machines,
> unfortunately it has some bugs :-(. My problem is that the generated
> code fails "once in a while" sometimes it can go for 20-40 iterations
> before failing.
>
> I have a collection of test cases where I verify the correctness of
> various simple constructs -- things like load, store, add, sub, etc.
> Those all pass.
>
> The test case in question generates a code sequence of about 400
> bytes. It fails by seg faulting, unfortunately gdb is unable to
> print out a useful stack trace.
Do you have a listing of the x86 output? Then just debug as though it
was of piece of assembly code.
The correctness of individual instructions does not stop you having a
memory fault which can be due to incorrect contents of registers or
memory.
So look carefully at data allocations too. And double-check a
disassembly of your code to see if that's what you had in mind. Are
you sure your debugger can't tell which instruction it's failing on?
--
Bart
| |
| Joel Yliluoma 2008-02-28, 10:25 pm |
| On Sun, 24 Feb 2008 21:47:50 -0800, Ram Bhamidipaty wrote:
> Hi,
>
> I have a small code generator - for 32 bit x86 machines, unfortunately it
> has some bugs :-(. My problem is that the generated code fails
> "once in a while" sometimes it can go for 20-40 iterations before failing.
>
> I have a collection of test cases where I verify the correctness of
> various simple constructs -- things like load, store, add, sub, etc.
> Those all pass.
>
> The test case in question generates a code sequence of about 400 bytes. It
> fails by seg faulting, unfortunately gdb is unable to print out a
> useful stack trace.
>
> What are some techniques that people have used for debugging code
> generators?
I am assuming you use a combination of a mprotect(..., PROT_EXEC)
and a cast into a function pointer to run generated code.
GDB can do generated code debugging tolerably, if you use a combination
of "display /i $pc", "stepi" and "disassemble <address1> <address2>".
When the program segfaults, you'll get the address and the exact
opcode that caused the segfault, and you can use disassemble to find
out about the surrounding context. Additionally, you can use "display
/i $registername" and "stepi" to singlestep through the generated
program.
((Reposting, because I did not receive a moderation queuing notification.))
--
Joel Yliluoma - http://iki.fi/bisqwit/
|
|
|
|
|