<div dir="auto"><p dir="ltr">> As far as I'm aware, there are no implementations that allow you to load a 32-bit library into a 64-bit process (and vice versa of course).</p>
<p dir="ltr">I don't program for PC very often, I need this functionality to implement Panama on Android. In the implementation of SymbolLookup.loaderLookup(), I scan all libraries connected to the current class loader. And some of them may actually have a different ABI - via the native bridge mechanism.</p><p dir="ltr"><a href="https://android.googlesource.com/platform/art/+/refs/heads/main/libnativebridge/">https://android.googlesource.com/platform/art/+/refs/heads/main/libnativebridge/</a><br></p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 11 окт. 2024 г., 21:41 Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" target="_blank" rel="noreferrer">jorn.vernee@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
  <div>
    <p>As far as I'm aware, there are no implementations that allow you
      to load a 32-bit library into a 64-bit process (and vice versa of
      course). Though, it is possible to run 32-bit processes on 64-bit
      machines through emulation (e.g. Wow64 on Windows). Do you have an
      example of loading 32-bit libraries into 64-bit processes?</p>
    <p>Jorn<br>
    </p>
    <div>On 11-10-2024 15:46, Владимир Козелков
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Thanks for the answer.<br>
        <div><br>
        </div>
        <div>At the moment, support on 64-bit architectures, their
          32-bit variants are very difficult, and I see several problems
          with this.<br>
        </div>
        <div><br>
        </div>
        <div>It seems to me that the main problem is in considering
          addresses outside of Linker and the existence of the
          ValueLayout.ADDRESS constant. All ValueLayout.JAVA_* constants
          have the same size, alignment and byte order on all platforms
          - this is determined by the Java platform itself. All native
          layouts are inside Linker.canonicalLayouts(), except for
          addresses (which are <b>always </b>platform-dependent). Why?<br>
        </div>
        <div><br>
        </div>
        <div>If we really want to support multiple calling conventions
          for ABIs with different bit depths (and this is the most
          common case of different ABIs on the same platform), we will
          also need to add support for AddressLayouts not only of
          different alignments, but also of different sizes, which will
          require non-trivial handling in VarHandles and some other
          places. In this case, we also need to say that
          ValueLayout.ADDRESS refers to Linker.nativeLayout(), but there
          could be others...<br>
        </div>
        <div><br>
        </div>
        <div>Unfortunately, there are problems not only with layouts,
          but also with memory segments. 32-bit ABIs only support 32-bit
          addresses, as funny as it may sound. So standard memory
          segments are unlikely to be used with 32-bit ABIs - you need a
          linker-dependent way to allocate memory, for example only in
          the first four gigabytes of process memory (I know for sure
          that Linux supports this)<br>
        </div>
        <div><br>
        </div>
        <div>All of this needs to be carefully thought out and reflected
          in the documentation, which can require a lot of work. This
          seems like a pretty big and radical change, but it is
          possible.<br>
        </div>
        <div><br>
        </div>
        <div>Cheers<br>
        </div>
        <div>Vladimir</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">пт, 11 окт. 2024 г. в 16:46,
          Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" rel="noreferrer noreferrer" target="_blank">maurizio.cimadamore@oracle.com</a>>:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <p>Hi,<br>
              Having the ability to select different calling conventions
              (or, more accurately, completely different ABIs) is a
              powerful trick. It comes in especially handy in cases that
              I'd call foreign^2 - that is, when you want to talk to
              some native function that adopts calling conventions that
              are not first-class on that particular system. I view x86
              on x64 and x64 on arm64 as largely similar in spirit.</p>
            <p>That is in contrast, IMHO with the situation we had with
              x86 - where multiple competing calling conventions often
              existed within the same system (sometimes with the intent
              of providing better performances in certain contexts).
              Windows x86 supports six (!!) calling conventions [1]. By
              contrast, on Windows x64 there's only two (__vectorcall is
              apparently still around, although I don't know how widely
              used). Other platforms followed a similar evolution.</p>
            <p>The cross-architecture-compatibility use case you mention
              is an emerging important one, so we will keep an eye in
              this space for sure.</p>
            <p>Maurizio</p>
            <p>[1] -
              <a href="https://learn.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=msvc-170" rel="noreferrer noreferrer" target="_blank">https://learn.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=msvc-170</a></p>
            <div>On 11/10/2024 01:48, Владимир Козелков wrote:<br>
            </div>
            <blockquote type="cite">
              <p dir="ltr">I think the main use of alternative linkers
                is to reflect the existing ability of systems to run
                binaries from other platforms. </p>
              <p dir="ltr">In my example, it was possible to use old
                binaries for 32-bin systems on 64-bit systems. But
                platforms are not limited to this. You were wrong when
                you said about the unified calling convention on new
                architectures - just look at the ARM64EC calling
                convention - it allows an application to have both
                aarch64 and x86_64 binaries in the process!</p>
              <p dir="ltr">Also... I'm confused by the existence of Wine
                on Linux - it provides a platform for running binaries
                of the same architecture, but of a different operating
                system (Windows). Unfortunately, I don't know if it has
                the ability to have a process with mixed binaries and
                how this relates to Java, but this is also an
                interesting example. </p>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">пт, 11 окт. 2024 г.,
                  4:04 Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" rel="noreferrer noreferrer" target="_blank">maurizio.cimadamore@oracle.com</a>>:<br>
                </div>
                <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
                  as you noticed, while the Linker javadoc alludes at
                  the fact that there <br>
                  might be other calling conventions supported in the
                  future, at the <br>
                  moment there's no API to expose this. What we had in
                  mind the last time <br>
                  we discussed this was not too dissimilar to what you
                  propose here - <br>
                  basically just keep calling convention open, by using
                  strings, and then <br>
                  allow the "nativeLinker" factory to accept a calling
                  convention string.<br>
                  <br>
                  Another possibility would be to use linker options -
                  e.g. have a <br>
                  CallingConvention linker option that can be passed to
                  <br>
                  downcallHandle/upcallStub. This would allow to keep a
                  single linker, but <br>
                  to support downcalls with different calling
                  conventions. Both approaches <br>
                  are equally expressive, at least in terms of allowing
                  to call functions <br>
                  using different argument shuffling. That said, on some
                  platforms, like <br>
                  PowerPC support for instance different kind of
                  endianness. So perhaps it <br>
                  would be good to have a way to ask for the "big
                  endian" Linker, whose <br>
                  canonical layouts will be... big endian. That is, a
                  Linker is about <br>
                  functions as much as it is about the definition of
                  fundamental data <br>
                  types. So, perhaps when adding support for different
                  Linker "flavors" it <br>
                  would be good to keep this in mind.<br>
                  <br>
                  The reason we left this out in 22 was that we wanted
                  to learn more use <br>
                  cases where this was useful. For instance, while it's
                  true that x86 <br>
                  supported several calling conventions, modern systems
                  seems to have <br>
                  evolved a bit, so that each major platform tend to
                  gravitate towards one <br>
                  main set of calling convention, typically specified in
                  that platform's <br>
                  ABI (e.g. SysV for Linux). It seems to me that even in
                  your case, the <br>
                  main driver for selecting an alternate calling
                  convention is x86 really. <br>
                  So I'm still not 100% sure that this is something
                  worth pursuing. I <br>
                  would feel more at ease if we had more cases where
                  this was useful.<br>
                  <br>
                  Cheers<br>
                  Maurizio<br>
                  <br>
                  <br>
                  On 10/10/2024 20:14, Владимир Козелков wrote:<br>
                  > Greetings,<br>
                  ><br>
                  > The documentation for the Linker.nativeLinker()
                  method says: "It is <br>
                  > not currently possible to obtain a linker for a
                  different combination <br>
                  > of OS and processor."<br>
                  ><br>
                  > This is indeed true for hotspot, but what if
                  another implementation <br>
                  > could provide the ability to create a linker for
                  a different calling <br>
                  > convention? Even if the implementation wanted to
                  do this, it would <br>
                  > fail because the API does not provide any points
                  through which this <br>
                  > could be done.<br>
                  ><br>
                  > As an example - android allows us to use binaries
                  for arm in aarch64 <br>
                  > and for x86 in x86_64 with JNI. In the current
                  implementation, I have <br>
                  > to filter the output of
                  SymbolLookup.loaderLookup() so that the user <br>
                  > does not get symbols with a different calling
                  convention, although the <br>
                  > platform really allows to use them.<br>
                  ><br>
                  > Additionally, I would like to note that the x86
                  and x86_64 platforms <br>
                  > have several "native" calling conventions, such
                  as cdecl (which is <br>
                  > actually used now), fastcall, vectorcall,
                  etc. Even if a hotspot does <br>
                  > not allow these calling conventions, it would be
                  useful to have at <br>
                  > least the potential to implement them.<br>
                  ><br>
                  > I can suggest a not very good and naive method
                  for solving the problem <br>
                  > - it is inspired by target-triple from LLVM:<br>
                  ><br>
                  > interface Linker ... {<br>
                  >     static List<String>
                  supportedConventions() {return ... ;}<br>
                  >     static String defaultConvention() {return ...
                  ;}<br>
                  >     static boolean isSupportedConvention(String
                  convention) {return ... ;}<br>
                  >     static Linker linkerForConvention(String 
                  convention) {return ... ;}<br>
                  >     static Linker nativeLinker() {<br>
                  >         return
                  linkerForConvention(defaultConvention());<br>
                  >     }<br>
                  > }<br>
                  ><br>
                  > For android aarch64 defaultConvention() will
                  return something like <br>
                  > "aarch64-android-cdecl"<br>
                  ><br>
                  > Thanks for reading<br>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div></div>