<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hi Lang,<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 02/05/16 19:42, Lang Hames wrote:<br>
    </div>
    <blockquote
cite="mid:CALLttgobY91oMuM6M9UuuDSsSwO=O9GTD_C-=qQmyJ9oNPmHig@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">Hi Axel,
        <div><br>
        </div>
        <div>Sorry for the delay. Attached is the patch for RuntimeDyld
          & MCJIT (plus a proof-of-concept MCJIT setup that uses
          it). This was just a quick hack to work around this issue in
          MCJIT - it needs some polish, and it hasn't been tested with
          ORC yet. </div>
      </div>
    </blockquote>
    <br>
    Thanks!<br>
    <br>
    <blockquote
cite="mid:CALLttgobY91oMuM6M9UuuDSsSwO=O9GTD_C-=qQmyJ9oNPmHig@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I think the full solution should look more like this:</div>
        <div><br>
        </div>
        <div>1) In loadObject all symbols in the object should be added
          to the RuntimeDyld instance's symbol table, each marked weak
          or not as appropriate.</div>
        <div>2) In RuntimeDyldImpl::loadObjectImpl weak symbols should
          be treated as if they were externals - i.e. we add symbolic
          relocations for each of them.</div>
        <div>3) In RuntimeDyldImpl::resolveRelocations, for each weak
          symbol we first search the logical dylib for an existing
          strong definition. If we find one we use that, and remove the
          weak definition from the local table entirely. If we don't
          find an existing strong definition we mark our local
          definition as strong and use it.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Yes makes sense, I also thought pseudo-relocs for weak symbols are
    the way to go, given the symbol resolution mechanism of RtDyld.<br>
    <blockquote
cite="mid:CALLttgobY91oMuM6M9UuuDSsSwO=O9GTD_C-=qQmyJ9oNPmHig@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Are you interested in implementing this?</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    The fact that I thought relocs are the way to go, and that I hacked
    something in in the past that "mostly" worked, makes me courageous
    ;-)<br>
    <br>
    I'll give it a try. If I get stuck / time out I'll come back to you.<br>
    <br>
    Cheers, Axel.<br>
    <br>
    <blockquote
cite="mid:CALLttgobY91oMuM6M9UuuDSsSwO=O9GTD_C-=qQmyJ9oNPmHig@mail.gmail.com"
      type="cite">
      <div class="gmail_extra">
        <div class="gmail_quote">On Fri, Apr 29, 2016 at 9:47 AM, Lang
          Hames <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">Hi Axel,
              <div><br>
              </div>
              <div>Yep - RuntimeDyld does not handle weak symbols
                properly at the moment. About a month back I ran into a
                bug that I thought was due to this lack of weak symbol
                support (but that actually turned out to be something
                else) and wrote up a preliminary patch to fix it. When I
                get in to the office in a couple of hours I'll dig that
                patch up and see what kind of state it's in - it should
                serve as a good starting point.</div>
              <span class="HOEnZb"><font color="#888888">
                  <div><br>
                  </div>
                  <div>- Lang.</div>
                </font></span></div>
            <div class="gmail_extra"><br>
              <div class="gmail_quote"><span class="">On Fri, Apr 29,
                  2016 at 5:20 AM, Axel Naumann via llvm-dev <span
                    dir="ltr"><<a moz-do-not-send="true"
                      href="mailto:llvm-dev@lists.llvm.org"
                      target="_blank">llvm-dev@lists.llvm.org</a>></span>
                  wrote:<br>
                </span>
                <div>
                  <div class="h5">
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
                      <br>
                      This is a question on how to resolve weak symbols
                      from the binary for<br>
                      symbols that are also llvm::Module-local.
                      Currently, the JIT seems to<br>
                      favor resolving to module-local symbols over
                      existing symbols:<br>
                      <br>
                      $ cat symbols.cxx<br>
                      extern "C" int printf(const char*,...);<br>
                      <br>
                      template <class T> struct StaticStuff {<br>
                        static T s_data;<br>
                      };<br>
                      template <class T> T
                      StaticStuff<T>::s_data = 42;<br>
                      <br>
                      int compareAddr(int* interp);<br>
                      #ifdef BUILD_SHARED<br>
                      int compareAddr(int* interp) {<br>
                        if (interp !=
                      &StaticStuff<int>::s_data) {<br>
                          printf("Wrong address, %ld in shared lib, %ld
                      in interpreter!\n",<br>
                               
                       (long)&StaticStuff<int>::s_data,<br>
                                 (long)interp);<br>
                          // CHECK-NOT: Wrong address<br>
                          return 1;<br>
                        }<br>
                        return 0;<br>
                      }<br>
                      #else<br>
                      # ifdef __CLING__<br>
                      int Symbols() {<br>
                      # else<br>
                      int main()<br>
                      # endif<br>
                      {  return
                      compareAddr(&StaticStuff<int>::s_data);}<br>
                      #endif // ! BUILD_SHARED<br>
                      <br>
                      <br>
                      $ clang++ -shared -fPIC -DBUILD_SHARED symbols.cxx
                      -o libSymbols.so<br>
                      $ clang++ -cc1 -emit-llvm symbols.cxx -o - |  lli
                      -load ./libSymbols.so -<br>
                      or<br>
                      $ clang++ -lSymbols symbols.cxx && ./a.out<br>
                      <br>
                      Compiled it's happy: the weak symbol used in main
                      gets resolved to be<br>
                      the one in the binary for both references. That's
                      the behavior I'd expect.<br>
                      <br>
                      The JIT OTOH is deciding that it shall use the
                      local version of the<br>
                      symbol; RuntimeDyld::getSymbol() doesn't care
                      about the fact that the<br>
                      symbol is weak and has an existing occurrence.<br>
                      <br>
                      For weak symbols from a different module,
                      RuntimeDyld would use<br>
                      resolveExternalSymbols() and all would be good -
                      but here this doesn't<br>
                      happen.<br>
                      <br>
                      IIUC, RuntimeDyld::getSymbol() really needs to
                      check whether the local<br>
                      symbol should survive or not, before handing out
                      its address. But that<br>
                      seems to break the whole design of when relocs
                      happen, so I'm sure I'm<br>
                      wrong. Can I get some hints on how to implement
                      the proper patch?<br>
                      <br>
                      Cheers, Axel.<br>
                      <br>
                      --<br>
                      ROOT - <a moz-do-not-send="true"
                        href="http://root.cern.ch" rel="noreferrer"
                        target="_blank">http://root.cern.ch</a><br>
                      PH-SFT, CERN, 1211 Geneve 23, Switzerland<br>
                      Tel: <a moz-do-not-send="true"
                        href="tel:%2B41%2022%207678225"
                        value="+41227678225" target="_blank">+41 22
                        7678225</a><br>
                      _______________________________________________<br>
                      LLVM Developers mailing list<br>
                      <a moz-do-not-send="true"
                        href="mailto:llvm-dev@lists.llvm.org"
                        target="_blank">llvm-dev@lists.llvm.org</a><br>
                      <a moz-do-not-send="true"
                        href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
                        rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
                    </blockquote>
                  </div>
                </div>
              </div>
              <br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>