Hi
On 64-bit Windows the lack of proper stack unwinding support causes
crashes in JIT code generated by LLVM. I was wondering if it is
possible to ask LLVM to generate 32-bit code - and if that would work
within a 64-bit Windows application - i.e. the rest of the system will
be 64-bit only the generated code will be 32-bit. I was also wondering
if this would allow me to workaround the crashes due to stack
unwinding problems.
Thanks and Regards
Dibyendu
Hi Dibyendu,
I’m not familiar with Windows at all, but I assume you can’t mix 64-bit and 32-bit code in the one process.
Reid - Are we generating correct call frame information for windows yet (https://llvm.org/PR24233) ? If so, I think Dibyendu would just have to override registerEHFrames/deregisterEHFrames and have them call RtlInstallFunctionTableCallback/RtlAddFunctionTable, right?
You actually can mix 32 and 64 bit code in the same Windows process, but only with great effort. Fixing PR24233 is probably easier. 
We know how to generate the info, but we still have to get it registered…
Thanks Reid!
Apologies for re-asking - I may be missing something obvious, but is the registration something Dibyendu can do himself in registerEHFrame/deregisterEHFrames?
It looks like registerEHFrames/deregisterEHFrames is implemented in RuntimeDyldCOFFX86_64, but it may just have been copy/pasted from somewhere else - I have no idea whether it works.
How does that work? Some syscall that you make to switch modes and
jump to a particular location?
Tim.
I've investigated several failures that my buildbots detected but when I figured out which revisions caused the failures they weren't on any blame lists. Thus the developer has no clue they broke anything until I contact them.
It appears this happens when (for instance) one of the test cases in projects/test-suite is updated and causes a failure. Such a revision also won't kick off a new test cycle.
Should the bots be including their test cases in determining blame lists and when to run or was this left off on purpose?
Hi Bill,
This is a known issue, and maybe we should look into that, now that
the two other critical issues (silent master and ignoring exceptions)
are done. Another repository that has the same effect is Zorg (the bot
infrastructure).
Galina,
First, the easy one: I think we should include Zorg on *all* monitors.
The not so easy one: I believe this is just a matter of creating a
monitor based on the test-suite, and put all test-suite bots checking
on it too. But from what I remember, you can only create lists of
monitors, not necessarily collate them per bot. Is that true?
cheers,
--renato
No, you really can't do this in any general purpose fashion. You can do some weird things that allow you to use 32 bit pointers while using the full 64 bit ISA, but that won't solve your problem (you still need unwind data).
The way to address the lack of stack unwinding is by adding capabilities to your runtime that use one of RtlAddFunctionTable, RtlAddGrowableFunctionTable, AddVectoredExceptionHandler, or RtlInstallFunctionTableCallback. I used to know a lot (way too much) about this stuff, but my brain has mercifully garbage collected most of it. You could try looking through some of my old MSDN blog found here: http://blogs.msdn.com/b/freik/archive/tags/x64+abi+info/ but it’s not going to be too informative, because most of it was written before I was involved with JIT compilation. I'd be happy to try to answer questions as they come up...
-Kev
Hi,
I've had this problem on a compiler-rt change too. It was on the clang-cmake-mips builder earlier this week.
Hello Bill, Daniel,
Could you point me to the exact build and tell me the correct revision to blame, please?
Most likely, this means that your bot defines wrong dependencies. I can look in to this, once I’ll learn the details.
Thanks
Galina
Hi Galina,
The failing build was http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/10220 and the commit that caused it was ‘r251331 [compiler-rt] Fix ptrace interceptor for aarch64’.
Adhemerval,
Can you have a look?
Hi Daniel,
Your buildbot should really be in the _get_sanitizer_builders() list,
instead of the _get_clang_fast_builders(), because the former monitors
compiler-rt changes, while the latter doesn't.
This would have made Adhemerval aware that his commit broke that bot.
cheers,
--renato
I already have a fix for the problem, we just have some definitions in odd places. I XFAIL'd it while I was in the US but I'll commit the fix shortly.
Thanks Daniel!
--renato
In my case it is the power lnt bots (both of them) not being dependent on the test suite.