<div dir="ltr"><div dir="ltr">On Tue, Feb 14, 2023 at 1:03 AM Florian Weimer <<a href="mailto:fweimer@redhat.com" target="_blank">fweimer@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Jiangli Zhou:<br>
<br>
> On Mon, Feb 13, 2023 at 1:58 AM Florian Weimer <<a href="mailto:fweimer@redhat.com" target="_blank">fweimer@redhat.com</a>> wrote:<br>
><br>
>  * Jiangli Zhou:<br>
><br>
>  > 1. The executable image (see slide #10 ofa [1]) consists of three<br>
>  > sections: the ELF executable section (see slide #14), the JDK runtime<br>
>  > section (see slide #20, #21) and the JAR section (see slide #22).<br>
><br>
>  These sections are not ELF sections, right?<br>
><br>
> Just to clarify that the ELF sections you referred to in the above are<br>
> the sections within an ELF file<br>
> (e.g. <a href="https://manpages.debian.org/stretch/manpages/elf.5.en.html" rel="noreferrer" target="_blank">https://manpages.debian.org/stretch/manpages/elf.5.en.html</a>), if<br>
> my understanding is correct.  The sections described for a hermetic<br>
> Java image are indeed not ELF sections in that sense. An ELF file as a<br>
> whole is encapsulated in the hermetic image at the beginning. We can<br>
> use a better name (if ELF section may cause any confusions),<br>
> e.g. executable section, to describe the section containing the ELF<br>
> file.<br>
<br>
I wouldn't use “section” or “segment” in this context if it's not about<br>
the ELF constructs.  ELF doesn't use “part” or “appendix” as<br>
terminology, so that would work.<br></blockquote><div><br></div><div>Thanks. Alternatively, 'component' may also be used without potential confusion?</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">
<br>
>  [from further down the thread]<br>
><br>
>  > Yeah, the loadLibrary and friends need to be able look up built-in<br>
>  > libraries in the executable (within the image ELF section). The<br>
>  > existing JDK code is already able to handle built-in libraries<br>
>  > (partially). Please see more details for built-in native support in<br>
>  > earlier comments.<br>
><br>
>  I believe that will require a custom glibc patch that has not been<br>
>  upstreamed.  I think Google's approach is here:<br>
><br>
>   <br>
>  <<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=dlfcn/dlopen.c;h=faf7a48ea71df186b3581235bffcc7a3692f1325;hb=refs/heads/google/grte/v5-2.27/master#l95" rel="noreferrer" target="_blank">https://sourceware.org/git/?p=glibc.git;a=blob;f=dlfcn/dlopen.c;h=faf7a48ea71df186b3581235bffcc7a3692f1325;hb=refs/heads/google/grte/v5-2.27/master#l95</a>><br>
>  <br>
><br>
> The loadLibrary work for built-in native libraries (with JDK static<br>
> support) does not require the glibc patch for dlopen_with_offset.<br>
<br>
Okay, but that means that Hotspot can't be re-linked or unbundled.<br></blockquote><div><br></div><div>That's an interesting use case. Any specific requirements/benefits for re-linking an existing hermetic image with different hotspot code/version?</div><div><br></div><div>From our observations of production usages, change in JDK libraries or the VM would be deployed via new releases (including both JDK release and the application release). Those include different testing cycles/stages before the new binary reaches production. The process includes rebuilding the hermetic image.</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">
<br>
>  There is a different proposed glibc interface for this:<br>
><br>
>    [PATCH v2 2/2] dlfcn,elf: implement dlmem() function [BZ #11767]<br>
>    <<a href="https://sourceware.org/pipermail/libc-alpha/2023-February/145476.html" rel="noreferrer" target="_blank">https://sourceware.org/pipermail/libc-alpha/2023-February/145476.html</a>><br>
><br>
>  Maybe you could check if that interface could serve your needs as well?<br>
><br>
> Thanks for pointing to dlmem(). So it looks like we could read the DSO<br>
> into a buffer then load with dlmem(). Cool! The build ID and symbol<br>
> file mapping could still be problematic?<br>
<br>
I don't think so, it's linked into the glibc dynamic loader data<br>
structures like any other mapping.  It probably depends on the tooling.<br>
If it uses DT_DEBUG/_r_debug, it should be able to identify these<br>
mappings even though they are not file-based.  If the tooling uses<br>
/proc/PID/maps and not _r_debug, that's of course a different matter.</blockquote><div><br></div><div>If I understand correctly from past (internal) discussions with the folks from the tooling side, the <span style="color:rgb(32,33,36);font-family:Arial;white-space:pre-wrap">existing tools mostly have the assumption that the ELF header starts at the beginning of an ELF file (the hermetic Java image can be treated as an ELF by tools since that's at the beginning of the image). If we are going with </span><span style="color:rgb(32,33,36);font-family:Arial;white-space:pre-wrap">supporting file embedded DSOs, it would require propagating the support in</span><span style="color:rgb(32,33,36);font-family:Arial;white-space:pre-wrap"> various tools (perf, gdb, lldb, ...). </span></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">
<br>
Note that dlmem is just a proposed new interface for now.<br></blockquote><div><br></div><div>Thanks for that data point. </div><div><br></div><div>Best,</div><div>Jiangli</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">
<br>
Thanks,<br>
Florian<br>
<br>
</blockquote></div></div>