> On Jun 2, 2020, at 1:38 AM, Josh Poimboeuf <jpoim...@redhat.com> wrote: > > 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 Thanks! It works.