RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built with Clang [v7]

[Kevin Walls]

On Mon, 29 Sep 2025 20:49:41 GMT, Chris Plummer <cjplummer at openjdk.org> 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