[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