[a7c4fc9 or earlier] VM error messages missing

[Rachael]

It is.

And CMake can be set up to properly generate PDB's without the in-line trouble - you just can't use the normal RelWithDebInfo to do it.

It's ultimately a linker flag - I'm guessing exactly the parameter dpJudas posted.

[dpJudas]

Yeah I was talking about the /pdbstripped:foobar.pdb linker flag. It generates a 8 MB large PDB.

But hey, it was just a suggestion. If you'd rather parse the map file and apply the relocated base address to that I'm fine with that too, as long I'm not the one coding it.

[Graf Zahl]

How large is that PDB when being zipped? The stripped map file is also 3 MB, but compresses quite well.

[dpJudas]

Zipped reduces it from 8780 KB to 1872 KB.

[Graf Zahl]

Ok. So it doesn't compress as nicely as the map file but that should be manageable and is definitely worth it for better bug reporting capabilities.

[dpJudas]

I pushed the code required to write out the native call stack too - if nothing else, then for future reference.

[phantombeta]

I've coded line numbers for the JIT stack trace. Not sure if I should PR it, as I'm not sure if this is a good/correct way to do it, but it seems to work perfectly.
The only issue with the callstack now is that the first line has no line number, for some reason. And due to the thrown exception, it prints the proper first line with its correct line number after the JIT stack trace. That's probably something I can't fix, though - it was already like that before I added the line numbers.


Here's a screenshot of the issue.

[Graf Zahl]

Actually, this looks like you get two stack traces being printed at the same time and getting mixed up. This will probably require some change to the VM side of exception handling - it may be better to run the JIT code completely outside the VM's exception guards - or at least let these guards do nothing when the JIT is enabled.

[phantombeta]

Should I make a pull request for it? Or would you rather take a look at the code first?
As for the stack trace weirdness, it's going through the JIT functions in the stack and outputting them into the stacktrace variable, which the exception guards later use. So basically it writes the JIT functions' stack trace, then the VM's normal stack trace. This could be fixed by not making it print the function that caused the VM abort in the exception guard code and fixing the first line not having the line number in the JIT's stack trace, but I don't know how hard that would be.

[Rachael]

Make a pull request, please. The pull request is the best way to review the code in the first place. It also helps to keep everything organized. You will get feedback there, if it's needed. If it "already works" (tm), though, it's more likely to be accepted as-is, unless there's something glaringly wrong with the code.

[phantombeta]

Made a PR. Had to fix some merge conflicts and remove a few debug lines I forgot about.
After testing it with dpJudas' latest commit, I'd say something should be done to it, as it's printing out way too much stuff. It's including stuff that isn't even necessary or useful for debugging, and it's just waaaaaay too long right now. Perhaps the stack trace should only be this verbose at the highest developer mode settings.

[dpJudas]

Yes, the native frames probably shouldn't be printed - I just did that to illustrate that we can print the full call stack if we want to.

[dpJudas]

The only issue with the callstack now is that the first line has no line number, for some reason.

This happens because EmitThrowExceptionLabel pushes all ThrowException calls to the end of the function.

[phantombeta]

I'm pretty sure this can be closed by now.