https://bugs.kde.org/show_bug.cgi?id=473944
--- Comment #1 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to Philippe Waroquiers from comment #0) I really don't understand what linker writers are doing. First they split the RW PT_LOAD into 2 which I thought was for performance, putting infrequently accessed stuff in a separate page from the frequently accessed stuff. But that uses more memory, so they allow the segments to overlap pages. I don't see what the benefit of having split+overlapped. Why not just have the one segment? > So, clearly we have 2 different segments. > The condition > 'a_phdr.p_offset == VG_PGROUNDDN(a_phdr.p_offset)' > in readelf.c to consider that the 2nd segment is glued with the first one is > very bizarre. > The above condition only ensures that p_offset (offset in the file) is on a > 0x1000 page boundary ???? As I understand it the split RW PT_LOAD segments used to always start on page boundaries, meaning that there would be padding after the first one. I think padding is required between segments with different protection since the granularity of the protection is the page size. Without overlapping the only time that VG_(di_notify_mmap) would only be called once for two PT_LOAD segments merged into one NSegement is if the first one ends exactly before a page boundary. If looks like overlapping segments started to be allowed back around 2019 https://reviews.llvm.org/D64906 https://reviews.llvm.org/rG0264950697e54505e5fd266b364c83e294fc86d9 I don't know what default options linkers are using, but id does look like they are starting to default to allowing overlapping. See also this bugzilla item which might be related to this https://bugs.kde.org/show_bug.cgi?id=472409 > The condition to determine that the first rw segment will be merged by > aspacemgr with the second > should be something like: > virtaddr seg1 + (some size) == virtaddr seg2 > ???? > The '(some size)' to use is not very clear to me. > In the readelf output, we have the FileSiz and the MemSiz > It looks like the mapping is done with FileSiz rounded up to the page size. No it's not very clear and there are numerous places where the code is impacted. -- You are receiving this mail because: You are watching all bug changes.
