View mode: basic / threaded / horizontal-split · Log in · Help
September 22, 2012
It's always something
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...
September 22, 2012
Re: It's always something
On 9/22/12, Walter Bright <newshound2@digitalmars.com> wrote:
> Win64 exception

Maybe unrelated but I've read this recently (WindowProc):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633573%28v=vs.85%29.aspx

It says: "However, if your application runs on a 64-bit version of
Windows operating system or WOW64, you should be aware that a 64-bit
operating system handles uncaught exceptions differently based on its
64-bit processor architecture, exception architecture, and calling
convention. The following table.."

Apparently there's a hotfix for some x64 exception issues:
http://support.microsoft.com/kb/976038

http://stackoverflow.com/questions/2631452/64bit-exceptions-in-wndproc-silently-fail

We've been discussing recently in D.learn whether WndProc needs to be
nothrow. The exceptions are propagated back to WinMain on x32 but
maybe on x64 it needs to be nothrow to avoid x64 issues.
September 22, 2012
Re: It's always something
On 2012-09-22 09:19:33 +0000, Walter Bright <newshound2@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.fortin@michelf.ca
http://michelf.ca/
September 22, 2012
Re: It's always something
> 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.

You are right. I think it is a good thing Walter took the time 
out to write about this. In the absence of better documentation 
this post might come in handy (we can always use Google).
September 22, 2012
Re: It's always something
On 9/22/2012 6:37 AM, Michel Fortin wrote:
> 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.

Such trampolines are most often used so that a function can be easily "hot 
swapped" with another function. This may be a debugging feature of VS.

It took me so long to figure this one out because I had no idea that the MS 
linker would do this.

> 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.

I'll probably write a blog post about it eventually.
Top | Discussion index | About this forum | D home