On Mon, 29 Sep 2025 20:49:41 GMT, Chris Plummer <[email protected]> wrote:
> Do we understand why this offset is happening?
It looks like the binary is just built differently, clang or the linker or some
combination arranges things differently to what we have seen from gcc.
Maybe it's enough to say there doesn't have to be a 1:1 mapping from program
headers to segments in the process.
We can have a core file segment that contains more than one program header from
the library (that 0x19000 size segment at the libjimage base address).
So, new question:
we must have been through this loop already, in the libjimage example with the
first LOAD PH of size 0x000000000000841c at the library base address.
Did that pass the same test?
No it can't, the mapping is 0x19000 and size 0x841c does not round up to that.
I think we must ignore the first LOAD PH from the clang build as we check:
408 } else if (lib_php->p_flags != existing_map->flags) {
..and the first LOAD PH from
https://bugs.openjdk.org/secure/attachment/116209/3libjimage_all.txt
..is a Read only, not execute.
This should be OK in this case:
https://bugs.openjdk.org/secure/attachment/116199/3core_all.txt
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000141000 0x00007fa9ff0e4000 0x0000000000000000
0x0000000000019000 0x0000000000019000 R E 0x1000
Filesize and memsiz both 0x019000 must mean the core contains everything, we
don't need either of these from the library.
But there is no harm in continuing past the problematic check and populating
existing_map from the library.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2390746069
