<div dir="ltr">Hi Bjoern,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I'm trying to make exceptions run. I have an Object file with a function, throwing a 1 and a second function which should catch the 1. Normal JITTING under Windows showed me, that I have an unresolved reference to the virtual table of type_info. Some experiments later I was able to load "msvcrt.lib" as an archive and could resolve the reference. Nice - but than "??_Etype_info@@UEAPEAXI@Z" was missing too. Ufff! I decided to ignore this. Because, when I try to load every .lib and .obj provided by Visual Studio, I get an assertion failure with "Relocation type not implemented yet!". </blockquote><div><br></div><div>RuntimeDyldCOFF is missing a lot of relocation support. We need a COFF expert to fix that and unfortunately I'm not one.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I decided to have a look at "_CxxThrowException". I inserted my own function for the JIT and had a look at the parameters. I got two of them. The first was the address of the Exception-Object, which was correct. The second is the address for the "_ThrowInfo". This address was valid too, but all its members - except from attributes - are null. So I can't throw this Exception. I tried to pass the address of typeid(1) to it, or modificate the call. Nothing helped. </blockquote><div><br></div><div>I don't know windows exception handling well, but if it's anything like DWARF EH then I'd be inclined to blame the missing relocations/fixups -- the _ThrowInfo struct (or whatever data-source ultimately populates it) probably isn't being fixed up.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I have no clue and no idea anymore. So... Do you have an idea? </blockquote></div><div><br></div><div>I'm afraid I don't personally. We need some windows linker / system experts to take an interest in the JIT.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Back then I tried to solve a related issue: SEH exceptions thrown from code loaded with RuntimeDyld had to be caught in statically compiled code. It turned out Windows explicitly prohibits this. I got in touch with Microsoft people and IIRC it's due to security concerns.</blockquote><div><br></div><div>Stefan -- That's an interesting restriction. :/</div><div>Does it prohibit exceptions thrown in JIT'd code from being caught also in JIT'd code, or does it only apply if an exception crosses the boundary back into statically compiled code?</div><div>Do you know how they were enforcing that?</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:37 PM, Stefan Gränitz via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p><span class="">
      </span></p><blockquote type="cite"><font face="sans-serif" size="2">I tried
          loading the "msvcrt.lib"
          as a archive. That was... a bad idea! I get a Exception while
          loading:</font>
        <br>
        <font face="sans-serif" size="2">Assertion failed:
          ((int64_t)Result <=
          INT32_MAX) && "Relocation overflow", file
          \lib\executionengine\<wbr>runtimedyld\Targets/<wbr>RuntimeDyldCOFFX86_64.h,
          line 81</font></blockquote>
      It's a limitation of the COFF/PE format and unrelated to
      exceptions. This patch explains it and shows a workaround:<br>
<a class="m_8479653584311911203moz-txt-link-freetext" href="https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f" target="_blank">https://github.com/<wbr>weliveindetail/pj-llvm/commit/<wbr>97cd336d458ae9c73232d1b539ceef<wbr>cdb2f5eb0f</a><span class=""><br>
      <br>
      <blockquote type="cite"><font face="sans-serif" size="2">Is there
          no hope left?</font></blockquote></span>
      Well at least I am not aware of a solution.<br>
      <br>
      Am 28.09.17 um 16:04 schrieb <a class="m_8479653584311911203moz-txt-link-abbreviated" href="mailto:bjoern.gaier@horiba.com" target="_blank">bjoern.gaier@horiba.com</a>:<br>
    <p></p><div><div class="h5">
    <blockquote type="cite"><font face="sans-serif" size="2">Hello Stefan,</font>
      <br>
      <br>
      <font face="sans-serif" size="2">I'm happy someone replied to my
        problem!
        Many thanks! To be honest... I didn't understood much of your
        mail. I'm
        a beginner with the JIT - so I will explain what I've done.</font>
      <br>
      <br>
      <font face="sans-serif" size="2">To manage the memory and resolve
        symbols,
        I'm using my own Resolver-Class, which overloads the allocation
        and the
        findSymbol functions. I've noticed today, that the
        "registerEHFrames"
        function of my class gets called automatically, with correct
        values. I'm
        remapping my code and the address are still correct. Great! But,
        what should
        I do with it? I pass the values to the original function, but my
        exception
        won't be caught! It's an exception raised inside the JITTED code
        and should
        also catched there.</font>
      <br>
      <br>
      <font face="sans-serif" size="2">I tried loading the "msvcrt.lib"
        as a archive. That was... a bad idea! I get a Exception while
        loading:</font>
      <br>
      <font face="sans-serif" size="2">Assertion failed:
        ((int64_t)Result <=
        INT32_MAX) && "Relocation overflow", file
        \lib\executionengine\<wbr>runtimedyld\Targets/<wbr>RuntimeDyldCOFFX86_64.h,
        line 81</font>
      <br>
      <br>
      <font face="sans-serif" size="2">Research didn't helped me! My
        code was
        compiled with /MD, but it didn't changed. So I'm still stupid D:</font>
      <br>
      <font face="sans-serif" size="2">The JITTED code must be loaded to
        shared
        memory later - there aren't libraries, so even if this would
        work, it wouldn't
        help me. I tried compiling my code with sjlj-exceptions. Didn't
        worked...</font>
      <br>
      <br>
      <font face="sans-serif" size="2">Is there no hope left?</font>
      <br>
      <br>
      <font face="sans-serif" size="2">Kind regards</font>
      <br>
      <font face="sans-serif" size="2">Björn</font>
      <br>
      <br>
      <br>
      <br>
      <font face="sans-serif" size="1" color="#5f5f5f">From:      
         </font><font face="sans-serif" size="1">Stefan Gränitz
        <a class="m_8479653584311911203moz-txt-link-rfc2396E" href="mailto:stefan.graenitz@gmail.com" target="_blank"><stefan.graenitz@gmail.com></a></font>
      <br>
      <font face="sans-serif" size="1" color="#5f5f5f">To:      
         </font><font face="sans-serif" size="1"><a class="m_8479653584311911203moz-txt-link-abbreviated" href="mailto:bjoern.gaier@horiba.com" target="_blank">bjoern.gaier@horiba.com</a>,
        <a class="m_8479653584311911203moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a></font>
      <br>
      <font face="sans-serif" size="1" color="#5f5f5f">Date:      
         </font><font face="sans-serif" size="1">27.09.2017 23:09</font>
      <br>
      <font face="sans-serif" size="1" color="#5f5f5f">Subject:    
           </font><font face="sans-serif" size="1">Re: [llvm-dev]
        Clang/LLVM JIT - When to use "registerEHFrames()"</font>
      <br>
      <hr noshade>
      <br>
      <br>
      <br>
      <font size="3">Hi Björn<br>
        <br>
        To first answer your questionin the subject: For x86
        registerEHFrames()
        is only a stub. For x86_64 registerEHFrames() is implemented
        properly in
        RuntimeDyldCOFFX86_64, calling MemMgr.registerEHFrames() for
        each EH frame
        section. It should be called and work out of the box without
        your involvement,
        but unfortunately it won't solve your issue. All the essential
        information
        is there in the comments, just check the base classes.<br>
        <br>
        This thread from last year helps with your unresolved symbol:</font><font size="3" color="blue"><u><br>
        </u></font><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html" target="_blank"><font size="3" color="blue"><u>http://lists.llvm.org/<wbr>pipermail/llvm-dev/2016-<wbr>October/106458.html</u></font></a><font size="3"><br>
        <br>
        Back then I tried to solve a related issue: SEH exceptions
        thrown from
        code loaded with RuntimeDyld had to be caught in statically
        compiled code.
        It turned out Windows explicitly prohibits this. I got in touch
        with Microsoft
        people and IIRC it's due to security concerns.<br>
        <br>
        Depending on your specific case, you may want to fall back to </font><font face="Calibri" size="2">vectored
        exception handling. In my experience this was a dead end though.
        If you
        need a solution for arbitrary situations, you just can't jump
        back to a
        "safe" place to continue execution. I tried setjump (on each
        entry point to the dynamically loaded code) / longjmp (in the
        vectored
        exception handler), but the address was invalidated when I
        accessed it.
        I suspect it's kind of undefined behavior to call longjmp
        outside a child
        frame of the function that called setjmp. Anyway it turned all
        far too
        hacky.</font><font size="3"><br>
        <br>
        If you are willing to do research, compare implementations and
        behavior
        with the MachO and ELF versions. At least one of them works,
        just not on
        Windows ;)<br>
        Also check the LLILC project: </font><a href="https://github.com/dotnet/llilc" target="_blank"><font size="3" color="blue"><u>https://github.com/dotnet/<wbr>llilc</u></font></a><font size="3">
        I heard about some solution that uses trampolines to push
        exceptions back
        to dynamically loaded code and handle them there.<br>
        <br>
        AND disclaimer: I did not follow recent developments in this
        area. If there's
        news please let me know!<br>
        <br>
        Cheers & Good Luck!<br>
        Stefan</font>
      <p><font size="3">Am 25.09.17 um 11:31 schrieb via llvm-dev:</font>
        <br>
        <font face="sans-serif" size="2">Hello friendly LLVM-World,</font><font size="3">
          <br>
        </font><font face="sans-serif" size="2"><br>
          because I don't know if I had send my problem to the correct
          Mailing-List,
          I will send my problem to this address too. I'm not subscribed
          to this
          list, so please add my in CC if you response.</font><font size="3"> <br>
        </font><font face="sans-serif" size="2"><br>
          Kind regards</font><font size="3"> </font><font face="sans-serif" size="2"><br>
          Björn</font><font size="3"> <br>
          <br>
        </font><font face="sans-serif" size="1" color="#5f5f5f"><br>
          From:        </font><font face="sans-serif" size="1">Bjoern
          Gaier/HE/HORIBA</font><font size="3"> </font><font face="sans-serif" size="1" color="#5f5f5f"><br>
          To:        </font><font face="sans-serif" size="1">Clang
          Dev </font><a href="mailto:cfe-dev@lists.llvm.org" target="_blank"><font face="sans-serif" size="1" color="blue"><u><cfe-dev@lists.llvm.org></u></font></a><font face="sans-serif" size="1">,
          "cfe-dev" </font><a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank"><font face="sans-serif" size="1" color="blue"><u><cfe-dev-bounces@lists.llvm.<wbr>org></u></font></a><font size="3">
        </font><font face="sans-serif" size="1" color="#5f5f5f"><br>
          Date:        </font><font face="sans-serif" size="1">19.09.2017
          08:05</font><font size="3"> </font><font face="sans-serif" size="1" color="#5f5f5f"><br>
          Subject:        </font><font face="sans-serif" size="1">Clang/LLVM
          JIT - When to use "registerEHFrames()"</font><font size="3"> <br>
        </font>
      </p>
      <hr noshade><font size="3"><br>
      </font><font face="sans-serif" size="2"><br>
        Hello friendly Clang-World,</font><font size="3"> <br>
      </font><font face="sans-serif" size="2"><br>
        I was experimenting with Clang and the JIT capabilities of LLVM.
        Most of
        my attempts were successfully but, I still fail miserably at
        exceptions.
        Doing research I found the function "registerEHFrames()" which
        should assist me supporting exceptions - but sadly the
        documentation I
        found wasn't helpful.</font><font size="3"> </font><font face="sans-serif" size="2"><br>
        I looked at into the "notifyObjectLoaded" function and
        discovered
        that there appear some symbol names starting with "$" - I
        expected
        them to be connected to my try and catch block. But what now? As
        usually,
        at this point I have there names, but can't get there address to
        register
        them with the "registerEHFrames()" function. Also the JITTER
        still wants an address for "??_7type_info@@6B@" which is the
        virtual table of the type_info struct.</font><font size="3"> <br>
      </font><font face="sans-serif" size="2"><br>
        Confusing! So friendly Clang-World, could you please help? </font><font size="3"><br>
      </font><font face="sans-serif" size="2"><br>
        Not so important - but has the dragon which decorates clang and
        LLVM a
        name?</font><font size="3"> <br>
      </font><font face="sans-serif" size="2"><br>
        Kind regards</font><font size="3"> </font><font face="sans-serif" size="2"><br>
        Björn</font><font size="3"> </font><font face="sans-serif" size="2"><br>
        <br>
        Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB
        9816, USt.ID-Nr.
        DE 114 165 789<br>
        Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus
        Bode, Heiko
        Lampert, Takashi Nagano, Takeshi Fukushima.</font><font size="3">
        <br>
      </font>
      <br>
      <tt><font size="3">______________________________<wbr>_________________<br>
          LLVM Developers mailing list<br>
        </font></tt><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><tt><font size="3" color="blue"><u>llvm-dev@lists.llvm.org</u></font></tt></a><tt><font size="3"><br>
        </font></tt><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><tt><font size="3" color="blue"><u>http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</u></font></tt></a><tt><font size="3"><br>
        </font></tt>
      <br>
      <tt><font size="3">-- <br>
        </font></tt><a href="https://weliveindetail.github.io/blog/" target="_blank"><tt><font size="3" color="blue"><u>https://weliveindetail.github.<wbr>io/blog/</u></font></tt></a><tt><font size="3"><br>
        </font></tt><a href="https://cryptup.org/pub/stefan.graenitz@gmail.com" target="_blank"><tt><font size="3" color="blue"><u>https://cryptup.org/pub/<wbr>stefan.graenitz@gmail.com</u></font></tt></a>
      <br>
      <br>
      <font face="sans-serif" size="2"><br>
        Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB
        9816, USt.ID-Nr.
        DE 114 165 789<br>
        Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus
        Bode, Heiko
        Lampert, Takashi Nagano, Takeshi Fukushima.</font>
    </blockquote>
    <br>
    <pre class="m_8479653584311911203moz-signature" cols="72">-- 
<a class="m_8479653584311911203moz-txt-link-freetext" href="https://weliveindetail.github.io/blog/" target="_blank">https://weliveindetail.github.<wbr>io/blog/</a>
<a class="m_8479653584311911203moz-txt-link-freetext" href="https://cryptup.org/pub/stefan.graenitz@gmail.com" target="_blank">https://cryptup.org/pub/<wbr>stefan.graenitz@gmail.com</a></pre>
  </div></div></div>

<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>