Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool

Josh Poimboeuf
2020-06-01T17:38:53Z

On Sun, May 31, 2020 at 01:26:54PM +0800, changhuaixin wrote:
> It turned out to be an alignment problem. If sh_size of previous section
> orc_unwind is not 4-byte aligned, sh_offset of the following orc_lookup
> section is not 4-byte aligned too. However, the VMA of section orc_lookup
> is aligned to the nearest 4-byte. Thus, the orc_lookup section means two
> different ares for scripts/sorttable tool and kernel.
>
> Sections headers look like this when it happens:
>
> 12 .orc_unwind_ip 00172124  ffffffff82573b28  0000000002573b28  01773b28
>  2**0
>                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 13 .orc_unwind   0022b1b6  ffffffff826e5c4c  00000000026e5c4c  018e5c4c
>  2**0
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
> 14 .orc_lookup   0003003c  ffffffff82910e04  0000000002910e04  01b10e02
>  2**0
>                  ALLOC
> 15 .vvar         00001000  ffffffff82941000  0000000002941000  01b41000
>  2**4
>                  CONTENTS, ALLOC, LOAD, DATA
>
> Sorttable tool uses the are starting with offset 0x01b10e02 for 0x0003003c
> bytes. While kernel use the area starting with VMA at  0xffffffff82910e04
> for 0x0003003c bytes, meaning that each entry in this table used by kernel
> is actually 2 bytes behind the corresponding entry set from sorttable
> tool.
>
> Any suggestion on fixing this？

The VMA and LMA are both 4-byte aligned. The file offset alignment
(0x01b10e02) shouldn't matter.

Actually it looks like the problem is that the section doesn't have
CONTENTS, so it's just loaded as a BSS section (all zeros). The section
needs to be type SHT_PROGBITS instead of SHT_NOBITS.

$ readelf -S vmlinux |grep orc_lookup
[16] .orc_lookup NOBITS ffffffff82b68418 01d68418

I tried to fix it with

diff --git a/scripts/sorttable.h b/scripts/sorttable.h
index a36c76c17be4..76adb1fb88f8 100644
--- a/scripts/sorttable.h
+++ b/scripts/sorttable.h
@@ -341,6 +341,7 @@ static int do_sort(Elf_Ehdr *ehdr,
param.lookup_table_size = s->sh_size;
param.orc_lookup_table = (unsigned int *)
((void *)ehdr + s->sh_offset);
+ w(SHT_PROGBITS, &s->sh_type);
}
if (!strcmp(secstrings + idx, ".text")) {
param.text_size = s->sh_size;

But that makes kallsyms unhappy, so I guess we need to do it from the
linker script where .orc_lookup is created.

Linker script doesn't seem to allow manual specification of the section
type, so this is the best I could come up with:

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index db600ef218d7..49f4f5bc6165 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -826,6 +826,8 @@
. += (((SIZEOF(.text) + LOOKUP_BLOCK_SIZE - 1) / \
LOOKUP_BLOCK_SIZE) + 1) * 4; \
orc_lookup_end = .; \
+ /* HACK: force SHT_PROGBITS so sorttable can edit: */ \
+ BYTE(1); \
}
#else
#define ORC_UNWIND_TABLE