search for: __start_builtin_fw

Displaying 15 results from an estimated 15 matches for "__start_builtin_fw".

2014 Dec 08
4
[LLVMdev] Incorrect loop optimization when building the Linux kernel
> It's difficult to say without a full example, but I'm very suspicious > of those global declarations. I think the compiler would be entirely > justified in assuming you could *never* get from __start_builtin_fw to > __end_builtin_fw, let alone on the first iteration: they're distinct > array objects and by definition (within C99) can't overlap. I think this should be the root cause. Once I changed the declaration to pointers (instead of arrays): extern struct builtin_fw* __start_builtin_fw...
2014 Dec 08
3
[LLVMdev] Incorrect loop optimization when building the Linux kernel
I was trying to build the Linux kernel with clang and observed a crash due to incorrect loop optimization: drivers/base/firmware_class.c extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name) { struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { if (strcmp(name, b_fw->name) == 0) { fw->size = b_fw->size; f...
2017 Oct 11
0
[PATCH v1 15/27] compiler: Option to default to hidden symbols
.../microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index 86e8f0b2537b..8f021783a929 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) return *res; } -extern struct builtin_fw __start_builtin_fw[]; -extern struct builtin_fw __end_builtin_fw[]; +extern struct builtin_fw __start_builtin_fw[] __default_visibility; +extern struct builtin_fw __end_builtin_fw[] __default_visibility; bool get_builtin_firmware(struct cpio_data *cd, const char *name) { diff --git a/drivers/base/firmware_class.c...
2014 Dec 08
3
[LLVMdev] Incorrect loop optimization when building the Linux kernel
...cky <nicholas at mxc.ca> wrote: > Chengyu Song wrote: > >> It's difficult to say without a full example, but I'm very suspicious >>> of those global declarations. I think the compiler would be entirely >>> justified in assuming you could *never* get from __start_builtin_fw to >>> __end_builtin_fw, let alone on the first iteration: they're distinct >>> array objects and by definition (within C99) can't overlap. >>> >> >> I think this should be the root cause. Once I changed the declaration to >> pointers (instead of...
2017 Oct 12
2
[PATCH v1 15/27] compiler: Option to default to hidden symbols
...microcode/core.c > index 86e8f0b2537b..8f021783a929 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) > return *res; > } > > -extern struct builtin_fw __start_builtin_fw[]; > -extern struct builtin_fw __end_builtin_fw[]; > +extern struct builtin_fw __start_builtin_fw[] __default_visibility; > +extern struct builtin_fw __end_builtin_fw[] __default_visibility; > > bool get_builtin_firmware(struct cpio_data *cd, const char *name) > { <-- snip...
2017 Oct 12
2
[PATCH v1 15/27] compiler: Option to default to hidden symbols
...microcode/core.c > index 86e8f0b2537b..8f021783a929 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) > return *res; > } > > -extern struct builtin_fw __start_builtin_fw[]; > -extern struct builtin_fw __end_builtin_fw[]; > +extern struct builtin_fw __start_builtin_fw[] __default_visibility; > +extern struct builtin_fw __end_builtin_fw[] __default_visibility; > > bool get_builtin_firmware(struct cpio_data *cd, const char *name) > { <-- snip...
2014 Dec 08
2
[LLVMdev] Incorrect loop optimization when building the Linux kernel
...cky <nicholas at mxc.ca> wrote: > Chengyu Song wrote: > >> It's difficult to say without a full example, but I'm very suspicious >>> of those global declarations. I think the compiler would be entirely >>> justified in assuming you could *never* get from __start_builtin_fw to >>> __end_builtin_fw, let alone on the first iteration: they're distinct >>> array objects and by definition (within C99) can't overlap. >>> >> >> I think this should be the root cause. Once I changed the declaration to >> pointers (instead of...
2017 Oct 18
0
[PATCH v1 15/27] compiler: Option to default to hidden symbols
...e8f0b2537b..8f021783a929 100644 >> --- a/arch/x86/kernel/cpu/microcode/core.c >> +++ b/arch/x86/kernel/cpu/microcode/core.c >> @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) >> return *res; >> } >> >> -extern struct builtin_fw __start_builtin_fw[]; >> -extern struct builtin_fw __end_builtin_fw[]; >> +extern struct builtin_fw __start_builtin_fw[] __default_visibility; >> +extern struct builtin_fw __end_builtin_fw[] __default_visibility; >> >> bool get_builtin_firmware(struct cpio_data *cd, const char *name) &g...
2017 Oct 11
32
[PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends
2017 Oct 11
32
[PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends
2018 Mar 13
32
[PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce
2018 Mar 13
32
[PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce
2017 Oct 04
28
x86: PIE support and option to extend KASLR randomization
These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to
2017 Oct 04
28
x86: PIE support and option to extend KASLR randomization
These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to
2018 May 23
33
[PATCH v3 00/27] x86: PIE support and option to extend KASLR randomization
Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace