<div dir="ltr">Hi Haoran, Stefan,<div><br></div><div>This case is poorly supported at the moment. I think your workaround (changing it to a decl) is good for now. You could also use a JITLink plugin to replace the duplicate definition with an absolute symbol at link time, but it's probably better to drop the definition before adding and save yourself some compile time.</div><div><br></div><div>Eventually I would like to improve weak symbol handling by adding a new WeakSymbolManager abstraction. This would be attached to the ExecutionSession and would be called for each MaterializationUnit before it is added. It would enable proper resolution of weak symbols across JITDylib boundaries (also currently unsupported) and could scan the process symbols first. It's on my todo list, but I have to get some JITLink work and the removable dylibs feature done first. If anyone wants to tackle this as a project I'd be happy to help with pointers. :)</div><div><br></div><div>Regards,</div><div>Lang.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020 at 9:14 AM Stefan Gränitz <<a href="mailto:stefan.graenitz@gmail.com">stefan.graenitz@gmail.com</a>> wrote:<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">
  
    
  
  <div>
    <p>Hi Haoran<br>
      <br>
      Yes, that's expected behavior. Definition generators only get
      invoked for symbols that are not defined in your modules. The
      documentation in <a href="https://llvm.org/docs/ORCv2.html" target="_blank">https://llvm.org/docs/ORCv2.html</a> says:<br>
      <br>
      > If a definition generator is attached to a JITDylib,
      then any unsuccessful lookup on that JITDylib will fall back to
      calling the
      definition generator<br>
      <br>
      I guess the situation is hard to compare with the context a static
      linker runs in. It's an interesting idea though. Maybe it's
      possible achieve with a JITLink plugin?<br>
      <br>
      Best<br>
      Stefan<br>
      <br>
      On 07/08/2020 11:51, Haoran Xu via llvm-dev wrote:<br>
    </p>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Hello,</div>
        <div><br>
        </div>
        <div>I recently hit an issue when JIT'ing my generated IR using
          llvm::orc::LLJIT. My IR contains the following definition of a
          global variable:</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">
          <div>$_ZZ23TestStaticVarInFunctionbE1x = comdat any<br>
            @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local
            global i32 123, comdat, align 4</div>
        </blockquote>
        <div><br>
        </div>
        <div>And in my host process, there exists the same symbol. I
          would expect LLJIT to resolve the global variable above to the
          address inside the host process, since it has linkage
          'linkonce_odr'. However, it turns out that LLJIT resolved it
          as if it were a conventional global variable definition and
          gave it its own address (I have added 'GetForCurrentProcess'
          generator for symbol resolution of course). <br>
        </div>
        <div><br>
        </div>
        <div>I can workaround this issue by making the symbol a
          declaration (drop the initializer, comdat and make the linkage
          external), but I'm wondering if it is expected behavior that
          LLJIT does not respect linkonce_odr specifier, since the
          documentation says LLJIT's symbol resolution should work as if
          I were running a normal linker. </div>
        <div><br>
        </div>
        <div>Best,</div>
        <div>Haoran<br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <pre cols="72">-- 
<a href="https://flowcrypt.com/pub/stefan.graenitz@gmail.com" target="_blank">https://flowcrypt.com/pub/stefan.graenitz@gmail.com</a></pre>
  </div>

</blockquote></div>