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

[Chris Plummer]

On Tue, 30 Sep 2025 10:19:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 428:
>> 
>>> 426:             lib_memsz += target_vaddr - existing_map->vaddr;
>>> 427:         }
>>> 428: 
>> 
>> I think this change looks good, but just want to make sure I'm understanding it properly. Kevin commented the following:
>> 
>> 
>> hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)
>> 
>>           print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
>>                         target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);
>> 
>> core has no mapping at exactly 0x7fa9ff0e4440 but has:
>> 
>>   Start                 End               Page Offset
>>   0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
>>   0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error
>> 
>> 
>> So the problem here is that we were expecting 0x00007fa9ff0e4000 but got 0x7fa9ff0e4440. Basically target_vaddr is at an unexpected offset from existing_map->vaddr. The fix is to ad this offset to lib_memsz so the error is no longer triggered. Do we understand why this offset is happening?
>
>>  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.

Ok. That's mostly making sense to me. I'm still a bit fuzzy on it, but that's ok. Has testing been done to make sure this doesn't break anything with gcc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2395729935