RFR: 8354675: Create separate image builder for hermetic

[Severin Gehwolf]

On Thu, 2025-04-17 at 18:55 +0200, Magnus Ihse Bursie wrote:
> 
> On 2025-04-15 16:28, Jiangli Zhou wrote:
> > 
> > On Thu, 10 Apr 2025 16:13:47 GMT, Severin Gehwolf
> > <sgehwolf at openjdk.org> wrote:
> > > $ 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.
> > > 
> > 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.
> >  
>  
> 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.
>  
> 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.

>  
> 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...


I tend to agree. We need to get this to a point where stripping debug
info doesn't break the hermetic image. After all 'file' and other tools
think this is an ELF binary.

Happy to slot a bug for this.

Thanks,
Severin