On Wed, 11 Mar 2026 09:25:44 GMT, Kevin Walls <[email protected]> wrote:

>> On CentOS 7 (glibc-2.17-326.el7_9.3.x86_64), ld-2.17.so is mapped like 
>> following:
>> 
>> 
>> 7f830b42c000-7f830b44e000 r-xp 00000000 08:04 202220966 /usr/lib64/ld-2.17.so
>> 
>> 
>> However SA maps it as following. Base address is correct, but end address is 
>> different from "maps".
>> 
>> 
>> libsaproc DEBUG: /usr/lib64/ld-2.17.so [0] 0x7f830b42c000-0x7f830b62c000: 
>> base = 0x7f830b42c000, vaddr = 0x0, memsz = 0x21960, filesz = 0x21960
>> 
>> 
>> We fixed calculation logic in 
>> [JDK-8377395](https://bugs.openjdk.org/browse/JDK-8377395) to align end 
>> address to align `p_align` in ELF header, but the logic seems to be 
>> incorrect (note that the calculation is working as expected).
>> 
>> Linux Kernel 
>> ([fs/binfmt_elf.c](https://github.com/torvalds/linux/blob/v6.19/fs/binfmt_elf.c#L414))
>>  aligns end address with page size, not `p_align`. So SA might need to 
>> follow it. Otherwise address it might happen address confliction what we saw 
>> in [JDK-8377395](https://bugs.openjdk.org/browse/JDK-8377395).
>
> OK, I would have expected p_align to be ignored if less than page size,
> but Linux just ignores p_align and uses pagesize. 8-)
> 
> The high address 0x7f830b62c000 suggests p_align was higher in this case, 
> 0x200000 2MB ?
> (Unfortunately we don't show p_align when we print all the other details on 
> line 196...)
> 
> Expect the distributions we test have p_align equal to pagesize, so should be 
> unaffected.

@kevinjwalls Thanks for your review!

> The high address 0x7f830b62c000 suggests p_align was higher in this case, 
> 0x200000 2MB ?

Yes, we can see 0x200000 on `readelf -l`.


Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000021960 0x0000000000021960  R E    200000
  LOAD           0x0000000000021b40 0x0000000000221b40 0x0000000000221b40
                 0x0000000000001438 0x0000000000001610  RW     200000
  DYNAMIC        0x0000000000021e00 0x0000000000221e00 0x0000000000221e00
                 0x0000000000000190 0x0000000000000190  RW     8
  NOTE           0x00000000000001c8 0x00000000000001c8 0x00000000000001c8
                 0x0000000000000024 0x0000000000000024  R      4
  GNU_EH_FRAME   0x000000000001eda4 0x000000000001eda4 0x000000000001eda4
                 0x0000000000000674 0x0000000000000674  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000021b40 0x0000000000221b40 0x0000000000221b40
                 0x00000000000004c0 0x00000000000004c0  R      1

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

PR Comment: https://git.openjdk.org/jdk/pull/30154#issuecomment-4038672250

Reply via email to