<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 17, 2025 at 9:55 AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">magnus.ihse.bursie@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <p>On 2025-04-15 16:28, Jiangli Zhou wrote:</p>
    <blockquote type="cite">
      <pre>On Thu, 10 Apr 2025 16:13:47 GMT, Severin Gehwolf <a href="mailto:sgehwolf@openjdk.org" target="_blank"><sgehwolf@openjdk.org></a> wrote:

</pre>
      <span style="white-space:pre-wrap">
</span>
      <blockquote type="cite">
        <pre>$ ll -lh ./demo-image 
-rwxr-xr-x. 1 sgehwolf sgehwolf 909M Apr 10 17:36 ./demo-image
$ strip -g ./demo-image 
$ ll -lh ./demo-image 
-rwxr-xr-x. 1 sgehwolf sgehwolf 50M Apr 10 18:07 ./demo-image
$ ./demo-image -m mod.example/com.example.demo.Main
Error occurred during initialization of VM
Failed setting boot class path.
</pre>
      </blockquote>
      <pre>Yeah, stripping the final image would corrupt the image. The linked launcher executable should be stripped first, then passed to jlink to create the final image. The `build-id` would be the same.</pre>
    </blockquote>
    <p>I tried commenting this on a commit, but I guess it is kind of
      invisible there, so let me repeat it here, and expand on it.</p>
    <p>The current approach on just "tucking on" the jlink data at the
      end of the binary surprises me. I've always just presumed that the
      jimage part should be stored as an ELF section, so that the entire
      binary is a complete, valid ELF file. I assume that if the jlink
      data was stored as a proper ELF section, the binary would not be
      destroyed by strip.<br></p></div></blockquote><div>In the original prototype using the <font face="monospace">singlejar</font> tool, the jimage, cds archive, and JAR files are appended after the ELF binary (see <a href="https://cr.openjdk.org/~jiangli/hermetic_java.pdf">https://cr.openjdk.org/~jiangli/hermetic_java.pdf</a>, slide 10). I basically followed the same approach in the current prototype using <font face="monospace">jlink</font>. We have discussed (a few times) the approach of appending the jimage after the ELF and recording the jimage start offset and size info at the end of the final image during the ongoing hermetic Java meetings.</div><div><br></div><div>Any particular benefits of making the hermetic Java image as a pure ELF binary by fitting the jimage as an ELF section, besides being able to run <font face="monospace">strip</font>? The launcher executable can be stripped during native linking (e.g. with -s for ld) then being fed to jlink for final image creation. </div><div><br></div><div>Tools like gdb, lldb, perf, nm, etc can work with the final hermetic image without issue.</div><div> </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>
    </p>
    <p>It also surprises me that this approach even works. Is appending
      arbitrary stuff at the end of the file explicitly allowed by the
      ELF spec? Or is this solution dependent on ELF loaders being not
      so strict? If so, it can break with any future update to the
      dynamic loader...</p></div></blockquote><div>Self-extracting zip archive is a good example of appending data after an executable (such as an ELF binary on linux). </div><div><br></div><div>Another example that I think that's relatvent is FatELF, see <a href="https://icculus.org/fatelf/">https://icculus.org/fatelf/</a>.  The file format combines multiple ELF binaries into a single file and can be executed on different architectures. </div><div> </div><div>Thanks,</div><div>Jiangli</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>/Magnus<br>
    </p>
  </div>

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