[PATCH] D23505: [ELF] - Linkrscript: shange the way of creating PT_LOADs segments when LS is used.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 30 01:20:17 PDT 2016


>> FreeBSD script seems to rely on this logic, and also it seems to be clear and simple, so patch implements the same.
>
>How does in depend on it?

Patch is abandoned, I think I was mistaken since kernel boots without that afaik,
but initially I noticed that output from ld is 2 PT_LOADS aligned to memory page size:

LOAD           0x0000000000000000 0xffffffff80200000 0xffffffff80200000
                 0x0000000000fe2de8 0x0000000000fe2de8  R E    200000
LOAD           0x0000000000fe3000 0xffffffff813e3000 0xffffffff813e3000
                 0x0000000000129430 0x00000000003313c0  RW     200000

ld output is
LOAD           0x0000000000000000 0xffffffff80001000 0xffffffff80001000
                0x00000000000e410e 0x00000000000e410e  R      1000
LOAD           0x00000000000e4110 0xffffffff800e5110 0xffffffff800e5110
                0x0000000000ba2b0c 0x0000000000ba2b0c  R E    1000
LOAD           0x0000000000c86c20 0xffffffff80c87c20 0xffffffff80c87c20
                0x000000000038ab28 0x000000000038ab28  R      1000
LOAD           0x0000000001012000 0xffffffff81013000 0xffffffff81013000
                0x000000000012ae30 0x0000000000331e30  RW     1000

So only first and the last PT_LOADS are aligned though 2 and 3 has different attributes "RE" vs "R".

I thought that alignment is important,
because second load ends at
0xffffffff800e5110 + 0x0000000000ba2b0c = FFFFFFFF80C87C1C
and shares the same memory page with the third load at 0xffffffff80c87c20,
so there is a conflict of access attributes.

But as far I understand it is not important for kernel, not sure why.

George.


More information about the llvm-commits mailing list