linux-kbuild.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
  • * [PATCH v2 0/3] Build ORC fast lookup table in scripts/sorttable tool
           [not found] <20200723034643.33537-1-changhuaixin@linux.alibaba.com>
           [not found] ` <20200723034643.33537-2-changhuaixin@linux.alibaba.com>
    @ 2020-08-07  4:17 ` Huaixin Chang
      2020-08-07  4:18   ` [PATCH 1/3] objtool: Write .orc_lookup section header Huaixin Chang
                         ` (3 more replies)
      1 sibling, 4 replies; 9+ messages in thread
    From: Huaixin Chang @ 2020-08-07  4:17 UTC (permalink / raw)
      To: changhuaixin
      Cc: bp, hpa, jpoimboe, linux-kbuild, linux-kernel, luto, michal.lkml,
    	mingo, peterz, tglx, x86, yamada.masahiro
    
    Move building of fast lookup table from boot to sorttable tool. This saves us
    6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores. It
    adds a little more than 7ms to boot time when testing on the same CPU.
    
    Changelog v2:
    1. Write .orc_lookup section header via objtool
    2. Move two ORC lookup table macro from orc_lookup.h into orc_types.h
    3. Spell 'ORC' in capitalized fashion
    
    Huaixin Chang (3):
      objtool: Write .orc_lookup section header
      scripts/sorttable: Build ORC fast lookup table via sorttable tool
      x86/unwind/orc: Simplify unwind_init() for x86 boot
    
     arch/x86/include/asm/orc_lookup.h      | 16 ------
     arch/x86/include/asm/orc_types.h       | 16 ++++++
     arch/x86/kernel/unwind_orc.c           | 41 +--------------
     arch/x86/kernel/vmlinux.lds.S          |  2 +-
     scripts/sorttable.h                    | 96 +++++++++++++++++++++++++++++++---
     tools/arch/x86/include/asm/orc_types.h | 16 ++++++
     tools/objtool/orc_gen.c                |  4 ++
     7 files changed, 128 insertions(+), 63 deletions(-)
    
    -- 
    2.14.4.44.g2045bb6
    
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread
  • * Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool
    @ 2020-06-01 17:38 Josh Poimboeuf
      2020-06-03 14:31 ` [PATCH v2 0/3] " Huaixin Chang
      0 siblings, 1 reply; 9+ messages in thread
    From: Josh Poimboeuf @ 2020-06-01 17:38 UTC (permalink / raw)
      To: changhuaixin
      Cc: linux-kernel, linux-kbuild, bp, hpa, luto, michal.lkml, mingo,
    	peterz, tglx, x86, yamada.masahiro
    
    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
    
    ^ permalink raw reply related	[flat|nested] 9+ messages in thread

    end of thread, other threads:[~2020-08-19  3:03 UTC | newest]
    
    Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
    -- links below jump to the message on this page --
         [not found] <20200723034643.33537-1-changhuaixin@linux.alibaba.com>
         [not found] ` <20200723034643.33537-2-changhuaixin@linux.alibaba.com>
    2020-08-04  1:40   ` [PATCH 1/3] scripts/sorttable: Change section type of orc_lookup to SHT_PROGBITS changhuaixin
    2020-08-06 15:08     ` Ingo Molnar
    2020-08-07  4:22       ` changhuaixin
    2020-08-07  4:17 ` [PATCH v2 0/3] Build ORC fast lookup table in scripts/sorttable tool Huaixin Chang
    2020-08-07  4:18   ` [PATCH 1/3] objtool: Write .orc_lookup section header Huaixin Chang
    2020-08-07  4:18   ` [PATCH 2/3] scripts/sorttable: Build ORC fast lookup table via sorttable tool Huaixin Chang
    2020-08-07  4:18   ` [PATCH 3/3] x86/unwind/orc: Simplify unwind_init() for x86 boot Huaixin Chang
    2020-08-19  3:03   ` [PATCH v2 0/3] Build ORC fast lookup table in scripts/sorttable tool changhuaixin
    2020-06-01 17:38 [PATCH 0/2] " Josh Poimboeuf
    2020-06-03 14:31 ` [PATCH v2 0/3] " Huaixin Chang
    

    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).