From: Josh Poimboeuf <jpoimboe@redhat.com>
To: changhuaixin <changhuaixin@linux.alibaba.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
bp@alien8.de, hpa@zytor.com, luto@amacapital.net,
michal.lkml@markovi.net, mingo@redhat.com, peterz@infradead.org,
tglx@linutronix.de, x86@kernel.org,
yamada.masahiro@socionext.com
Subject: Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool
Date: Mon, 1 Jun 2020 12:38:40 -0500 [thread overview]
Message-ID: <20200601173840.3f36m6l4fsu5bill@treble> (raw)
In-Reply-To: <482837A8-E9D9-4229-B7B1-8E14403FB2AC@linux.alibaba.com>
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
next prev parent reply other threads:[~2020-06-01 17:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 6:46 [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool Huaixin Chang
2020-04-29 6:46 ` [PATCH 1/2] scripts/sorttable: Build orc fast lookup table via sorttable tool Huaixin Chang
2020-04-29 6:46 ` [PATCH 2/2] x86/unwind/orc: Remove unwind_init() from x86 boot Huaixin Chang
2020-04-29 8:49 ` [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool Peter Zijlstra
2020-04-30 2:32 ` changhuaixin
2020-04-30 4:06 ` Josh Poimboeuf
2020-04-30 4:10 ` Josh Poimboeuf
2020-05-22 18:28 ` Josh Poimboeuf
2020-05-25 3:33 ` changhuaixin
[not found] ` <482837A8-E9D9-4229-B7B1-8E14403FB2AC@linux.alibaba.com>
2020-06-01 17:38 ` Josh Poimboeuf [this message]
2020-06-03 13:47 ` changhuaixin
2020-06-03 14:31 ` [PATCH v2 0/3] " Huaixin Chang
2020-06-03 14:31 ` [PATCH 1/3] scripts/sorttable: Change section type of orc_lookup to SHT_PROGBITS Huaixin Chang
2020-06-03 14:31 ` [PATCH 2/3] scripts/sorttable: Build orc fast lookup table via sorttable tool Huaixin Chang
2020-06-03 14:31 ` [PATCH 3/3] x86/unwind/orc: Simplify unwind_init() for x86 boot Huaixin Chang
2020-06-03 14:39 ` [PATCH v3 0/3] Build ORC fast lookup table in scripts/sorttable tool Huaixin Chang
2020-06-03 14:39 ` [PATCH 1/3] scripts/sorttable: Change section type of orc_lookup to SHT_PROGBITS Huaixin Chang
2020-06-03 14:39 ` [PATCH 2/3] scripts/sorttable: Build orc fast lookup table via sorttable tool Huaixin Chang
2020-06-03 14:39 ` [PATCH 3/3] x86/unwind/orc: Simplify unwind_init() for x86 boot Huaixin Chang
2020-06-29 2:14 ` [PATCH v3 0/3] Build ORC fast lookup table in scripts/sorttable tool changhuaixin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200601173840.3f36m6l4fsu5bill@treble \
--to=jpoimboe@redhat.com \
--cc=bp@alien8.de \
--cc=changhuaixin@linux.alibaba.com \
--cc=hpa@zytor.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=michal.lkml@markovi.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).