On 2012-09-22 09:19:33 +0000, Walter Bright <newshou...@digitalmars.com> said:
I just spent about 3 hours tracking down the strangest problem. Win64
exception handling would work fine, but when I'd turn on -g, it would
crash.
At first I thought "I'm generating a bad object file with -g." But
since dmd isn't emitting any Win64 symbolic debug info, a check shows
the object files are the same with and without -g.
So it must be something with linking? I spent a lot of time going over
and over the relocation fixups (could there be a missing offset?), but
could find nothing wrong.
Instrumenting the Phobos eh handler code, it seems my handler table was
pointing off into la-la land when linking with /DEBUG. What the hell?
I thought I'd dump the first byte of where it was pointing to, and look
in the assembler output and see if that byte was at a predictable
offset from where it was supposed to be. The actual function started
with C3, but the handler table pointed to E9. There was no E9 in the
object file. What the hell?
Finally, it dawned on me. E9 is a JMP instruction! For some reason, the
Microsoft linker inserts a bunch of trampolines when linking for debug.
The fix, then, was for the eh handler to look and see if the handler
table is pointing to an E9, and if so, then adjust the function address
to be where ever the JMP goes.
And so it goes...
But there should be a reason why there's a jump there. Have you found
it? If you're just bypassing the jump you might be breaking something
else. For instance, this jump table might have been a mean to allow the
debugger to more easily break on exceptions. Or it might be something
else, I don't know, but it's likely there's a reason.
You should keep a record of those anomalies somewhere, it might prove
useful as a starting point to investigating problems future problems
that might arise.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/