[PATCH v5 01/13] buildid: Only consider GNU notes for build ID parsing
Some kernel elf files have various notes that also happen to have an elf
note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
"GNU". For example, this note trips up the existing logic:
Owner Data size Description
Xen0x0008 Unknown note type: (0x0003) description data: 00 00 00
ff80
Let's make sure that it is a GNU note when parsing the build ID so that
we can use this function to parse a vmlinux's build ID too.
Reported-by: Petr Mladek
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Fixes: bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib")
Tested-by: Petr Mladek
Signed-off-by: Stephen Boyd
---
lib/buildid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/buildid.c b/lib/buildid.c
index 6156997c3895..e014636ec3eb 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -31,6 +31,7 @@ static inline int parse_build_id(void *page_addr,
if (nhdr->n_type == BUILD_ID &&
nhdr->n_namesz == sizeof("GNU") &&
+ !strcmp((char *)(nhdr + 1), "GNU") &&
nhdr->n_descsz > 0 &&
nhdr->n_descsz <= BUILD_ID_SIZE_MAX) {
memcpy(build_id,
--
https://chromeos.dev
[PATCH 5.11 019/122] remoteproc: pru: Fix loading of GNU Binutils ELF
From: Dimitar Dimitrov
[ Upstream commit e6d9423d31b2f9bdd0220fd0584e3bb6ed2c4e52 ]
PRU port of GNU Binutils lacks support for separate address spaces.
PRU IRAM addresses are marked with artificial offset to differentiate
them from DRAM addresses. Hence remoteproc must mask IRAM addresses
coming from GNU ELF in order to get the true hardware address.
PRU firmware used for testing was the example in:
https://github.com/dinuxbg/pru-gcc-examples/tree/master/blinking-led/pru
Signed-off-by: Dimitar Dimitrov
Link: https://lore.kernel.org/r/20201230105005.30492-1-dimi...@dinux.eu
Signed-off-by: Bjorn Andersson
Signed-off-by: Sasha Levin
---
drivers/remoteproc/pru_rproc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 16979c1cd2f4..dcb380e868df 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -450,6 +450,24 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da,
size_t len)
if (len == 0)
return NULL;
+ /*
+* GNU binutils do not support multiple address spaces. The GNU
+* linker's default linker script places IRAM at an arbitrary high
+* offset, in order to differentiate it from DRAM. Hence we need to
+* strip the artificial offset in the IRAM addresses coming from the
+* ELF file.
+*
+* The TI proprietary linker would never set those higher IRAM address
+* bits anyway. PRU architecture limits the program counter to 16-bit
+* word-address range. This in turn corresponds to 18-bit IRAM
+* byte-address range for ELF.
+*
+* Two more bits are added just in case to make the final 20-bit mask.
+* Idea is to have a safeguard in case TI decides to add banking
+* in future SoCs.
+*/
+ da &= 0xf;
+
if (da >= PRU_IRAM_DA &&
da + len <= PRU_IRAM_DA + pru->mem_regions[PRU_IOMEM_IRAM].size) {
offset = da - PRU_IRAM_DA;
--
2.30.2
Re: [next] aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
On Fri, Apr 16, 2021 at 08:45:04PM +0530, Naresh Kamboju wrote: > The arm64 allnoconfig build failed on linux -next tag 20210416 > fpsimd.c:(.text+0x144): undefined reference to `sve_load_state' > aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function `fpsimd_save': > fpsimd.c:(.text+0x1f8): undefined reference to `sve_get_vl' > aarch64-linux-gnu-ld: fpsimd.c:(.text+0x230): undefined reference to > `sve_save_state' This was already reported and fixed yesterday. signature.asc Description: PGP signature
[next] aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
The arm64 allnoconfig build failed on linux -next tag 20210416 kernel/sched/fair.c:8428:13: warning: 'update_nohz_stats' defined but not used [-Wunused-function] static bool update_nohz_stats(struct rq *rq) ^ aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected! aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected! aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function `task_fpsimd_load': fpsimd.c:(.text+0x144): undefined reference to `sve_load_state' aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function `fpsimd_save': fpsimd.c:(.text+0x1f8): undefined reference to `sve_get_vl' aarch64-linux-gnu-ld: fpsimd.c:(.text+0x230): undefined reference to `sve_save_state' make[1]: *** [/builds/linux/Makefile:1277: vmlinux] Error 1 make[1]: Target '__all' not remade because of errors. make: *** [Makefile:222: __sub-make] Error 2 make: Target '__all' not remade because of errors. Reported-by: Naresh Kamboju steps to reproduce: # TuxMake is a command line tool and Python library that provides # portable and repeatable Linux kernel builds across a variety of # architectures, toolchains, kernel configurations, and make targets. # # TuxMake supports the concept of runtimes. # See https://docs.tuxmake.org/runtimes/, for that to work it requires # that you install podman or docker on your system. # # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation. tuxmake --runtime podman --target-arch arm64 --toolchain gcc-8 --kconfig allnoconfig metadata: - git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_describe: next-20210415 kconfig: allnoconfig target_arch: arm64 toolchain: gcc-8 -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v4 01/13] buildid: Only consider GNU notes for build ID parsing
On Fri 2021-04-09 18:52:48, Stephen Boyd wrote:
> Some kernel elf files have various notes that also happen to have an elf
> note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
> "GNU". For example, this note trips up the existing logic:
>
> Owner Data size Description
> Xen0x0008 Unknown note type: (0x0003) description data: 00 00
> 00 ff80 ffff
>
> Let's make sure that it is a GNU note when parsing the build ID so that
> we can use this function to parse a vmlinux's build ID too.
>
> Reported-by: Petr Mladek
> Cc: Jiri Olsa
> Cc: Alexei Starovoitov
> Cc: Jessica Yu
> Cc: Evan Green
> Cc: Hsin-Yi Wang
> Fixes: bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib")
> Signed-off-by: Stephen Boyd
Tested-by: Petr Mladek
Best Regards,
Petr
[PATCH AUTOSEL 5.11 08/51] remoteproc: pru: Fix loading of GNU Binutils ELF
From: Dimitar Dimitrov
[ Upstream commit e6d9423d31b2f9bdd0220fd0584e3bb6ed2c4e52 ]
PRU port of GNU Binutils lacks support for separate address spaces.
PRU IRAM addresses are marked with artificial offset to differentiate
them from DRAM addresses. Hence remoteproc must mask IRAM addresses
coming from GNU ELF in order to get the true hardware address.
PRU firmware used for testing was the example in:
https://github.com/dinuxbg/pru-gcc-examples/tree/master/blinking-led/pru
Signed-off-by: Dimitar Dimitrov
Link: https://lore.kernel.org/r/20201230105005.30492-1-dimi...@dinux.eu
Signed-off-by: Bjorn Andersson
Signed-off-by: Sasha Levin
---
drivers/remoteproc/pru_rproc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 2667919d76b3..5fad787ba012 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -450,6 +450,24 @@ static void *pru_i_da_to_va(struct pru_rproc *pru, u32 da,
size_t len)
if (len == 0)
return NULL;
+ /*
+* GNU binutils do not support multiple address spaces. The GNU
+* linker's default linker script places IRAM at an arbitrary high
+* offset, in order to differentiate it from DRAM. Hence we need to
+* strip the artificial offset in the IRAM addresses coming from the
+* ELF file.
+*
+* The TI proprietary linker would never set those higher IRAM address
+* bits anyway. PRU architecture limits the program counter to 16-bit
+* word-address range. This in turn corresponds to 18-bit IRAM
+* byte-address range for ELF.
+*
+* Two more bits are added just in case to make the final 20-bit mask.
+* Idea is to have a safeguard in case TI decides to add banking
+* in future SoCs.
+*/
+ da &= 0xf;
+
if (da >= PRU_IRAM_DA &&
da + len <= PRU_IRAM_DA + pru->mem_regions[PRU_IOMEM_IRAM].size) {
offset = da - PRU_IRAM_DA;
--
2.30.2
[PATCH v4 01/13] buildid: Only consider GNU notes for build ID parsing
Some kernel elf files have various notes that also happen to have an elf
note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
"GNU". For example, this note trips up the existing logic:
Owner Data size Description
Xen0x0008 Unknown note type: (0x0003) description data: 00 00 00
ff80
Let's make sure that it is a GNU note when parsing the build ID so that
we can use this function to parse a vmlinux's build ID too.
Reported-by: Petr Mladek
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Fixes: bd7525dacd7e ("bpf: Move stack_map_get_build_id into lib")
Signed-off-by: Stephen Boyd
---
lib/buildid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/buildid.c b/lib/buildid.c
index 6156997c3895..e014636ec3eb 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -31,6 +31,7 @@ static inline int parse_build_id(void *page_addr,
if (nhdr->n_type == BUILD_ID &&
nhdr->n_namesz == sizeof("GNU") &&
+ !strcmp((char *)(nhdr + 1), "GNU") &&
nhdr->n_descsz > 0 &&
nhdr->n_descsz <= BUILD_ID_SIZE_MAX) {
memcpy(build_id,
--
https://chromeos.dev
aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
Hi Kees, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1678e493d530e7977cce34e59a86bb86f3c5631e commit: be2881824ae9eb92a35b094f734f9ca7339ddf6d arm64/build: Assert for unwanted sections date: 7 months ago config: arm64-randconfig-r033-20210401 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be2881824ae9eb92a35b094f734f9ca7339ddf6d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout be2881824ae9eb92a35b094f734f9ca7339ddf6d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: -z norelro ignored >> aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected! >> aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected! aarch64-linux-gnu-ld: security/apparmor/lsm.o: in function `param_get_mode': lsm.c:(.text+0x460): undefined reference to `stpcpy' aarch64-linux-gnu-ld: security/apparmor/lsm.o: in function `param_get_audit': lsm.c:(.text+0x8cc): undefined reference to `stpcpy' aarch64-linux-gnu-ld: drivers/xen/sys-hypervisor.o: in function `buildid_show': sys-hypervisor.c:(.text+0x52c): undefined reference to `stpcpy' aarch64-linux-gnu-ld: drivers/tty/tty_io.o: in function `tty_line_name': tty_io.c:(.text+0x7760): undefined reference to `stpcpy' aarch64-linux-gnu-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x2ff0): undefined reference to `rcar_lvds_clk_enable' aarch64-linux-gnu-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x3810): undefined reference to `rcar_lvds_clk_disable' aarch64-linux-gnu-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function `rcar_du_init': rcar_du_drv.c:(.init.text+0x1c): undefined reference to `rcar_du_of_init' aarch64-linux-gnu-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in function `rcar_du_encoder_init': rcar_du_encoder.c:(.text+0x204): undefined reference to `rcar_lvds_dual_link' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Merge Linux and Gnu as Inu? Was Re: For those who did not get this yet, Fair Pay discussion is over, and concluded with LCPU.
Even better Inu OS, and Inu Licence, merges the relevant parts of Linux and Gnu, drops the X and rejects other irrelevant parts. This will be the angle I support. Serenity. Ywe Cærlyn https://www.youtube.com/channel/UC3BcyFY1Bphc7smGH-IGLVw/featured Den 17.03.2021 10:28, skrev Ywe Cærlyn: Something that occured to me also, why not just change licence to NiX licence? NiX is a generally known name of open source unix derivative variants. Serenity. Den 17.03.2021 08:14, skrev Ywe Cærlyn: I got some mails on some old posts here, please update: Fair Pay discussion is over, and concluded with LCPU. My media chan is here: https://www.youtube.com/channel/UC3BcyFY1Bphc7smGH-IGLVw Bit Qabbi, which always has been about the monotheistic angle, now also with the term Qabbi, taking inspiration from the muslim shaped Qaba, for design. Knowing the muslim debate follows, we have made a joke reply to this, seeing that it is mostly based in a deviant Eid, which I am not interested in. https://www.youtube.com/channel/UCDDmHQv0dTHPjdwJwKrjLqQ A discussion on reality goes to the standard expression of Alla, and this should then be the goal, and is already on my projects. Trance actually was this in the 90s, but when it reached that stage, many became confused, and it mostly failed. (While it did actually represent reality in media a few times). I was ready for this and DID become a muslim. LCPU representing natural progression in computing space. Serenity, Ywe Cærlyn (Best read in Cursive).
RE: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
From: Valdis Kletnieks > Sent: 18 March 2021 11:56 > > On Thu, 18 Mar 2021 11:41:29 -, David Laight said: > > > That gcc bug just implies you need a space after "xxx". > > That is easily fixable in the sources. > > It's not quite that simple. > >In file included from > /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27, > from > /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31, > from > /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23, > from scripts/gcc-plugins/gcc-common.h:9, > from scripts/gcc-plugins/latent_entropy_plugin.c:78: > >> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21: > >> warning: invalid suffix on > literal; C++11 requires a space between literal and string macro > [-Wliteral-suffix] >fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ > > The problem isn't in a kernel source file... ... Could you pass -Wno-literal-suffix on plugin builds? Might be less faff than changing the -std=xxx' parameter. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
On Thu, 18 Mar 2021 11:41:29 -, David Laight said: > That gcc bug just implies you need a space after "xxx". > That is easily fixable in the sources. It's not quite that simple. In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27, from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31, from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23, from scripts/gcc-plugins/gcc-common.h:9, from scripts/gcc-plugins/latent_entropy_plugin.c:78: >> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21: >> warning: invalid suffix on literal; C++11 requires a space between literal >> and string macro [-Wliteral-suffix] fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ The problem isn't in a kernel source file... To quote an earlier message of mine: > It looks like it's not a kernel source tree issue, it's a g++ issue fixed in > g++ 6 and later. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 > And it looks like there was an intent to backport it to 4.9 and 5.4: > https://gcc.gnu.org/legacy-ml/gcc-patches/2016-02/msg01409.html > The bugtracker doesn't show an equivalent for 69959 being closed against > 4.9.x or 5.[56], > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63254 has a patch for one of the > gcc-supplied files that tosses the warning, but that way lies madness... pgpKAMpPEyXho.pgp Description: PGP signature
Re: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
On Thu, 18 Mar 2021 18:07:28 +0900, Masahiro Yamada said: > We can require GCC 6+ for building GCC plugins. > + depends on CC_IS_GCC && GCC_VERSION >= 6 I'd be OK with that personally, but the question is whether any gcc 4.9 or 5.x users are using plugins. That's a bit above my pay grade. Kees? Do we have any data on that? (All I know is that there is at least one, because they tripped over the GCC bug that prompted the second patch) > BTW, the commit message mentions that > the issues only happen on GCC 4 and 5, > but the added code was: > > GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98) > > instead of > > GCC_FLAVOR = $(call cc-ifversion, -ge, 600, 11, 98) > > So, this patch is also requiring to cover two standards: > > GCC_VERSION >= 11 : -std=gnu++11 > GCC_VERSION < 11 : -std=gnu++98 I chose 1100 so that everything from 4.9 to 10 would keep getting handed gnu++98 the way they had been, and only change it for gcc11. pgpWrthr3a1BK.pgp Description: PGP signature
RE: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
From: Valdis Kletnieks > Sent: 18 March 2021 06:02 > > On Wed, 17 Mar 2021 22:52:56 -0700, Kees Cook said: > > On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis KlDtnieks wrote: > > > It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but > > > due to a gcc bug fixed in gcc6, throw errors during the build. > > > The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 > > > > > > Version the option based on what gcc we're using. > > > > Is there a better way to detect this than with version checking? > > Not really. gcc 11 needs --std=gnu++11 to build it. And although > gcc4 and gcc5 *claim* to support it, there's a known bug, so we *can't* > feed gnu++11 to them. We can check versions.. That gcc bug just implies you need a space after "xxx". That is easily fixable in the sources. Is there another problem? (Apart from the standards committee breaking everything again.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
On Thu, Mar 18, 2021 at 3:26 PM Miguel Ojeda wrote: > > On Thu, Mar 18, 2021 at 7:03 AM Valdis Klētnieks > wrote: > > > > Or declare that gcc6 is the minimum for building the kernel. > > Cc'ing some interested people in raising GCC's version for one reason > or another, so that we put this as another one in the pile of reasons > :-) > > https://lore.kernel.org/lkml/CAHk-=wjgvt1ei72btreh5fgfqykvh-ayt56-7ybt8lcprj7...@mail.gmail.com/ > > Cheers, > Miguel Previously we were discussing raising the min GCC version 5.x, but not further at this point of time. We can require GCC 6+ for building GCC plugins. --- a/scripts/gcc-plugins/Kconfig +++ b/scripts/gcc-plugins/Kconfig @@ -8,7 +8,7 @@ config HAVE_GCC_PLUGINS menuconfig GCC_PLUGINS bool "GCC plugins" depends on HAVE_GCC_PLUGINS - depends on CC_IS_GCC + depends on CC_IS_GCC && GCC_VERSION >= 6 depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h) default y help BTW, the commit message mentions that the issues only happen on GCC 4 and 5, but the added code was: GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98) instead of GCC_FLAVOR = $(call cc-ifversion, -ge, 600, 11, 98) So, this patch is also requiring to cover two standards: GCC_VERSION >= 11 : -std=gnu++11 GCC_VERSION < 11 : -std=gnu++98 -- Best Regards Masahiro Yamada
Re: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
On Thu, Mar 18, 2021 at 7:03 AM Valdis Klētnieks wrote: > > Or declare that gcc6 is the minimum for building the kernel. Cc'ing some interested people in raising GCC's version for one reason or another, so that we put this as another one in the pile of reasons :-) https://lore.kernel.org/lkml/CAHk-=wjgvt1ei72btreh5fgfqykvh-ayt56-7ybt8lcprj7...@mail.gmail.com/ Cheers, Miguel
Re: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
On Wed, 17 Mar 2021 22:52:56 -0700, Kees Cook said: > On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis KlÄtnieks wrote: > > It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but > > due to a gcc bug fixed in gcc6, throw errors during the build. > > The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 > > > > Version the option based on what gcc we're using. > > Is there a better way to detect this than with version checking? Not really. gcc 11 needs --std=gnu++11 to build it. And although gcc4 and gcc5 *claim* to support it, there's a known bug, so we *can't* feed gnu++11 to them. We can check versions.. Or heave gcc-plugins over the side entirely.. Or declare that gcc6 is the minimum for building the kernel. But if we support gcc4/5 *and* gcc11 to build gcc-plugins, we have to version-check. (Unrelated - the patch has grown a merge conflict since I sent it, let me know if you want an updated one, or if it's OK as is pgpP_B8IN3TEc.pgp Description: PGP signature
Re: [PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis Klētnieks wrote:
> It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
> due to a gcc bug fixed in gcc6, throw errors during the build.
> The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
>
> Version the option based on what gcc we're using.
Is there a better way to detect this than with version checking?
-Kees
>
> Signed-off-by: Valdis Kletnieks
> Fixes: 27c287b41659 ("gcc-plugins: fix gcc 11 indigestion with plugins...")
> ---
> diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
> index b5487cce69e8..cc779973724a 100644
> --- a/scripts/gcc-plugins/Makefile
> +++ b/scripts/gcc-plugins/Makefile
> @@ -21,8 +21,11 @@ always-y += $(GCC_PLUGIN)
>
> GCC_PLUGINS_DIR = $(shell $(CC) -print-file-name=plugin)
>
> +# need gnu++11 for gcc 11, but 4.9 and 5.4 need gnu++98
> +GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98)
> +
> plugin_cxxflags = -Wp,-MMD,$(depfile) $(KBUILD_HOSTCXXFLAGS) -fPIC \
> --I $(GCC_PLUGINS_DIR)/include -I $(obj) -std=gnu++11 \
> +-I $(GCC_PLUGINS_DIR)/include -I $(obj)
> -std=gnu++$(GCC_FLAVOR) \
> -fno-rtti -fno-exceptions -fasynchronous-unwind-tables \
> -ggdb -Wno-narrowing -Wno-unused-variable \
> -Wno-format-diag
>
>
--
Kees Cook
[PATCH v2 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
When building with LLVM_IAS=1, there is no point to specifying '--prefix=' because that flag is only used to find GNU cross tools, which will not be used indirectly when using the integrated assembler. All of the tools are invoked directly from PATH or a full path specified via the command line, which does not depend on the value of '--prefix='. Sharing commands to reproduce issues becomes a little bit easier without a '--prefix=' value because that '--prefix=' value is specific to a user's machine due to it being an absolute path. Some further notes from Fangrui Song: clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). objcopy is only used for GNU as assembled object files. With integrated assembler, the object file streamer creates .o and .dwo simultaneously. With GNU as, two objcopy commands are needed to extract .debug*.dwo to .dwo files && another command to remove .debug*.dwo sections. A small consequence of this change (to keep things simple) is that '--prefix=' will always be specified now, even with a native build, when it was not before. This should not be an issue due to the way that the Makefile searches for the prefix (based on elfedit's location). This ends up improving the experience for host builds because PATH is better respected and matches GCC's behavior more closely. See the below thread for more details: https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/ Signed-off-by: Nathan Chancellor --- v1 -> v2: * Fix position of -no-integrated-as flag to fix native build (thanks to Masahiro for catching it and sorry for the breakage). * Add Fangrui's comments about what GNU binaries clang can spawn at Masahiro's request. * Reword commit message. I did not carry tags forward so that people could re-review and test. Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 182e93d91198..15292a6d63f5 100644 --- a/Makefile +++ b/Makefile @@ -566,11 +566,11 @@ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) ifneq ($(CROSS_COMPILE),) CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) -GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) -CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) endif ifneq ($(LLVM_IAS),1) CLANG_FLAGS+= -no-integrated-as +GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) +CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) endif CLANG_FLAGS+= -Werror=unknown-warning-option KBUILD_CFLAGS += $(CLANG_FLAGS) -- 2.31.0.rc1
Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
On Wed, Mar 10, 2021 at 4:55 AM Masahiro Yamada wrote: > > On Wed, Mar 3, 2021 at 6:07 AM Nathan Chancellor wrote: > > > > When building with LLVM_IAS=1, there is no point to specifying > > '--prefix=' because that flag is only used to find the cross assembler, > > which is clang itself when building with LLVM_IAS=1. All of the other > > tools are invoked directly from PATH or a full path specified via the > > command line, which does not depend on the value of '--prefix='. > > > > Sharing commands to reproduce issues becomes a little bit easier without > > a '--prefix=' value because that '--prefix=' value is specific to a > > user's machine due to it being an absolute path. > > > > Signed-off-by: Nathan Chancellor > > > I was tricked by a couple of Reviewed-by/Tested-by tags. > > With this patch applied, the code looks as follows: > > > ifneq ($(CROSS_COMPILE),) > CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > ifneq ($(LLVM_IAS),1) > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > CLANG_FLAGS += -no-integrated-as > endif > endif > > > For the native build (empty CROSS_COMPILE), > you cannot add -no-integrated-as. > > > I dropped this from my tree. > > > > Is the correct code as follows? > > > ifneq ($(LLVM_IAS),1) > CLANG_FLAGS += -no-integrated-as > ifneq ($(CROSS_COMPILE),) > CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > endif > endif > > > > If you send v2, can you include comments from Fangrui Song? Fangrui Song: clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). objcopy is only used for GNU as assembled object files. With integrated assembler, the object file streamer creates .o and .dwo simultaneously. With GNU as, two objcopy commands are needed to extract .debug*.dwo to .dwo files && another command to remove .debug*.dwo sections. I did not know the objtool part, and I think it is worth recording. -- Best Regards Masahiro Yamada
Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
On Wed, Mar 3, 2021 at 6:07 AM Nathan Chancellor wrote: > > When building with LLVM_IAS=1, there is no point to specifying > '--prefix=' because that flag is only used to find the cross assembler, > which is clang itself when building with LLVM_IAS=1. All of the other > tools are invoked directly from PATH or a full path specified via the > command line, which does not depend on the value of '--prefix='. > > Sharing commands to reproduce issues becomes a little bit easier without > a '--prefix=' value because that '--prefix=' value is specific to a > user's machine due to it being an absolute path. > > Signed-off-by: Nathan Chancellor I was tricked by a couple of Reviewed-by/Tested-by tags. With this patch applied, the code looks as follows: ifneq ($(CROSS_COMPILE),) CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) ifneq ($(LLVM_IAS),1) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) CLANG_FLAGS += -no-integrated-as endif endif For the native build (empty CROSS_COMPILE), you cannot add -no-integrated-as. I dropped this from my tree. Is the correct code as follows? ifneq ($(LLVM_IAS),1) CLANG_FLAGS += -no-integrated-as ifneq ($(CROSS_COMPILE),) CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) endif endif > --- > Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index c20f0ad8be73..0413b8c594cd 100644 > --- a/Makefile > +++ b/Makefile > @@ -566,12 +566,12 @@ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | > head -n 1 | sed 's/\#//g > ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) > ifneq ($(CROSS_COMPILE),) > CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) > +ifneq ($(LLVM_IAS),1) > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > -endif > -ifneq ($(LLVM_IAS),1) > CLANG_FLAGS+= -no-integrated-as > endif > +endif > CLANG_FLAGS+= -Werror=unknown-warning-option > KBUILD_CFLAGS += $(CLANG_FLAGS) > KBUILD_AFLAGS += $(CLANG_FLAGS) > -- > 2.31.0.rc0.75.gec125d1bc1 > -- Best Regards Masahiro Yamada
[PATCH RESEND] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
due to a gcc bug fixed in gcc6, throw errors during the build.
The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Version the option based on what gcc we're using.
Signed-off-by: Valdis Kletnieks
Fixes: 27c287b41659 ("gcc-plugins: fix gcc 11 indigestion with plugins...")
---
diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index b5487cce69e8..cc779973724a 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -21,8 +21,11 @@ always-y += $(GCC_PLUGIN)
GCC_PLUGINS_DIR = $(shell $(CC) -print-file-name=plugin)
+# need gnu++11 for gcc 11, but 4.9 and 5.4 need gnu++98
+GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98)
+
plugin_cxxflags= -Wp,-MMD,$(depfile) $(KBUILD_HOSTCXXFLAGS) -fPIC \
- -I $(GCC_PLUGINS_DIR)/include -I $(obj) -std=gnu++11 \
+ -I $(GCC_PLUGINS_DIR)/include -I $(obj)
-std=gnu++$(GCC_FLAVOR) \
-fno-rtti -fno-exceptions -fasynchronous-unwind-tables \
-ggdb -Wno-narrowing -Wno-unused-variable \
-Wno-format-diag
Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
On Tue, Mar 2, 2021 at 2:09 PM Nick Desaulniers wrote: > > On Tue, Mar 2, 2021 at 2:02 PM Fangrui Song wrote: > > > > On 2021-03-02, Nathan Chancellor wrote: > > >When building with LLVM_IAS=1, there is no point to specifying > > >'--prefix=' because that flag is only used to find the cross assembler, > > >which is clang itself when building with LLVM_IAS=1. All of the other > > >tools are invoked directly from PATH or a full path specified via the > > >command line, which does not depend on the value of '--prefix='. > > > > > >Sharing commands to reproduce issues becomes a little bit easier without > > >a '--prefix=' value because that '--prefix=' value is specific to a > > >user's machine due to it being an absolute path. > > > > > >Signed-off-by: Nathan Chancellor > > > > Reviewed-by: Fangrui Song > > > > clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU > > objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). > > But -g get's set via CONFIG_DEBUG_INFO and -gsplit-dwarf by > DEBUG_INFO_SPLIT. So if we say: > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang LLVM_IAS=1 > > So cross compile, use clang, use the integrated assembler (ie. with > this change, don't set --prefix), with either of the two above > configs, which objcopy get's exec'd? Ok, I spoke to Fangrui more offline, and probably misread his response. From our chat: ``` Fangrui: objcopy is only used for GNU as assembled object files With integrated assembler, the object file streamer creates .o and .dwo simultaneously With GNU as, two objcopy commands are needed to extract .debug*.dwo to .dwo files &&& another command to remove .debug*.dwo sections ``` Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers I ran this series through a mix of LLVM=1 vs CC=clang, LLVM_IAS=1 vs unset, CROSS_COMPILE vs not, without issue. > > > > > With LLVM_IAS=1, these cases are ruled out. > > > > -- > Thanks, > ~Nick Desaulniers -- Thanks, ~Nick Desaulniers
Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
On Tue, Mar 2, 2021 at 2:02 PM Fangrui Song wrote: > > On 2021-03-02, Nathan Chancellor wrote: > >When building with LLVM_IAS=1, there is no point to specifying > >'--prefix=' because that flag is only used to find the cross assembler, > >which is clang itself when building with LLVM_IAS=1. All of the other > >tools are invoked directly from PATH or a full path specified via the > >command line, which does not depend on the value of '--prefix='. > > > >Sharing commands to reproduce issues becomes a little bit easier without > >a '--prefix=' value because that '--prefix=' value is specific to a > >user's machine due to it being an absolute path. > > > >Signed-off-by: Nathan Chancellor > > Reviewed-by: Fangrui Song > > clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU > objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). But -g get's set via CONFIG_DEBUG_INFO and -gsplit-dwarf by DEBUG_INFO_SPLIT. So if we say: $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang LLVM_IAS=1 So cross compile, use clang, use the integrated assembler (ie. with this change, don't set --prefix), with either of the two above configs, which objcopy get's exec'd? > > With LLVM_IAS=1, these cases are ruled out. -- Thanks, ~Nick Desaulniers
Re: [PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
On 2021-03-02, Nathan Chancellor wrote: When building with LLVM_IAS=1, there is no point to specifying '--prefix=' because that flag is only used to find the cross assembler, which is clang itself when building with LLVM_IAS=1. All of the other tools are invoked directly from PATH or a full path specified via the command line, which does not depend on the value of '--prefix='. Sharing commands to reproduce issues becomes a little bit easier without a '--prefix=' value because that '--prefix=' value is specific to a user's machine due to it being an absolute path. Signed-off-by: Nathan Chancellor Reviewed-by: Fangrui Song clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). With LLVM_IAS=1, these cases are ruled out.
[PATCH 2/2] Makefile: Only specify '--prefix=' when building with clang + GNU as
When building with LLVM_IAS=1, there is no point to specifying '--prefix=' because that flag is only used to find the cross assembler, which is clang itself when building with LLVM_IAS=1. All of the other tools are invoked directly from PATH or a full path specified via the command line, which does not depend on the value of '--prefix='. Sharing commands to reproduce issues becomes a little bit easier without a '--prefix=' value because that '--prefix=' value is specific to a user's machine due to it being an absolute path. Signed-off-by: Nathan Chancellor --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index c20f0ad8be73..0413b8c594cd 100644 --- a/Makefile +++ b/Makefile @@ -566,12 +566,12 @@ CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) ifneq ($(CROSS_COMPILE),) CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) +ifneq ($(LLVM_IAS),1) GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) -endif -ifneq ($(LLVM_IAS),1) CLANG_FLAGS+= -no-integrated-as endif +endif CLANG_FLAGS+= -Werror=unknown-warning-option KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_AFLAGS += $(CLANG_FLAGS) -- 2.31.0.rc0.75.gec125d1bc1
Re: [PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
On 2021.02.22 06:22:37 -0800, Randy Dunlap wrote: > On 2/22/21 6:21 AM, Randy Dunlap wrote: > > On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote: > >> > >> s/negtive/negative/ > >> s/possilbe/possible/ > >> > >> Signed-off-by: Bhaskar Chowdhury > > > > Acked-by: Randy Dunlap > > except the Subject has a typo in it. > s/gnu/gpu/ > And pls follow gvt subsys's subject line as drm/i915/gvt: xxx in future. I'll fix the title and queue this. Thanks! > >> --- > >> drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c > >> b/drivers/gpu/drm/i915/gvt/gtt.c > >> index 897c007ea96a..dc5834bf4de2 100644 > >> --- a/drivers/gpu/drm/i915/gvt/gtt.c > >> +++ b/drivers/gpu/drm/i915/gvt/gtt.c > >> @@ -1159,8 +1159,8 @@ static inline void > >> ppgtt_generate_shadow_entry(struct intel_gvt_gtt_entry *se, > >> * @vgpu: target vgpu > >> * @entry: target pfn's gtt entry > >> * > >> - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, > >> - * negtive if found err. > >> + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, > >> + * negative if found err. > >> */ > >> static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, > >>struct intel_gvt_gtt_entry *entry) > >> -- > > > > > > > -- > ~Randy > Reported-by: Randy Dunlap > ___ > intel-gvt-dev mailing list > intel-gvt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev signature.asc Description: PGP signature
Re: [PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
On 2/22/21 6:21 AM, Randy Dunlap wrote: > On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote: >> >> s/negtive/negative/ >> s/possilbe/possible/ >> >> Signed-off-by: Bhaskar Chowdhury > > Acked-by: Randy Dunlap except the Subject has a typo in it. s/gnu/gpu/ >> --- >> drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c >> index 897c007ea96a..dc5834bf4de2 100644 >> --- a/drivers/gpu/drm/i915/gvt/gtt.c >> +++ b/drivers/gpu/drm/i915/gvt/gtt.c >> @@ -1159,8 +1159,8 @@ static inline void ppgtt_generate_shadow_entry(struct >> intel_gvt_gtt_entry *se, >> * @vgpu: target vgpu >> * @entry: target pfn's gtt entry >> * >> - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, >> - * negtive if found err. >> + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, >> + * negative if found err. >> */ >> static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, >> struct intel_gvt_gtt_entry *entry) >> -- > > -- ~Randy Reported-by: Randy Dunlap
Re: [PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote: > > s/negtive/negative/ > s/possilbe/possible/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > index 897c007ea96a..dc5834bf4de2 100644 > --- a/drivers/gpu/drm/i915/gvt/gtt.c > +++ b/drivers/gpu/drm/i915/gvt/gtt.c > @@ -1159,8 +1159,8 @@ static inline void ppgtt_generate_shadow_entry(struct > intel_gvt_gtt_entry *se, > * @vgpu: target vgpu > * @entry: target pfn's gtt entry > * > - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, > - * negtive if found err. > + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, > + * negative if found err. > */ > static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, > struct intel_gvt_gtt_entry *entry) > -- -- ~Randy
[PATCH] drivers: gnu: drm: i915: gvt: Fixed couple of spellings in the file gtt.c
s/negtive/negative/ s/possilbe/possible/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/i915/gvt/gtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c index 897c007ea96a..dc5834bf4de2 100644 --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -1159,8 +1159,8 @@ static inline void ppgtt_generate_shadow_entry(struct intel_gvt_gtt_entry *se, * @vgpu: target vgpu * @entry: target pfn's gtt entry * - * Return 1 if 2MB huge gtt shadowing is possilbe, 0 if miscondition, - * negtive if found err. + * Return 1 if 2MB huge gtt shadowing is possible, 0 if miscondition, + * negative if found err. */ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu, struct intel_gvt_gtt_entry *entry) -- 2.26.2
Re: /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21: warning: invalid suffix on literal; C++11 requires a space between literal and string macro
On Sun, 14 Feb 2021 04:00:31 +0800, kernel test robot said: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: dcc0b49040c70ad827a7f3d58a21b01fdb14e749 > commit: 67a5a68013056cbcf0a647e36cb6f4622fb6a470 gcc-plugins: fix gcc 11 > indigestion with plugins... > date: 5 weeks ago > config: x86_64-randconfig-a001-20200622 (attached as .config) > compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 > reproduce (this is a W=1 build): > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67a5a68013056cbcf0a647e36cb6f4622fb6a470 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 67a5a68013056cbcf0a647e36cb6f4622fb6a470 > # save the attached .config to linux build tree > make W=1 ARCH=x86_64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All warnings (new ones prefixed by >>): > >In file included from > /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27, > from > /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-pugin.h:31, > from > /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23, > from scripts/gcc-plugins/gcc-common.h:9, > from scripts/gcc-plugins/latent_entropy_plugin.c:78: > >> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21: > >> warning: invalid suffix on literal; C++11 requires a space between literal > >> and string macro [-Wliteral-suffix] >fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ > ^ Kees: I already sent a patch for this on Jan 13, but apparently it didn't get pushed out.. pgpq5WHgo8LCc.pgp Description: PGP signature
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21: warning: invalid suffix on literal; C++11 requires a space between literal and string macro
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: dcc0b49040c70ad827a7f3d58a21b01fdb14e749
commit: 67a5a68013056cbcf0a647e36cb6f4622fb6a470 gcc-plugins: fix gcc 11
indigestion with plugins...
date: 5 weeks ago
config: x86_64-randconfig-a001-20200622 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67a5a68013056cbcf0a647e36cb6f4622fb6a470
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 67a5a68013056cbcf0a647e36cb6f4622fb6a470
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23,
from scripts/gcc-plugins/gcc-common.h:9,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
>> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21:
>> warning: invalid suffix on literal; C++11 requires a space between literal
>> and string macro [-Wliteral-suffix]
fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
^
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:170:24:
warning: invalid suffix on literal; C++11 requires a space between literal and
string macro [-Wliteral-suffix]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:48,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23,
from scripts/gcc-plugins/gcc-common.h:9,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
>> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/defaults.h:126:24: warning:
>> invalid suffix on literal; C++11 requires a space between literal and string
>> macro [-Wliteral-suffix]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^
>> cc1plus: warning: unrecognized command line option '-Wno-format-diag'
--
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23,
from scripts/gcc-plugins/gcc-common.h:9,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
>> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21:
>> warning: invalid suffix on literal; C++11 requires a space between literal
>> and string macro [-Wliteral-suffix]
fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
^
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:170:24:
warning: invalid suffix on literal; C++11 requires a space between literal and
string macro [-Wliteral-suffix]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:48,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23,
from scripts/gcc-plugins/gcc-common.h:9,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
>> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/defaults.h:126:24: warning:
>> invalid suffix on literal; C++11 requires a space between literal and string
>> macro [-Wliteral-suffix]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h:23,
from scripts/gcc-plugins/gcc-common.h:9,
from scripts/gcc-plugins/sancov_plugin.c:22:
>> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/config/elfos.h:102:21:
>> warnin
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/clk/clk-fsl-flexspi.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 6642d600b541b81931fb1ab0c041b0d68f77be7e commit: fcf77be87eacb8f305528d24d892dfcf15cf0341 clk: fsl-flexspi: new driver date: 8 weeks ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf77be87eacb8f305528d24d892dfcf15cf0341 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout fcf77be87eacb8f305528d24d892dfcf15cf0341 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-devres.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-legacy.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-of.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-cdev.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-mmio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-74xx-mmio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-adnp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-adp5588.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-altera.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-amd-fch.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-xgs-iproc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-bd70528.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-bd71828.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-bd9571mwv.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-cadence.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-dln2.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-dwapb.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-eic-sprd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-ftgpio010.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-grgpio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-gw-pld.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-kempld.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-logicvc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-lp3943.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-lp873x.o' being placed in section `.eh_frame'
Re: [kbuild-all] aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/trace_recursion_record.o' being placed in section `.eh_frame'
On Sun, Jan 31, 2021 at 10:09:22AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 > commit: 773c16705058e9be7b0f4ce124e89cd231c120a2 ftrace: Add recording of > functions that caused recursion > date: 3 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773c16705058e9be7b0f4ce124e89cd231c120a2 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 773c16705058e9be7b0f4ce124e89cd231c120a2 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot Sorry, kindly ignore this false positive > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/irq_sim.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/proc.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/cpuhotplug.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/msi.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/ipi.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/affinity.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/debugfs.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/update.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/sync.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/srcutree.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/rcuscale.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/refscale.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/tree.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/rcu_segcblist.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/mapping.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/direct.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/ops_helpers.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/dummy.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/coherent.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/swiotlb.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/pool.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/remap.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/fr
Re: [kbuild-all] aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/tty/serial/liteuart.o' being placed in section `.eh_frame'
On Sun, Jan 31, 2021 at 11:36:33AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 6642d600b541b81931fb1ab0c041b0d68f77be7e > commit: 1da81e5562fac8286567422cc56a7fbd0dc646d4 drivers/tty/serial: add > LiteUART driver > date: 3 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1da81e5562fac8286567422cc56a7fbd0dc646d4 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 1da81e5562fac8286567422cc56a7fbd0dc646d4 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot Sorry, kindly ignore this false positive. > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max77650-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8649.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8660.o' being placed in section `.eh_frame' > aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8925-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8952.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max77802-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max77826-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mcp16502.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mp8859.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mpq7920.o' being placed in section `.eh_frame' > aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mt6311-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mt6360-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mt6397-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/qcom-labibb-regulator.o' being placed in section > `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/qcom_spmi-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/palmas-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pca9450-regulator.o' being placed in section `.eh_frame' > aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pfuze100-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pv88060-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pv88090-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/tps51
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/tty/serial/liteuart.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 6642d600b541b81931fb1ab0c041b0d68f77be7e commit: 1da81e5562fac8286567422cc56a7fbd0dc646d4 drivers/tty/serial: add LiteUART driver date: 3 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1da81e5562fac8286567422cc56a7fbd0dc646d4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1da81e5562fac8286567422cc56a7fbd0dc646d4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max77650-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8649.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8660.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8925-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8952.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max77802-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max77826-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mcp16502.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mp8859.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mpq7920.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mt6311-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mt6360-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mt6397-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/qcom-labibb-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/qcom_spmi-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/palmas-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pca9450-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pfuze100-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pv88060-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pv88090-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/tps51632-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pcf50633-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/rpi-panel-attiny-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/r
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/trace_recursion_record.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 commit: 773c16705058e9be7b0f4ce124e89cd231c120a2 ftrace: Add recording of functions that caused recursion date: 3 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773c16705058e9be7b0f4ce124e89cd231c120a2 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 773c16705058e9be7b0f4ce124e89cd231c120a2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/irq_sim.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/proc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/cpuhotplug.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/msi.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/ipi.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/affinity.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/debugfs.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/update.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/sync.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/srcutree.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/rcuscale.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/refscale.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/tree.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/rcu_segcblist.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/mapping.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/direct.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/ops_helpers.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/dummy.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/coherent.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/swiotlb.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/pool.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/remap.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/freezer.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/profile.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/stacktrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/time/time.o' being placed in section `.eh_frame' aarch64-linux-gn
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/firmware/arm_scmi/voltage.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 commit: 2add5cacff3531e54c50b0832128299faa9f0563 firmware: arm_scmi: Add voltage domain management protocol support date: 2 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2add5cacff3531e54c50b0832128299faa9f0563 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 2add5cacff3531e54c50b0832128299faa9f0563 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/speakup_dectlk.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/speakup_decext.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/speakup_soft.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/buffers.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/devsynth.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/i18n.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/fakekey.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/main.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/keyhelp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/kobjects.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/selection.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/spk_ttyio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/synth.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/thread.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/varhandlers.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/core.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/bus.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/host.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/mmc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/mmc_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sd_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sdio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `sound/usb/implicit.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 commit: 9fddc15e803945a744f357a4d1c94301e1ed6681 ALSA: usb-audio: Factor out the implicit feedback quirk code date: 10 weeks ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9fddc15e803945a744f357a4d1c94301e1ed6681 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 9fddc15e803945a744f357a4d1c94301e1ed6681 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/intel_th/msu-sink.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/stm/core.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/stm/policy.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/stm/p_sys-t.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/stm/dummy_stm.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/stm/heartbeat.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/hwtracing/stm/ftrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/core.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/bcm-ocotp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/imx-iim.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/imx-ocotp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/qcom-spmi-sdam.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/rockchip-efuse.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/rockchip-otp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/uniphier-efuse.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/snvs_lpgpr.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/rave-sp-eeprom.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/zynqmp_nvmem.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/nvmem/sprd-efuse.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/fpga/fpga-mgr.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/fpga/stratix10-soc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/fpga/fpga-bridge.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/fpga/xilinx-pr-decoupler.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/fpga/fpga-region.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `d
Re: aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/media/platform/rockchip/rkisp1/rkisp1-capture.o' being placed in section `.eh_frame'
On Sun, Jan 31, 2021 at 03:52:15AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 0e9bcda5d286f4a26a5407bb38f55c55b453ecfb > commit: e6938cc1cb7763a363f62b78147f1f2fb972f49c media: rockchip: rkisp1: > destage Rockchip ISP1 driver > date: 3 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6938cc1cb7763a363f62b78147f1f2fb972f49c > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout e6938cc1cb7763a363f62b78147f1f2fb972f49c > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/input/input.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/input/input-compat.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/input/input-mt.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/input/input-poller.o' being placed in section `.eh_frame' https://lore.kernel.org/lkml/20210130004650.2682422-1-nat...@kernel.org/ Cheers, Nathan
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/media/platform/rockchip/rkisp1/rkisp1-capture.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0e9bcda5d286f4a26a5407bb38f55c55b453ecfb commit: e6938cc1cb7763a363f62b78147f1f2fb972f49c media: rockchip: rkisp1: destage Rockchip ISP1 driver date: 3 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6938cc1cb7763a363f62b78147f1f2fb972f49c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout e6938cc1cb7763a363f62b78147f1f2fb972f49c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/input.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/input-compat.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/input-mt.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/input-poller.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/ff-core.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/ff-memless.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/sparse-keymap.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/matrix-keymap.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/input-leds.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/mousedev.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/joydev.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/evbug.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_bus.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_driver.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f01.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_2d_sensor.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f03.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f11.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f12.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f34.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f34v7.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_f3a.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/input/rmi4/rmi_smbus.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/i2c/i2c-boardinfo.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/i2c/i2c-core-base.o' being place
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/ftrace.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bec4c2968fce2f44ce62d05288a633cd99a722eb commit: b3e5d80d0c48c0cc7bce56473672f4e6e1210910 arm64/build: Warn on orphan section placement date: 5 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout b3e5d80d0c48c0cc7bce56473672f4e6e1210910 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: -z norelro ignored aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/main.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/version.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/do_mounts.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/do_mounts_rd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/do_mounts_initrd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/initramfs.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/calibrate.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/init_task.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/debug-monitors.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/irq.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/fpsimd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/entry-common.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/process.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/ptrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/setup.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/signal.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/sys.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/stacktrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/time.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/traps.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/io.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/vdso.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/psci.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/cpu_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/insn.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: w
Re: aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/ftrace.o' being placed in section `.eh_frame'
On Sat, Jan 30, 2021 at 09:21:49AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: bec4c2968fce2f44ce62d05288a633cd99a722eb > commit: b3e5d80d0c48c0cc7bce56473672f4e6e1210910 arm64/build: Warn on orphan > section placement > date: 5 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout b3e5d80d0c48c0cc7bce56473672f4e6e1210910 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: -z norelro ignored >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/main.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/version.o' being placed in section `.eh_frame' > aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/do_mounts.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/do_mounts_rd.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/do_mounts_initrd.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/initramfs.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/calibrate.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `init/init_task.o' being placed in section `.eh_frame' https://lore.kernel.org/lkml/20210130004650.2682422-1-nat...@kernel.org/ Cheers, Nathan
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/sdei.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 76c057c84d286140c6c416c3b4ba832cd1d8984e commit: b3e5d80d0c48c0cc7bce56473672f4e6e1210910 arm64/build: Warn on orphan section placement date: 5 months ago config: arm64-randconfig-r034-20210128 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 48bdd676a1d1338c10541460bf5beb69ac17e451) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout b3e5d80d0c48c0cc7bce56473672f4e6e1210910 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.igot.plt' from `arch/arm64/kernel/head.o' being placed in section `.igot.plt' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/main.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/version.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/do_mounts.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/do_mounts_initrd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/initramfs.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/calibrate.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `init/init_task.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/debug-monitors.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/irq.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/fpsimd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/entry-common.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/process.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/ptrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/setup.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/signal.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/sys.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/stacktrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/time.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/traps.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/io.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/vdso.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/psci.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/cpu_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arch/arm64/kernel/insn.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `arc
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/ring_buffer.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 19c329f6808995b142b3966301f217c831e7cf31 commit: b3e5d80d0c48c0cc7bce56473672f4e6e1210910 arm64/build: Warn on orphan section placement date: 5 months ago config: arm64-randconfig-r006-20210118 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 95d146182fdf2315e74943b93fb3bb0cbafc5d89) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout b3e5d80d0c48c0cc7bce56473672f4e6e1210910 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.igot.plt' from `arch/arm64/kernel/head.o' being placed in section `.igot.plt' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/trace_clock.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/ring_buffer.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/ring_buffer_benchmark.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_output.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_seq.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_stat.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_printk.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/tracing_map.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_sched_switch.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_preemptirq.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_irqsoff.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_hwlat.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_nop.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_events.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_export.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_event_perf.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_events_filter.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_events_trigger.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_events_synth.o' being placed in section `.eh_frame' >> aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from >> `kernel/trace/trace_events_hist.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/bpf_trace
[PATCH] gcc-plugins: avoid errors with -std=gnu++11 on old gcc
It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
due to a gcc bug fixed in gcc6, throw errors during the build.
The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Version the option based on what gcc we're using.
Signed-off-by: Valdis Kletnieks
Fixes: 27c287b41659 ("gcc-plugins: fix gcc 11 indigestion with plugins...")
---
diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index b5487cce69e8..cc779973724a 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -21,8 +21,11 @@ always-y += $(GCC_PLUGIN)
GCC_PLUGINS_DIR = $(shell $(CC) -print-file-name=plugin)
+# need gnu++11 for gcc 11, but 4.9 and 5.4 need gnu++98
+GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98)
+
plugin_cxxflags= -Wp,-MMD,$(depfile) $(KBUILD_HOSTCXXFLAGS) -fPIC \
- -I $(GCC_PLUGINS_DIR)/include -I $(obj) -std=gnu++11 \
+ -I $(GCC_PLUGINS_DIR)/include -I $(obj)
-std=gnu++$(GCC_FLAVOR) \
-fno-rtti -fno-exceptions -fasynchronous-unwind-tables \
-ggdb -Wno-narrowing -Wno-unused-variable \
-Wno-format-diag
aarch64-linux-gnu-ld: drivers/clk/meson/g12a.o:undefined reference to `meson_vid_pll_div_ro_ops'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e37b12e4bb21e7c81732370b0a2b34bd196f380b commit: ba66a25536dd24b73d36e380c68593e95e4e06a8 arm64: meson: ship only the necessary clock controllers date: 6 weeks ago config: arm64-randconfig-r033-20201220 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project cee1e7d14f4628d6174b33640d502bff3b54ae45) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba66a25536dd24b73d36e380c68593e95e4e06a8 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout ba66a25536dd24b73d36e380c68593e95e4e06a8 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: -z norelro ignored >> aarch64-linux-gnu-ld: drivers/clk/meson/g12a.o:(.data+0x4ec8): undefined >> reference to `meson_vid_pll_div_ro_ops' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: Plumbers session on GNU+LLVM collab?
On 2020-07-09, 'Nick Desaulniers' via Clang Built Linux wrote: Hi Segher, Rasmus, and Ramana, I am working on finalizing a proposal for an LLVM microconference at plumbers, which is focusing on a lot of issues we currently face on the LLVM side. I'd really like to host a session with more GNU toolchain developers to discuss collaboration more. I was curious; are either of you planning on attending plumbers this year? If so, would such a session be interesting enough for you to attend? Looks like a good idea. I am interested. Perhaps Tom Stellard, Jeremy Bennett, Nathan Sidwell and Iain Sandoe have some ideas. They have a talk about GCC/LLVM collaboration https://gcc.gnu.org/wiki/cauldron2019#cauldron2019talks.GCC_LLVM_Collaboration_BoF I was curious too, who else we should explicitly invite? I ran a quick set analysis on who's contributed to both kernel and , and the list was much much bigger than I was expecting. https://gist.github.com/nickdesaulniers/5330eea6f46dea93e7766bb03311d474 89 contributors to both linux and llvm 283 linux+gcc 159 linux+binutils (No one to all four yet...also, not super scientific, since I'm using name+email for the set, and emails change. Point being I don't want to explicitly invite hundreds of people) Might be worth sending an email to g...@gcc.gnu.org as well. This month's archive: https://sourceware.org/pipermail/gcc/2020-July/
Re: [PATCH v2 4/4] perf-probe: Warn if the target function is GNU Indirect function
Em Fri, Jul 10, 2020 at 07:27:12PM +0530, Srikar Dronamraju escreveu: > * Masami Hiramatsu [2020-07-10 22:11:33]: > > > Warn if the probe target function is GNU indirect function (GNU_IFUNC) > > because it may not what the user want to probe. > > > > The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC ) > > is the dynamic solved symbol at runtime. IFUNC function is a selector > > which is invoked from the elf loader, but the symbol address of the > > function which will be modified by the IFUNC is same as the IFUNC in > > the symbol table. This can confuse users who is trying to probe on > > such functions. > > > > For example, the memcpy is one of IFUNC. > > > > # perf probe -x /lib64/libc-2.30.so -a memcpy > > # perf probe -l > > probe_libc:memcpy(on __new_memcpy_ifunc@x86_64/multiarch/memcpy.c in > > /usr/lib64/libc-2.30.so) > > > > the probe is put on a IFUNC. > > > > # perf record -e probe_libc:memcpy --call-graph dwarf -aR ./perf > > > > Thus, I decided to warn user when the perf probe detects the probe point > > is on the GNU IFUNC symbol. Someone who wants to probe an IFUNC symbol to > > debug the IFUNC function, they can ignore this warning. > > > > Reported-by: Andi Kleen > > Signed-off-by: Masami Hiramatsu > > Looks good to me. > > Reviewed-by: Srikar Dronamraju Thanks, applied. - Arnaldo
Re: [PATCH v2 4/4] perf-probe: Warn if the target function is GNU Indirect function
* Masami Hiramatsu [2020-07-10 22:11:33]:
> Warn if the probe target function is GNU indirect function (GNU_IFUNC)
> because it may not what the user want to probe.
>
> The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
> is the dynamic solved symbol at runtime. IFUNC function is a selector
> which is invoked from the elf loader, but the symbol address of the
> function which will be modified by the IFUNC is same as the IFUNC in
> the symbol table. This can confuse users who is trying to probe on
> such functions.
>
> For example, the memcpy is one of IFUNC.
>
> # perf probe -x /lib64/libc-2.30.so -a memcpy
> # perf probe -l
> probe_libc:memcpy(on __new_memcpy_ifunc@x86_64/multiarch/memcpy.c in
> /usr/lib64/libc-2.30.so)
>
> the probe is put on a IFUNC.
>
> # perf record -e probe_libc:memcpy --call-graph dwarf -aR ./perf
>
> Thus, I decided to warn user when the perf probe detects the probe point
> is on the GNU IFUNC symbol. Someone who wants to probe an IFUNC symbol to
> debug the IFUNC function, they can ignore this warning.
>
> Reported-by: Andi Kleen
> Signed-off-by: Masami Hiramatsu
Looks good to me.
Reviewed-by: Srikar Dronamraju
> ---
> Changes in v2:
>- Check GNU_IFUNC only for uprobe
>- Show function name instead of the address.
>- Update the warning message according to Andi's comment.
> ---
> tools/perf/util/probe-event.c |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 8cd1224e5f4c..679447f13c20 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -375,9 +375,13 @@ static int find_alternative_probe_point(struct debuginfo
> *dinfo,
>
> /* Find the address of given function */
> map__for_each_symbol_by_name(map, pp->function, sym) {
> - if (uprobes)
> + if (uprobes) {
> address = sym->start;
> - else
> + if (sym->type == STT_GNU_IFUNC)
> + pr_warning("Warning: The probe function (%s) is
> a GNU indirect function.\n"
> +"Consider identifying the final
> function used at run time and set the probe directly on that.\n",
> +pp->function);
> + } else
> address = map->unmap_ip(map, sym->start) - map->reloc;
> break;
> }
>
--
Thanks and Regards
Srikar Dronamraju
[PATCH v2 4/4] perf-probe: Warn if the target function is GNU Indirect function
Warn if the probe target function is GNU indirect function (GNU_IFUNC)
because it may not what the user want to probe.
The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
is the dynamic solved symbol at runtime. IFUNC function is a selector
which is invoked from the elf loader, but the symbol address of the
function which will be modified by the IFUNC is same as the IFUNC in
the symbol table. This can confuse users who is trying to probe on
such functions.
For example, the memcpy is one of IFUNC.
# perf probe -x /lib64/libc-2.30.so -a memcpy
# perf probe -l
probe_libc:memcpy(on __new_memcpy_ifunc@x86_64/multiarch/memcpy.c in
/usr/lib64/libc-2.30.so)
the probe is put on a IFUNC.
# perf record -e probe_libc:memcpy --call-graph dwarf -aR ./perf
# perf script
perf 1742 [000] 26201.715632: probe_libc:memcpy: (7fdaa53824c0)
7fdaa53824c0 __new_memcpy_ifunc+0x0 (inlined)
7fdaa5d4a980 elf_machine_rela+0x6c0 (inlined)
7fdaa5d4a980 elf_dynamic_do_Rela+0x6c0 (inlined)
7fdaa5d4a980 _dl_relocate_object+0x6c0 (/usr/lib64/ld-2.30.so)
7fdaa5d42155 dl_main+0x1cc5 (/usr/lib64/ld-2.30.so)
7fdaa5d5831a _dl_sysdep_start+0x54a (/usr/lib64/ld-2.30.so)
7fdaa5d3ffeb _dl_start_final+0x25b (inlined)
7fdaa5d3ffeb _dl_start+0x25b (/usr/lib64/ld-2.30.so)
7fdaa5d3f117 .annobin_rtld.c+0x7 (inlined)
...
And the event is invoked from the elf loader instead of the target
program's main code.
Moreover, at this moment, we can not probe on the function which will
be selected by the IFUNC, because it is determined at runtime. But
uprobe will be prepared before running the target binary.
Thus, I decided to warn user when the perf probe detects the probe point
is on the GNU IFUNC symbol. Someone who wants to probe an IFUNC symbol to
debug the IFUNC function, they can ignore this warning.
Reported-by: Andi Kleen
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- Check GNU_IFUNC only for uprobe
- Show function name instead of the address.
- Update the warning message according to Andi's comment.
---
tools/perf/util/probe-event.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 8cd1224e5f4c..679447f13c20 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -375,9 +375,13 @@ static int find_alternative_probe_point(struct debuginfo
*dinfo,
/* Find the address of given function */
map__for_each_symbol_by_name(map, pp->function, sym) {
- if (uprobes)
+ if (uprobes) {
address = sym->start;
- else
+ if (sym->type == STT_GNU_IFUNC)
+ pr_warning("Warning: The probe function (%s) is
a GNU indirect function.\n"
+ "Consider identifying the final
function used at run time and set the probe directly on that.\n",
+ pp->function);
+ } else
address = map->unmap_ip(map, sym->start) - map->reloc;
break;
}
[PATCH v2 0/4] perf-probe: Fix GNU IFUNC probe issue etc.
Hi, Here are the v2 patches to fix some issues of probing on GNU IFUNC, duplicated symbols, and memory leak, which were reported by Andi. V1 is here: https://lkml.kernel.org/r/159428201109.56570.3802208017109058146.stgit@devnote2 In this version, I've added Srikar's reviewed-by and Andi's Tested-by (Thanks Srikar and Andi!) and fix some messages and code according to the comment. Thank you, --- Masami Hiramatsu (4): perf-probe: Avoid setting probes on same address on same event perf-probe: Fix wrong variable warning when the probe point is not found perf-probe: Fix memory leakage when the probe point is not found perf-probe: Warn if the target function is GNU Indirect function tools/perf/util/probe-event.c | 18 -- tools/perf/util/probe-finder.c |5 - 2 files changed, 20 insertions(+), 3 deletions(-) -- Masami Hiramatsu (Linaro)
Re: [PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
On Fri, 10 Jul 2020 08:55:40 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 10, 2020 at 12:30:08PM +0900, Masami Hiramatsu escreveu:
> > On Thu, 9 Jul 2020 07:36:54 -0700
> > Andi Kleen wrote:
> >
> > > > diff --git a/tools/perf/util/probe-event.c
> > > > b/tools/perf/util/probe-event.c
> > > > index 1e95a336862c..671176d39569 100644
> > > > --- a/tools/perf/util/probe-event.c
> > > > +++ b/tools/perf/util/probe-event.c
> > > > @@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct
> > > > debuginfo *dinfo,
> > > > address = sym->start;
> > > > else
> > > > address = map->unmap_ip(map, sym->start) -
> > > > map->reloc;
> > > > + if (sym->type == STT_GNU_IFUNC) {
> > > > + pr_warning("Warning: The probe address (0x%lx)
> > > > is in a GNU indirect function.\n"
> > > > + "This may not work as you expected
> > > > unless you intend to probe the indirect function.\n",
> > >
> > > I would say something like this.
> > >
> > > Consider identifying the final function used at run time and set the
> > > probe directly on that.
> > >
> > > I think that's more useful to the user.
> >
> > Hmm, would you mean the default function which may be used for the symbol?
>
> Humm, I think he means that the user must somehow, knowing details
> involved in picking the final function, probe that one instead of the
> IFUNC one, right Andi?
Ah, I got it. OK, I'll update the message :)
Thank you,
--
Masami Hiramatsu
Re: [PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
On Fri, 10 Jul 2020 16:45:12 +0530
Srikar Dronamraju wrote:
> * Masami Hiramatsu [2020-07-09 17:07:31]:
>
> > Reported-by: Andi Kleen
> > Signed-off-by: Masami Hiramatsu
> > ---
> > tools/perf/util/probe-event.c |5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> > index 1e95a336862c..671176d39569 100644
> > --- a/tools/perf/util/probe-event.c
> > +++ b/tools/perf/util/probe-event.c
> > @@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct
> > debuginfo *dinfo,
> > address = sym->start;
> > else
> > address = map->unmap_ip(map, sym->start) - map->reloc;
> > + if (sym->type == STT_GNU_IFUNC) {
> > + pr_warning("Warning: The probe address (0x%lx) is in a
> > GNU indirect function.\n"
> > + "This may not work as you expected unless you
> > intend to probe the indirect function.\n",
> > + (unsigned long)address);
> > + }
>
> Are these GNU indirect functions possible in kernel? If not we could move
> this warning under if (uprobes)
OK, I'll move it under if (uprobes).
>
> Also instead of printing the address, can we print the pp->function?
Hmm, OK. But it may not help user because the pp->function will the name
specified by user...
Thank you,
--
Masami Hiramatsu
Re: [PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
Em Fri, Jul 10, 2020 at 12:30:08PM +0900, Masami Hiramatsu escreveu:
> On Thu, 9 Jul 2020 07:36:54 -0700
> Andi Kleen wrote:
>
> > > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> > > index 1e95a336862c..671176d39569 100644
> > > --- a/tools/perf/util/probe-event.c
> > > +++ b/tools/perf/util/probe-event.c
> > > @@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct
> > > debuginfo *dinfo,
> > > address = sym->start;
> > > else
> > > address = map->unmap_ip(map, sym->start) - map->reloc;
> > > + if (sym->type == STT_GNU_IFUNC) {
> > > + pr_warning("Warning: The probe address (0x%lx) is in a
> > > GNU indirect function.\n"
> > > + "This may not work as you expected unless you
> > > intend to probe the indirect function.\n",
> >
> > I would say something like this.
> >
> > Consider identifying the final function used at run time and set the
> > probe directly on that.
> >
> > I think that's more useful to the user.
>
> Hmm, would you mean the default function which may be used for the symbol?
Humm, I think he means that the user must somehow, knowing details
involved in picking the final function, probe that one instead of the
IFUNC one, right Andi?
- Arnaldo
> Let me check how we can find it.
Re: [PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
* Masami Hiramatsu [2020-07-09 17:07:31]:
> Reported-by: Andi Kleen
> Signed-off-by: Masami Hiramatsu
> ---
> tools/perf/util/probe-event.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 1e95a336862c..671176d39569 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct debuginfo
> *dinfo,
> address = sym->start;
> else
> address = map->unmap_ip(map, sym->start) - map->reloc;
> + if (sym->type == STT_GNU_IFUNC) {
> + pr_warning("Warning: The probe address (0x%lx) is in a
> GNU indirect function.\n"
> + "This may not work as you expected unless you
> intend to probe the indirect function.\n",
> + (unsigned long)address);
> + }
Are these GNU indirect functions possible in kernel? If not we could move
this warning under if (uprobes)
Also instead of printing the address, can we print the pp->function?
> break;
> }
> if (!address) {
>
--
Thanks and Regards
Srikar Dronamraju
Re: [PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
On Thu, 9 Jul 2020 07:36:54 -0700
Andi Kleen wrote:
> > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> > index 1e95a336862c..671176d39569 100644
> > --- a/tools/perf/util/probe-event.c
> > +++ b/tools/perf/util/probe-event.c
> > @@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct
> > debuginfo *dinfo,
> > address = sym->start;
> > else
> > address = map->unmap_ip(map, sym->start) - map->reloc;
> > + if (sym->type == STT_GNU_IFUNC) {
> > + pr_warning("Warning: The probe address (0x%lx) is in a
> > GNU indirect function.\n"
> > + "This may not work as you expected unless you
> > intend to probe the indirect function.\n",
>
> I would say something like this.
>
> Consider identifying the final function used at run time and set the
> probe directly on that.
>
> I think that's more useful to the user.
Hmm, would you mean the default function which may be used for the symbol?
Let me check how we can find it.
Thank you,
--
Masami Hiramatsu
Plumbers session on GNU+LLVM collab?
Hi Segher, Rasmus, and Ramana, I am working on finalizing a proposal for an LLVM microconference at plumbers, which is focusing on a lot of issues we currently face on the LLVM side. I'd really like to host a session with more GNU toolchain developers to discuss collaboration more. I was curious; are either of you planning on attending plumbers this year? If so, would such a session be interesting enough for you to attend? I was curious too, who else we should explicitly invite? I ran a quick set analysis on who's contributed to both kernel and , and the list was much much bigger than I was expecting. https://gist.github.com/nickdesaulniers/5330eea6f46dea93e7766bb03311d474 89 contributors to both linux and llvm 283 linux+gcc 159 linux+binutils (No one to all four yet...also, not super scientific, since I'm using name+email for the set, and emails change. Point being I don't want to explicitly invite hundreds of people) The details of the MC are still being worked out, and it might not happen, but I think with more explicit interest it's likely. -- Thanks, ~Nick Desaulniers
Re: [PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 1e95a336862c..671176d39569 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct debuginfo
> *dinfo,
> address = sym->start;
> else
> address = map->unmap_ip(map, sym->start) - map->reloc;
> + if (sym->type == STT_GNU_IFUNC) {
> + pr_warning("Warning: The probe address (0x%lx) is in a
> GNU indirect function.\n"
> + "This may not work as you expected unless you
> intend to probe the indirect function.\n",
I would say something like this.
Consider identifying the final function used at run time and set the
probe directly on that.
I think that's more useful to the user.
-Andi
[PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function
Warn if the probe target function is GNU indirect function (GNU_IFUNC)
because it may not what the user want to probe.
The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
is the dynamic solved symbol at runtime. IFUNC function is a selector
which is invoked from the elf loader, but the symbol address of the
function which will be modified by the IFUNC is same as the IFUNC in
the symbol table. This can confuse users who is trying to probe on
such functions.
For example, the memcpy is one of IFUNC.
# perf probe -x /lib64/libc-2.30.so -a memcpy
# perf probe -l
probe_libc:memcpy(on __new_memcpy_ifunc@x86_64/multiarch/memcpy.c in
/usr/lib64/libc-2.30.so)
the probe is put on a IFUNC.
# perf record -e probe_libc:memcpy --call-graph dwarf -aR ./perf
# perf script
perf 1742 [000] 26201.715632: probe_libc:memcpy: (7fdaa53824c0)
7fdaa53824c0 __new_memcpy_ifunc+0x0 (inlined)
7fdaa5d4a980 elf_machine_rela+0x6c0 (inlined)
7fdaa5d4a980 elf_dynamic_do_Rela+0x6c0 (inlined)
7fdaa5d4a980 _dl_relocate_object+0x6c0 (/usr/lib64/ld-2.30.so)
7fdaa5d42155 dl_main+0x1cc5 (/usr/lib64/ld-2.30.so)
7fdaa5d5831a _dl_sysdep_start+0x54a (/usr/lib64/ld-2.30.so)
7fdaa5d3ffeb _dl_start_final+0x25b (inlined)
7fdaa5d3ffeb _dl_start+0x25b (/usr/lib64/ld-2.30.so)
7fdaa5d3f117 .annobin_rtld.c+0x7 (inlined)
...
And the event is invoked from the elf loader instead of the target
program's main code.
Moreover, at this moment, we can not probe on the function which will
be selected by the IFUNC, because it is determined at runtime. But
uprobe will be prepared before running the target binary.
Thus, I decided to warn user when the perf probe detects the probe point
is on the GNU IFUNC symbol. Someone who wants to probe an IFUNC symbol to
debug the IFUNC function, they can ignore this warning.
Reported-by: Andi Kleen
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c |5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 1e95a336862c..671176d39569 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct debuginfo
*dinfo,
address = sym->start;
else
address = map->unmap_ip(map, sym->start) - map->reloc;
+ if (sym->type == STT_GNU_IFUNC) {
+ pr_warning("Warning: The probe address (0x%lx) is in a
GNU indirect function.\n"
+ "This may not work as you expected unless you
intend to probe the indirect function.\n",
+ (unsigned long)address);
+ }
break;
}
if (!address) {
[PATCH 0/4] perf-probe: Fix GNU IFUNC probe issue etc.
Hi, Here are patches to fix some issues of probing on GNU IFUNC, duplicated symbols, and memory leak, which were reported by Andi. Andi reported that some issues on probing memcpy function in glibc, which was related to GNU IFUNC (indirect function). As I described in the patch [4/4], it is hard to support probing on the functions which are selected by GNU indirect function because those are chosen at runtime. I think we need a user-mode helper in uprobes to find which one is chosen at runtime. (Oleg, Srikar, would you have any idea?) While cleaning up the patches, I also found a memory leak problem so fixed it ([3/4]). Thank you, --- Masami Hiramatsu (4): perf-probe: Avoid setting probes on same address on same event perf-probe: Fix wrong variable warning when the probe point is not found perf-probe: Fix memory leakage when the probe point is not found perf-probe: Warn if the target function is GNU Indirect function tools/perf/util/probe-event.c | 14 ++ tools/perf/util/probe-finder.c |5 - 2 files changed, 18 insertions(+), 1 deletion(-) -- Masami Hiramatsu (Linaro)
Re: [PATCH v2] ext4: support xattr gnu.* namespace for the Hurd
On Fri, May 29, 2020 at 10:39:39AM +0200, Jan Nieuwenhuizen wrote: > Theodore Y. Ts'o writes: > > Hello! > > > On Mon, May 25, 2020 at 09:39:40PM +0200, Jan (janneke) Nieuwenhuizen wrote: > >> The Hurd gained[0] support for moving the translator and author > >> fields out of the inode and into the "gnu.*" xattr namespace. > >> > >> In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has > >> now been brought into compliance[2] with that. > >> > >> This patch adds support for reading and writing such attributes from > >> Linux; you can now do something like > > [...] > > > > This patch is missing a Signed-off-by. If you don't understand why > > this is really important, please read: > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin > > Ah, that makes sense. Sorry for omitting that/being not clear on it. > > > Can you resubmit with the DCO or confirm that it's OK for me to add > > your Signed-off-by? > > Yes, that's OK, please do! I am the original author of this patch. Thanks, I've applied this to the ext4.git tree. - Ted
Re: linux-next: arm64 build failed - aarch64-linux-gnu-ld: cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or directory
On Wed, 3 Jun 2020 at 14:31, Naresh Kamboju wrote:
>
> arm64 build failed on Linux-next 20200603.
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64
> CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache
> aarch64-linux-gnu-gcc" O=build Image
> #
> aarch64-linux-gnu-ld: cannot find
> ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or
> directory
> make[1]: *** [/linux/Makefile:1132: vmlinux] Error 1
>
9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4 is the first bad commit
commit 9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4
Author: Masahiro Yamada
Date: Mon Jun 1 14:56:59 2020 +0900
kbuild: refactor KBUILD_VMLINUX_{OBJS,LIBS} calculation
Do not overwrite core-y or drivers-y. Remove libs-y1 and libs-y2.
Signed-off-by: Masahiro Yamada
linux-next: arm64 build failed - aarch64-linux-gnu-ld: cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or directory
arm64 build failed on Linux-next 20200603. make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache aarch64-linux-gnu-gcc" O=build Image # aarch64-linux-gnu-ld: cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or directory make[1]: *** [/linux/Makefile:1132: vmlinux] Error 1 -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v2] ext4: support xattr gnu.* namespace for the Hurd
Theodore Y. Ts'o writes: Hello! > On Mon, May 25, 2020 at 09:39:40PM +0200, Jan (janneke) Nieuwenhuizen wrote: >> The Hurd gained[0] support for moving the translator and author >> fields out of the inode and into the "gnu.*" xattr namespace. >> >> In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has >> now been brought into compliance[2] with that. >> >> This patch adds support for reading and writing such attributes from >> Linux; you can now do something like [...] > > This patch is missing a Signed-off-by. If you don't understand why > this is really important, please read: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin Ah, that makes sense. Sorry for omitting that/being not clear on it. > Can you resubmit with the DCO or confirm that it's OK for me to add > your Signed-off-by? Yes, that's OK, please do! I am the original author of this patch. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [PATCH v2] ext4: support xattr gnu.* namespace for the Hurd
On Mon, May 25, 2020 at 09:39:40PM +0200, Jan (janneke) Nieuwenhuizen wrote: > The Hurd gained[0] support for moving the translator and author > fields out of the inode and into the "gnu.*" xattr namespace. > > In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has > now been brought into compliance[2] with that. > > This patch adds support for reading and writing such attributes from > Linux; you can now do something like > > mkdir -p hurd-root/servers/socket > touch hurd-root/servers/socket/1 > setfattr --name=gnu.translator --value='"/hurd/pflocal\0"' \ > hurd-root/servers/socket/1 > getfattr --name=gnu.translator hurd-root/servers/socket/1 > # file: 1 > gnu.translator="/hurd/pflocal" > > to setup a pipe translator, which is being used to create[3] a > vm-image for the Hurd from GNU Guix. > > [0] https://summerofcode.withgoogle.com/projects/#5869799859027968 > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3980bd3b406addb327d858aebd19e229ea340b9a > [2] > https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=a04c7bf83172faa7cb080fbe3b6c04a8415ca645 > [3] https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-hurd-vm This patch is missing a Signed-off-by. If you don't understand why this is really important, please read: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin Can you resubmit with the DCO or confirm that it's OK for me to add your Signed-off-by? - Ted
[PATCH v2] ext4: support xattr gnu.* namespace for the Hurd
The Hurd gained[0] support for moving the translator and author
fields out of the inode and into the "gnu.*" xattr namespace.
In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has
now been brought into compliance[2] with that.
This patch adds support for reading and writing such attributes from
Linux; you can now do something like
mkdir -p hurd-root/servers/socket
touch hurd-root/servers/socket/1
setfattr --name=gnu.translator --value='"/hurd/pflocal\0"' \
hurd-root/servers/socket/1
getfattr --name=gnu.translator hurd-root/servers/socket/1
# file: 1
gnu.translator="/hurd/pflocal"
to setup a pipe translator, which is being used to create[3] a
vm-image for the Hurd from GNU Guix.
[0] https://summerofcode.withgoogle.com/projects/#5869799859027968
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3980bd3b406addb327d858aebd19e229ea340b9a
[2]
https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=a04c7bf83172faa7cb080fbe3b6c04a8415ca645
[3] https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-hurd-vm
---
fs/ext4/Makefile | 3 ++-
fs/ext4/xattr.c| 2 ++
fs/ext4/xattr.h| 1 +
fs/ext4/xattr_hurd.c | 51 ++
include/uapi/linux/xattr.h | 4 +++
5 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 fs/ext4/xattr_hurd.c
diff --git a/fs/ext4/Makefile b/fs/ext4/Makefile
index 4ccb3c9189d8..2e42f47a7f98 100644
--- a/fs/ext4/Makefile
+++ b/fs/ext4/Makefile
@@ -9,7 +9,8 @@ ext4-y := balloc.o bitmap.o block_validity.o dir.o ext4_jbd2.o
extents.o \
extents_status.o file.o fsmap.o fsync.o hash.o ialloc.o \
indirect.o inline.o inode.o ioctl.o mballoc.o migrate.o \
mmp.o move_extent.o namei.o page-io.o readpage.o resize.o \
- super.o symlink.o sysfs.o xattr.o xattr_trusted.o xattr_user.o
+ super.o symlink.o sysfs.o xattr.o xattr_hurd.o xattr_trusted.o \
+ xattr_user.o
ext4-$(CONFIG_EXT4_FS_POSIX_ACL) += acl.o
ext4-$(CONFIG_EXT4_FS_SECURITY)+= xattr_security.o
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 9b29a40738ac..7d2f6576d954 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -93,6 +93,7 @@ static const struct xattr_handler * const
ext4_xattr_handler_map[] = {
#ifdef CONFIG_EXT4_FS_SECURITY
[EXT4_XATTR_INDEX_SECURITY] = &ext4_xattr_security_handler,
#endif
+ [EXT4_XATTR_INDEX_HURD] = &ext4_xattr_hurd_handler,
};
const struct xattr_handler *ext4_xattr_handlers[] = {
@@ -105,6 +106,7 @@ const struct xattr_handler *ext4_xattr_handlers[] = {
#ifdef CONFIG_EXT4_FS_SECURITY
&ext4_xattr_security_handler,
#endif
+ &ext4_xattr_hurd_handler,
NULL
};
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index ffe21ac77f78..730b91fa0dd7 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -124,6 +124,7 @@ struct ext4_xattr_inode_array {
extern const struct xattr_handler ext4_xattr_user_handler;
extern const struct xattr_handler ext4_xattr_trusted_handler;
extern const struct xattr_handler ext4_xattr_security_handler;
+extern const struct xattr_handler ext4_xattr_hurd_handler;
#define EXT4_XATTR_NAME_ENCRYPTION_CONTEXT "c"
diff --git a/fs/ext4/xattr_hurd.c b/fs/ext4/xattr_hurd.c
new file mode 100644
index ..8cfa74a56361
--- /dev/null
+++ b/fs/ext4/xattr_hurd.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * linux/fs/ext4/xattr_hurd.c
+ * Handler for extended gnu attributes for the Hurd.
+ *
+ * Copyright (C) 2001 by Andreas Gruenbacher,
+ * Copyright (C) 2020 by Jan (janneke) Nieuwenhuizen,
+ */
+
+#include
+#include
+#include "ext4.h"
+#include "xattr.h"
+
+static bool
+ext4_xattr_hurd_list(struct dentry *dentry)
+{
+ return test_opt(dentry->d_sb, XATTR_USER);
+}
+
+static int
+ext4_xattr_hurd_get(const struct xattr_handler *handler,
+ struct dentry *unused, struct inode *inode,
+ const char *name, void *buffer, size_t size)
+{
+ if (!test_opt(inode->i_sb, XATTR_USER))
+ return -EOPNOTSUPP;
+
+ return ext4_xattr_get(inode, EXT4_XATTR_INDEX_HURD,
+ name, buffer, size);
+}
+
+static int
+ext4_xattr_hurd_set(const struct xattr_handler *handler,
+ struct dentry *unused, struct inode *inode,
+ const char *name, const void *value,
+ size_t size, int flags)
+{
+ if (!test_opt(inode->i_sb, XATTR_USER))
+ return -EOPNOTSUPP;
+
+ return ext4_xattr_set(inode, EXT4_XATTR_INDEX_HURD,
+ name, value, size, flags);
+}
+
+const struct xattr_handler ext4_xattr_hurd_handler = {
+ .prefix = XATTR_HURD_PREFIX,
+ .list = ext4_xattr_hu
[PATCH] [NOT APPLICABLE YET] kbuild: speed up incremental build for the new GNU Make?
It has been 3 years since GNU Make 4.2.1 was released. The maintainer
of GNU Make, Paul Smith, has announced that the new version (4.3?) will
be released soon.
I reported a bug about the $? behavior some time ago, but it has not
been fixed yet. I am eager to see it fixed for the new release.
[https://savannah.gnu.org/bugs/?55532]
This is a hypothetical patch to demonstrate how it would be beneficial
for the Linux kernel build if it were fixed in time.
The incremental build of Linux kernel is somewhat slow, especially when
lots of objects are compiled. The incremental build of allmodconfig
typically takes a couple of minutes even when none of the objects needs
to be rebuilt.
The time-consuming part in the incremental build is the evaluation of
if_changed* macros since they are used in the recipes to compile C and
assembly source files into objects.
I notice the following code in if_changed* is expensive:
$(filter-out $(PHONY) $(wildcard $^),$^)
In the incremental build, every object has its .*.cmd file, which
contains the auto-generated list of included headers. So, $^ are
expanded into the long list of the source file + included headers,
and $(wildcard $^) checks whether they exist.
It may not be clear why this check exists there.
Here is the record of my research.
[1] The first code addition into Kbuild
This code dates back to 2002. It is the pre-git era. So, I copy-pasted
it from the historical git tree.
| commit 4a6db0791528c220655b063cf13fefc8470dbfee (HEAD)
| Author: Kai Germaschewski
| Date: Mon Jun 17 00:22:37 2002 -0500
|
| kbuild: Handle removed headers
|
| New and old way to handle dependencies would choke when a file
| #include'd by other files was removed, since the dependency on it was
| still recorded, but since it was gone, make has no idea what to do about
| it (and would complain with "No rule to make ...")
|
| We now add targets for all the previously included files, so make will
| just ignore them if they disappear.
|
| diff --git a/Rules.make b/Rules.make
| index 6ef827d3df39..7db5301ea7db 100644
| --- a/Rules.make
| +++ b/Rules.make
| @@ -446,7 +446,7 @@ if_changed = $(if $(strip $? \
| # execute the command and also postprocess generated .d dependencies
| # file
|
| -if_changed_dep = $(if $(strip $? \
| +if_changed_dep = $(if $(strip $? $(filter-out FORCE $(wildcard $^),$^)\
| $(filter-out $(cmd_$(1)),$(cmd_$@))\
| $(filter-out $(cmd_$@),$(cmd_$(1,\
| @set -e; \
| diff --git a/scripts/fixdep.c b/scripts/fixdep.c
| index b5d7bee8efc7..db45bd1888c0 100644
| --- a/scripts/fixdep.c
| +++ b/scripts/fixdep.c
| @@ -292,7 +292,7 @@ void parse_dep_file(void *map, size_t len)
| exit(1);
| }
| memcpy(s, m, p-m); s[p-m] = 0;
| - printf("%s: \\\n", target);
| + printf("deps_%s := \\\n", target);
| m = p+1;
|
| clear_config();
| @@ -314,7 +314,8 @@ void parse_dep_file(void *map, size_t len)
| }
| m = p + 1;
| }
| - printf("\n");
| + printf("\n%s: $(deps_%s)\n\n", target, target);
| + printf("$(deps_%s):\n", target);
| }
|
| void print_deps(void)
The "No rule to make ..." error can be solved by passing -MP to
the compiler, but I think the detection of header removal is a good
feature. When a header is removed, all source files that previously
included it should be re-compiled. This makes sure we has correctly
got rid of #include directives of it.
This is also related with the behavior of $?. The manual says:
$?
The names of all the prerequisites that are newer than the target,
with spaces between them.
This does not address whether a non-existent prerequisite is considered
to be newer than the target.
At this point of time, GNU Make 3.7x was used, where the $? did not
include non-existent prerequisites. Therefore,
$(filter-out FORCE $(wildcard $^),$^)
was added to detect the header removal, and to rebuild the related
objects if it is the case.
[2] Change of $? behavior
Later, the behavior of $? was changed (fixed) to include prerequisites
that did not exist.
First, GNU Make commit 64e16d6c00a5 ("Various changes getting ready for
the release of 3.81.") changed it, but in the release test of 3.81, it
turned out to break the kernel build.
Some materials:
- http://lists.gnu.org/archive/html/bug-make/2006-03/msg3.html
- https://savannah.gnu.org/bugs/?16002
- https://savannah.gnu.org/bugs/?16051
Then, GNU Make commit 6d8d9b74d9c5 ("Numerous updates to tests for
issues found on Cygwin and Windows.") reverted it for the 3.81 release
to give Linux kernel time to adjust to the new behavior.
After the 3.81 release, GNU Make commit 7595f38f62af ("Fixed a number
of documentation bugs, plus some build/install issues:") re-added it.
[3] Adjustm
Re: Linux behaviour problems comes down to GNU idol based on Morphine Psychosis
Yes, then I think we have solved the behavioural problem of Linux, and it seems to come down to the GNU idol, that seems based on Morphine Psychosis. And such the worst Stallman fans, have irate behaviour. And much have pointed to that already, and much criticism done, and indeed the GNU idol should be gone. And indeed I concluded this a while back, and suggested a Fair Labour direction for the OS instead. And replacing LSD culture, with Interculture, and Islam as the Bible is altered with Thorian belief, similar to LSD. then we keep the relevant of developments, and replace the irrelevant with interculture. And indeed the "acid" type never could do finances. Getting the Thor/Odin out, with it sectunrest and reality in. (Nor could they do mastering indeed, and rather than loudnesswar, we do suggest -10dB RMS masters too :)). Peace (Go With Thee), as was the original greeting, and As-Salam is indeed a name of The Divine. Eyx OS https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
Re: sh4-linux-gnu-ld: arch/sh/kernel/cpu/sh2/clock-sh7619.o:undefined reference to `followparent_recalc'
On 4/29/19 9:48 PM, kbuild test robot wrote: > Hi Randy, > > It's probably a bug fix that unveils the link errors. Yoshinori Sato (cc-ed) has a patch for this. I guess that it's not in the arch/sh git tree yet ??? or wherever arch/sh changes come from. > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 83a50840e72a5a964b4704fcdc2fbb2d771015ab > commit: acaf892ecbf5be7710ae05a61fd43c668f68ad95 sh: fix multiple function > definition build errors > date: 3 weeks ago > config: sh-allmodconfig (attached as .config) > compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout acaf892ecbf5be7710ae05a61fd43c668f68ad95 > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=sh > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > All errors (new ones prefixed by >>): > >>> sh4-linux-gnu-ld: arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.data+0x1c): >>> undefined reference to `followparent_recalc' > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > -- ~Randy
sh4-linux-gnu-ld: arch/sh/kernel/cpu/sh2/clock-sh7619.o:undefined reference to `followparent_recalc'
Hi Randy, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 83a50840e72a5a964b4704fcdc2fbb2d771015ab commit: acaf892ecbf5be7710ae05a61fd43c668f68ad95 sh: fix multiple function definition build errors date: 3 weeks ago config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout acaf892ecbf5be7710ae05a61fd43c668f68ad95 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=sh If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> sh4-linux-gnu-ld: arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.data+0x1c): >> undefined reference to `followparent_recalc' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [RFC PATCH 01/68] kbuild: skip sub-make for in-tree build with GNU Make 4.x
Masahiro Yamada wrote: > Why should this patch be included in a > totally unrelated patch series? Sorry, I forgot to exclude it. It's in all my branches that I've touched since upstream got broken. I've now rebased and it's gone from this branch. David
Re: [RFC PATCH 01/68] kbuild: skip sub-make for in-tree build with GNU Make 4.x
On Thu, Mar 28, 2019 at 9:53 AM Masahiro Yamada
wrote:
>
> David,
>
>
> On Thu, Mar 28, 2019 at 8:41 AM David Howells wrote:
> >
> > From: Masahiro Yamada
> >
> > Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> > annoyed people who want to wrap the top Makefile with GNUmakefile
> > or something in order to customize it for their use.
> >
> > On second thought, we do not need to run the sub-make for in-tree
> > build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
> > on GNU Make 3.x.
> >
> > With this commit, people will get back the workflow, and the Debian
> > make-kpkg will still work.
> >
> > Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> > Reported-by: Andreas Schwab
> > Reported-by: David Howells
> > Signed-off-by: Masahiro Yamada
> > Signed-off-by: David Howells
>
>
> Why should this patch be included in a
> totally unrelated patch series?
>
>
> I already applied this to my fixes branch,
> and am planning to send a PR to Linus soon.
>
> (Sorry, I missed to send a PR for -rc2)
Now, this landed in Linus tree.
--
Best Regards
Masahiro Yamada
Re: [RFC PATCH 01/68] kbuild: skip sub-make for in-tree build with GNU Make 4.x
David,
On Thu, Mar 28, 2019 at 8:41 AM David Howells wrote:
>
> From: Masahiro Yamada
>
> Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> annoyed people who want to wrap the top Makefile with GNUmakefile
> or something in order to customize it for their use.
>
> On second thought, we do not need to run the sub-make for in-tree
> build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
> on GNU Make 3.x.
>
> With this commit, people will get back the workflow, and the Debian
> make-kpkg will still work.
>
> Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> Reported-by: Andreas Schwab
> Reported-by: David Howells
> Signed-off-by: Masahiro Yamada
> Signed-off-by: David Howells
Why should this patch be included in a
totally unrelated patch series?
I already applied this to my fixes branch,
and am planning to send a PR to Linus soon.
(Sorry, I missed to send a PR for -rc2)
> ---
>
> Makefile | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index c0a34064c574..cd38d203e71a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -31,26 +31,12 @@ _all:
> # descending is started. They are now explicitly listed as the
> # prepare rule.
>
> -# Ugly workaround for Debian make-kpkg:
> -# make-kpkg directly includes the top Makefile of Linux kernel. In such a
> case,
> -# skip sub-make to support debian_* targets in ruleset/kernel_version.mk, but
> -# displays warning to discourage such abusage.
> -ifneq ($(word 2, $(MAKEFILE_LIST)),)
> -$(warning Do not include top Makefile of Linux Kernel)
> -sub-make-done := 1
> -MAKEFLAGS += -rR
> -endif
> -
> ifneq ($(sub-make-done),1)
>
> # Do not use make's built-in rules and variables
> # (this increases performance and avoids hard-to-debug behaviour)
> MAKEFLAGS += -rR
>
> -# 'MAKEFLAGS += -rR' does not become immediately effective for old
> -# GNU Make versions. Cancel implicit rules for this Makefile.
> -$(lastword $(MAKEFILE_LIST)): ;
> -
> # Avoid funny character set dependencies
> unexport LC_ALL
> LC_COLLATE=C
> @@ -153,6 +139,7 @@ $(if $(KBUILD_OUTPUT),, \
> # 'sub-make' below.
> MAKEFLAGS += --include-dir=$(CURDIR)
>
> +need-sub-make := 1
> else
>
> # Do not print "Entering directory ..." at all for in-tree build.
> @@ -160,6 +147,15 @@ MAKEFLAGS += --no-print-directory
>
> endif # ifneq ($(KBUILD_OUTPUT),)
>
> +ifneq ($(filter 3.%,$(MAKE_VERSION)),)
> +# 'MAKEFLAGS += -rR' does not immediately become effective for GNU Make 3.x
> +# We need to run sub-make to avoid implicit rules in the top Makefile.
> +need-sub-make := 1
> +# Cancel implicit rules for this Makefile.
> +$(lastword $(MAKEFILE_LIST)): ;
> +endif
> +
> +ifeq ($(need-sub-make),1)
> PHONY += $(MAKECMDGOALS) sub-make
>
> $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all:
> sub-make
> @@ -171,8 +167,11 @@ sub-make:
> $(if $(KBUILD_OUTPUT),-C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR)) \
> -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
>
> -else # sub-make-done
> +endif # need-sub-make
> +endif # sub-make-done
> +
> # We process the rest of the Makefile if this is the final invocation of make
> +ifeq ($(need-sub-make),)
>
> # Do not print "Entering directory ...",
> # but we want to display it when entering to the output directory
> @@ -1757,7 +1756,7 @@ existing-targets := $(wildcard $(sort $(targets)))
>
> endif # ifeq ($(config-targets),1)
> endif # ifeq ($(mixed-targets),1)
> -endif # sub-make-done
> +endif # need-sub-make
>
> PHONY += FORCE
> FORCE:
>
--
Best Regards
Masahiro Yamada
[RFC PATCH 01/68] kbuild: skip sub-make for in-tree build with GNU Make 4.x
From: Masahiro Yamada
Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
annoyed people who want to wrap the top Makefile with GNUmakefile
or something in order to customize it for their use.
On second thought, we do not need to run the sub-make for in-tree
build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
on GNU Make 3.x.
With this commit, people will get back the workflow, and the Debian
make-kpkg will still work.
Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
Reported-by: Andreas Schwab
Reported-by: David Howells
Signed-off-by: Masahiro Yamada
Signed-off-by: David Howells
---
Makefile | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
index c0a34064c574..cd38d203e71a 100644
--- a/Makefile
+++ b/Makefile
@@ -31,26 +31,12 @@ _all:
# descending is started. They are now explicitly listed as the
# prepare rule.
-# Ugly workaround for Debian make-kpkg:
-# make-kpkg directly includes the top Makefile of Linux kernel. In such a case,
-# skip sub-make to support debian_* targets in ruleset/kernel_version.mk, but
-# displays warning to discourage such abusage.
-ifneq ($(word 2, $(MAKEFILE_LIST)),)
-$(warning Do not include top Makefile of Linux Kernel)
-sub-make-done := 1
-MAKEFLAGS += -rR
-endif
-
ifneq ($(sub-make-done),1)
# Do not use make's built-in rules and variables
# (this increases performance and avoids hard-to-debug behaviour)
MAKEFLAGS += -rR
-# 'MAKEFLAGS += -rR' does not become immediately effective for old
-# GNU Make versions. Cancel implicit rules for this Makefile.
-$(lastword $(MAKEFILE_LIST)): ;
-
# Avoid funny character set dependencies
unexport LC_ALL
LC_COLLATE=C
@@ -153,6 +139,7 @@ $(if $(KBUILD_OUTPUT),, \
# 'sub-make' below.
MAKEFLAGS += --include-dir=$(CURDIR)
+need-sub-make := 1
else
# Do not print "Entering directory ..." at all for in-tree build.
@@ -160,6 +147,15 @@ MAKEFLAGS += --no-print-directory
endif # ifneq ($(KBUILD_OUTPUT),)
+ifneq ($(filter 3.%,$(MAKE_VERSION)),)
+# 'MAKEFLAGS += -rR' does not immediately become effective for GNU Make 3.x
+# We need to run sub-make to avoid implicit rules in the top Makefile.
+need-sub-make := 1
+# Cancel implicit rules for this Makefile.
+$(lastword $(MAKEFILE_LIST)): ;
+endif
+
+ifeq ($(need-sub-make),1)
PHONY += $(MAKECMDGOALS) sub-make
$(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make
@@ -171,8 +167,11 @@ sub-make:
$(if $(KBUILD_OUTPUT),-C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR)) \
-f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
-else # sub-make-done
+endif # need-sub-make
+endif # sub-make-done
+
# We process the rest of the Makefile if this is the final invocation of make
+ifeq ($(need-sub-make),)
# Do not print "Entering directory ...",
# but we want to display it when entering to the output directory
@@ -1757,7 +1756,7 @@ existing-targets := $(wildcard $(sort $(targets)))
endif # ifeq ($(config-targets),1)
endif # ifeq ($(mixed-targets),1)
-endif # sub-make-done
+endif # need-sub-make
PHONY += FORCE
FORCE:
Re: [PATCH] kbuild: skip sub-make for in-tree build with GNU Make 4.x
On Tue, Mar 19, 2019 at 1:03 PM Masahiro Yamada
wrote:
>
> Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> annoyed people who want to wrap the top Makefile with GNUmakefile
> or something in order to customize it for their use.
>
> On second thought, we do not need to run the sub-make for in-tree
> build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
> on GNU Make 3.x.
>
> With this commit, people will get back the workflow, and the Debian
> make-kpkg will still work.
>
> Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
> Reported-by: Andreas Schwab
> Reported-by: David Howells
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild/fixes.
>
> Makefile | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 99c0530..d9591f2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -31,26 +31,12 @@ _all:
> # descending is started. They are now explicitly listed as the
> # prepare rule.
>
> -# Ugly workaround for Debian make-kpkg:
> -# make-kpkg directly includes the top Makefile of Linux kernel. In such a
> case,
> -# skip sub-make to support debian_* targets in ruleset/kernel_version.mk, but
> -# displays warning to discourage such abusage.
> -ifneq ($(word 2, $(MAKEFILE_LIST)),)
> -$(warning Do not include top Makefile of Linux Kernel)
> -sub-make-done := 1
> -MAKEFLAGS += -rR
> -endif
> -
> ifneq ($(sub-make-done),1)
>
> # Do not use make's built-in rules and variables
> # (this increases performance and avoids hard-to-debug behaviour)
> MAKEFLAGS += -rR
>
> -# 'MAKEFLAGS += -rR' does not become immediately effective for old
> -# GNU Make versions. Cancel implicit rules for this Makefile.
> -$(lastword $(MAKEFILE_LIST)): ;
> -
> # Avoid funny character set dependencies
> unexport LC_ALL
> LC_COLLATE=C
> @@ -153,6 +139,7 @@ $(if $(KBUILD_OUTPUT),, \
> # 'sub-make' below.
> MAKEFLAGS += --include-dir=$(CURDIR)
>
> +need-sub-make := 1
> else
>
> # Do not print "Entering directory ..." at all for in-tree build.
> @@ -160,6 +147,15 @@ MAKEFLAGS += --no-print-directory
>
> endif # ifneq ($(KBUILD_OUTPUT),)
>
> +ifneq ($(filter 3.%,$(MAKE_VERSION)),)
> +# 'MAKEFLAGS += -rR' does not immediately become effective for GNU Make 3.x
> +# We need to run sub-make to avoid implicit rules in the top Makefile.
> +need-sub-make := 1
> +# Cancel implicit rules for this Makefile.
> +$(lastword $(MAKEFILE_LIST)): ;
> +endif
> +
> +ifeq ($(need-sub-make),1)
> PHONY += $(MAKECMDGOALS) sub-make
>
> $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all:
> sub-make
> @@ -171,8 +167,11 @@ sub-make:
> $(if $(KBUILD_OUTPUT),-C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR)) \
> -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
>
> -else # sub-make-done
> +endif # need-sub-make
> +endif # sub-make-done
> +
> # We process the rest of the Makefile if this is the final invocation of make
> +ifeq ($(need-sub-make),)
>
> # Do not print "Entering directory ...",
> # but we want to display it when entering to the output directory
> @@ -1757,7 +1756,7 @@ existing-targets := $(wildcard $(sort $(targets)))
>
> endif # ifeq ($(config-targets),1)
> endif # ifeq ($(mixed-targets),1)
> -endif # sub-make-done
> +endif # need-sub-make
>
> PHONY += FORCE
> FORCE:
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
[PATCH] kbuild: skip sub-make for in-tree build with GNU Make 4.x
Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
annoyed people who want to wrap the top Makefile with GNUmakefile
or something in order to customize it for their use.
On second thought, we do not need to run the sub-make for in-tree
build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
on GNU Make 3.x.
With this commit, people will get back the workflow, and the Debian
make-kpkg will still work.
Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
Reported-by: Andreas Schwab
Reported-by: David Howells
Signed-off-by: Masahiro Yamada
---
Makefile | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
index 99c0530..d9591f2 100644
--- a/Makefile
+++ b/Makefile
@@ -31,26 +31,12 @@ _all:
# descending is started. They are now explicitly listed as the
# prepare rule.
-# Ugly workaround for Debian make-kpkg:
-# make-kpkg directly includes the top Makefile of Linux kernel. In such a case,
-# skip sub-make to support debian_* targets in ruleset/kernel_version.mk, but
-# displays warning to discourage such abusage.
-ifneq ($(word 2, $(MAKEFILE_LIST)),)
-$(warning Do not include top Makefile of Linux Kernel)
-sub-make-done := 1
-MAKEFLAGS += -rR
-endif
-
ifneq ($(sub-make-done),1)
# Do not use make's built-in rules and variables
# (this increases performance and avoids hard-to-debug behaviour)
MAKEFLAGS += -rR
-# 'MAKEFLAGS += -rR' does not become immediately effective for old
-# GNU Make versions. Cancel implicit rules for this Makefile.
-$(lastword $(MAKEFILE_LIST)): ;
-
# Avoid funny character set dependencies
unexport LC_ALL
LC_COLLATE=C
@@ -153,6 +139,7 @@ $(if $(KBUILD_OUTPUT),, \
# 'sub-make' below.
MAKEFLAGS += --include-dir=$(CURDIR)
+need-sub-make := 1
else
# Do not print "Entering directory ..." at all for in-tree build.
@@ -160,6 +147,15 @@ MAKEFLAGS += --no-print-directory
endif # ifneq ($(KBUILD_OUTPUT),)
+ifneq ($(filter 3.%,$(MAKE_VERSION)),)
+# 'MAKEFLAGS += -rR' does not immediately become effective for GNU Make 3.x
+# We need to run sub-make to avoid implicit rules in the top Makefile.
+need-sub-make := 1
+# Cancel implicit rules for this Makefile.
+$(lastword $(MAKEFILE_LIST)): ;
+endif
+
+ifeq ($(need-sub-make),1)
PHONY += $(MAKECMDGOALS) sub-make
$(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make
@@ -171,8 +167,11 @@ sub-make:
$(if $(KBUILD_OUTPUT),-C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR)) \
-f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
-else # sub-make-done
+endif # need-sub-make
+endif # sub-make-done
+
# We process the rest of the Makefile if this is the final invocation of make
+ifeq ($(need-sub-make),)
# Do not print "Entering directory ...",
# but we want to display it when entering to the output directory
@@ -1757,7 +1756,7 @@ existing-targets := $(wildcard $(sort $(targets)))
endif # ifeq ($(config-targets),1)
endif # ifeq ($(mixed-targets),1)
-endif # sub-make-done
+endif # need-sub-make
PHONY += FORCE
FORCE:
--
2.7.4
Re: Can a recipients rights under GNU GPL be revoked?
Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor. Search for "vsnsdualce" "gpl" online to find his messages which prove that, he is a lawyer and has investigated this subject very well. I am CC'ing him in case you'd like to request more information. So if you didn't like the Code of Conduct covertly accepted behind the scenes against your will, and maybe some other questionable political decisions in technical projects (e.g. the recent removal of useful "weboob" package which have been a part of Debian for 8 years but got removed just because some mad SJWs suddenly got offended at its' name) - well you know what to do, and maybe vsnsdualce will be happy to help with your case free of charge. Best regards, Ivan Ivanov вс, 27 янв. 2019 г. в 17:55, Thomas Schmitt : > > Hi, > > Ben Finney wrote: > > > In other words: Any copyright holder can *say* they wish to > > > retroactively revoke the GNU GPL to some party. > > Well, everybody is free to express wishes. But a granted license with no > applicable revocation clause is irrevocable. > > The copyright holders alltogether are entitled to grant any license > they can agree on (and that is not illegal or legally void). > E.g. they can grant non-GPL licenses for their GPLed software. > > What they cannot do is to revoke granted GPL on published versions. > > > rhkra...@gmail.com wrote: > > I believe that the > > original author of a package could do something like create further > > modifications to the code and create a non-free version of the code. > > An example is the cdrecord-wodim fork. The copyright holders did not > release newer versions of cdrecord under GPL. So some concerned Debian > developers used an earlier GPLed version as base of their fork named > wodim. > > > Assuming that is correct, people using (or basing modifications) on the > > (presumably) older free version could continue to use and develop based on > > that, but would not have rights to that new non-free version. > > I agree and practical examples show that we are not alone. > > The copyright of the original authors remains, so that the forkers cannot > change the old license until they replaced all copyrightable imaterial of > the original authors. > > > Have a nice day :) > > Thomas >
GNU and Belief In Flying People - A difficult area of life - Xmas Special.
"He did not believe in Santa Claus, he was the grinch". People obviously have their irrational believes. Flying people indeed, Mary Poppins, Superman, Santa Claus, all have a special place, for many. Over at Nerd Kool Mediaz we have a christmas special: Digi G' Alessio - Mushrooms (Terence McKenna Christmas Dub Special) https://www.youtube.com/watch?v=jZKNQAXWN1U Next time GNU Stallman prophesizes on LSD, without understandings for economics (like indeed most hippies were), think of Digi G' Alessio Peas. (As indeed the NKM version goes).
Re: GNU Kind Communication Guidelines / New Code Of Conduct = Insufficient Pseudoreligion
And indeed behaviour like Linus, who has threatened to kill people over printers is not acceptable. Linus Benedict Torvalds, genius, or pisscrazy? A song made in remembrance of Linus temper: Archetypical Geek - Printernerd Hate. https://www.youtube.com/watch?v=1oel17-9N7o If indeed people do not have the sense to gather around a Fair Pay construct, as I am talking about, pisscrazy is your leader I guess, and the reason that OSs never will be good.
Re: GNU Kind Communication Guidelines / New Code Of Conduct = Insufficient Pseudoreligion
The real philosophical background of operating systems is actually this: I/O, first operatingsystems like layer, available source, has Biblical background. Unix, a whole operating system, available source, builds on first biblical background. Irix, a first multimedia OS, not available source, builds on the earlier. GNU Is Not Unix, builds on the earlier, but in hippie times, is also associated with LSD. Amiga 500, an Irix for the home computer, not available source, builds on earlier, and probably LSD aswell. Microsoft Windows, not available source, builds on earlier aswell, LSD and many regressions aswell, with task priorities still not working after 20 years. Uqquh Is Not A Triune O-S, fixes all this, makes available source focus again, and upgrades the biblical philosophy with a Quran, and a correct latinization of ALLAH, Uqquh. Being a global "fair pay" OS, and the only OS needed, with Fpy Licence and Delyar as the online currency. The Next Thing, in Computing, respecting Labour Party politics, and work union efforts. Peace! Ywe Cærlyn WIP - https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
GNU Kind Communication Guidelines / New Code Of Conduct = Insufficient Pseudoreligion
Hello. As a researcher I started a trend in here a few years ago, where criticism of the lack of coherent philosophy behind Linux, now seems to have resulted in a few lines of pseudoreligious statements, that supposedly is the answer to this, called "GNU Kind Communication Guidelines" and "New Code Of Conduct". Again, ofcourse none of this will solve anything. A full and coherent philosophy is needed. I/O in the 50s was indeed based in "God", and a biblical background. For a full coherent philosophy, globally, one needs the roots, and corrected roots, and that means a Quran now, with full corrected Ibrahimic background. Islam indeed is an inescapable growing trend, and just as any good development should be accepted. . Indeed The Quran states, deal justly, and fair pay measures should be implemented kernelwise. So that indeed available source can be a real alternative in this businessdominated sector. A global fair pay available source system, would be the logical conclusion and next move, and requires such a philosophical coherence. And one day people might be grown enough to do without Pingu idols: https://www.youtube.com/watch?v=N-hg7ENwFUg Do not wait for GNU7 Unyx w/ Mate. This is it. Best, Ywe Cærlyn WIP - https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q
GNU censorship hit me again = Fed up, I am just going to say this.
GNU senorship hit me again, on Phoronix. This is LKML, a usenet mailing list. So lets try again here. Linus Torvalds, Richard Stallman, and Andrew Tanenbaum all are pedophilia victims. And oddly enough think they are gods because of this. On Linux forums, fanboys attack, because they sympathize, with this pantheon. In source, GNU zealousy and the same means among others 1000 HZ Kernel Patch. 10 ms filter in sched.c and this is just from a quick look at source. And Phoronix mails the list and Linus pulls patches from the kernel, without knowing what they were, based on average performance testing. Average performance in a lot of cases, is not important, but rather peak jitter. Gettig peak jitter down, means best performance, or "average performance" will not even be displayed on screen, because of jitter bottlenecks. And in earlier "ricer" (abuse victim slang?) discussions it is supposedly obvious that turning certain optimizations on is useless. Yet nobody sees "defer pop" being on, as usless, that only contributes jitter. Obviously this is poor patching, poor understanding, and a poor internet. And LKML still is ascii, when most of the world has moved to better technology. Better technology, with more ID, for less obscure behaviour. Will Linus scubadiving help? No. Tanenbaum writing books with circus on them? No. Stallman dancing strange dances? No. What is needed is a coherent monotheistic philosophy. That is where civilization comes from, and a good word to all, also abuse victims, that this is not about abuse. Neither communism, nor facism. I am even trying a zén-concept for maximal desirelessness. "Hacker"-space was actually already quite monotheistic. And it was never intended to be poor, neither spiritually nor financially. This is what needs to happen in computing space. Obviously. A good and moral behaviour pattern, an adhérance to religion that teaches monotheism. Overriding vain egoes, and diciplining it to understand reality, and society at large. I hope you understand. Peace. www.nyt.cloud
%ÿ4 Coding OS, Vanity gods, LKML/GNU Attiude Problems, Problematic Netelements in general.
Slight retweak, to %ÿ4 Coding OS. Having had a bit of feel with the namechange I think I can do even better. Looking at what really needs to be fixed with the internet, starting with Fair Pay, getting rid of poor and thieving GNU, and warezpups in general, LKML/GNU Attitude problems, and problematic netelements in general, slight final finish with retweak to %ÿ4 coding OS. A pop-culture threeletter concept, free of as much vains gods as possible. I hope you will enjoy. I already am. Our research and vision for computing forward: https://nyt.cloud/showthread.php?tid=2 Peace, Ywe Cærlyn Léad %ÿ4 Coding
make randconfig of samples/seccomp/bpf-fancy.c (4.17.3) gives "/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory"
Got this at a chroot image at a stable hardened Gentoo Linux : BuildKernel with randconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o YACCscripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --randconfig Kconfig KCONFIG_SEED=0xECEA7407 # # configuration written to .config # scripts/kconfig/conf --syncconfig Kconfig .config:4349:warning: override: reassigning to symbol KERNEL_GZIP * * Restart config... * * * General setup * Cross-compiler tool prefix (CROSS_COMPILE) [] Compile also drivers which will not load (COMPILE_TEST) [N/y/?] n Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode > 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) 3. LZMA (KERNEL_LZMA) 4. XZ (KERNEL_XZ) 5. LZO (KERNEL_LZO) (NEW) 6. LZ4 (KERNEL_LZ4) choice[1-6?]: Error in reading or end of file. Default hostname (DEFAULT_HOSTNAME) [(none)] (none) Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n System V IPC (SYSVIPC) [Y/n/?] y POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y Enable process_vm_readv/writev syscalls (CROSS_MEMORY_ATTACH) [N/y/?] n uselib syscall (USELIB) [Y/n/?] y Auditing support (AUDIT) [N/y/?] n CPU isolation (CPU_ISOLATION) [Y/n/?] y Kernel .config support (IKCONFIG) [Y/n/m/?] y Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y Automatic process group scheduling (SCHED_AUTOGROUP) [N/y/?] n Enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n Kernel->user space relay support (formerly relayfs) (RELAY) [Y/?] y Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y Initramfs source file(s) (INITRAMFS_SOURCE) [] Support initial ramdisk/ramfs compressed using gzip (RD_GZIP) [Y/n/?] y Support initial ramdisk/ramfs compressed using bzip2 (RD_BZIP2) [Y/n/?] y Support initial ramdisk/ramfs compressed using LZMA (RD_LZMA) [N/y/?] n Support initial ramdisk/ramfs compressed using XZ (RD_XZ) [N/y/?] n Support initial ramdisk/ramfs compressed using LZO (RD_LZO) [N/y/?] n Support initial ramdisk/ramfs compressed using LZ4 (RD_LZ4) [N/y/?] n Compiler optimization level > 1. Optimize for performance (CC_OPTIMIZE_FOR_PERFORMANCE) 2. Optimize for size (CC_OPTIMIZE_FOR_SIZE) choice[1-2?]: 1 Enable bpf() system call (BPF_SYSCALL) [N/y/?] n Enable userfaultfd() system call (USERFAULTFD) [Y/n/?] y Embedded system (EMBEDDED) [Y/n/?] y PC/104 support (PC104) [Y/n/?] y Enable VM event counters for /proc/vmstat (VM_EVENT_COUNTERS) [N/y/?] n Enable SLUB debugging support (SLUB_DEBUG) [Y/n/?] y Enable memcg SLUB sysfs support by default (SLUB_MEMCG_SYSFS_ON) [N/y/?] n Disable heap randomization (COMPAT_BRK) [Y/n/?] y Choose SLAB allocator 1. SLAB (SLAB) > 2. SLUB (Unqueued Allocator) (SLUB) 3. SLOB (Simple Allocator) (SLOB) choice[1-3?]: 2 Allow slab caches to be merged (SLAB_MERGE_DEFAULT) [N/y/?] n SLAB freelist randomization (SLAB_FREELIST_RANDOM) [N/y/?] n Harden slab freelist metadata (SLAB_FREELIST_HARDENED) [N/y/?] n SLUB per cpu partial cache (SLUB_CPU_PARTIAL) [Y/n/?] y Profiling support (PROFILING) [Y/n/?] y OProfile system profiling (OPROFILE) [N/m/y/?] n Kprobes (KPROBES) [N/y/?] n Optimize very unlikely/likely branches (JUMP_LABEL) [Y/n/?] y Static key selftest (STATIC_KEYS_SELFTEST) [Y/n/?] y Stack Protector buffer overflow detection 1. None (CC_STACKPROTECTOR_NONE) 2. Regular (CC_STACKPROTECTOR_REGULAR) > 3. Strong (CC_STACKPROTECTOR_STRONG) 4. Automatic (CC_STACKPROTECTOR_AUTO) choice[1-4?]: 3 Number of bits to use for ASLR of mmap base address (ARCH_MMAP_RND_BITS) [8] 8 Perform full reference count validation at the expense of speed (REFCOUNT_FULL) [N/y/?] n # # configuration written to .config # SYSTBL arch/x86/include/generated/asm/syscalls_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h HOSTCC scripts/basic/bin2c HOSTCC arch/x86/tools/relocs_32.o ... AR samples/seccomp/built-in.a HOSTCC samples/seccomp/bpf-fancy.o In file included from /usr/include/features.h:447:0, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdio.h:27, from samples/seccomp/bpf-fancy.c:16: /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory # include ^~~~ compilation terminated. make[2]: *** [scripts/Makefile.host:107: samples/seccomp/bpf-fancy.o] Error 1 make[1]: *** [scripts/Makefile.build:559: samples/seccomp] Error 2 make: *** [Makefile:1063: samples] Error 2 # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.17.3 Kernel Configuration # #
Re: [PATCH] kbuild: rpm-pkg: Support GNU tar >= 1.29
2018-03-24 2:59 GMT+09:00 Jason Gunthorpe : > There is a change in how command line parsing is done in this version. > Excludes and includes are now ordered with the file list. Since > the spec file puts the file list before the exclude list it means newer > tar ignores the excludes and packs all the build output into the > kernel-devel RPM resulting in a huge package. > > Simple argument re-ordering fixes the problem. > > Signed-off-by: Jason Gunthorpe > --- Applied to linux-kbuild/fixes. Thanks! -- Best Regards Masahiro Yamada
Re: [gnu-csky] [PATCH 00/19] C-SKY(csky) Linux Kernel Port
On Mon, Mar 26, 2018 at 5:06 PM, Sandra Loosemore wrote: > On 03/26/2018 07:30 AM, Arnd Bergmann wrote: >> >> >> Another interesting question is the status of your toolchain support. I >> see your >> github account contains binutils and gcc repositories, but they are not >> upstream >> yet. Are you working on getting those included in the respective upstream >> projects already? > > > We at Mentor Graphics are working on preparing the abiv2 binutils and gcc > support for upstream submission. The existing gcc back end for abiv1 is > actually completely separate from the abiv2 back end and probably eventually > needs to be merged with it, but first things first. Ok, very good. Being able to build abiv2 is probably sufficient for testing the kernel in a meaningful way, and if you are working on getting that upstream, I trust that it will happen quick enough. I can always provide toolchain binaries on kernel.org based a prerelease version like I did for openrisc, which makes it accessible to other kernel developers doing cross-arch changes. Arnd
Re: [gnu-csky] [PATCH 00/19] C-SKY(csky) Linux Kernel Port
On 03/26/2018 07:30 AM, Arnd Bergmann wrote: Another interesting question is the status of your toolchain support. I see your github account contains binutils and gcc repositories, but they are not upstream yet. Are you working on getting those included in the respective upstream projects already? We at Mentor Graphics are working on preparing the abiv2 binutils and gcc support for upstream submission. The existing gcc back end for abiv1 is actually completely separate from the abiv2 back end and probably eventually needs to be merged with it, but first things first. -Sandra
[PATCH] kbuild: rpm-pkg: Support GNU tar >= 1.29
There is a change in how command line parsing is done in this version.
Excludes and includes are now ordered with the file list. Since
the spec file puts the file list before the exclude list it means newer
tar ignores the excludes and packs all the build output into the
kernel-devel RPM resulting in a huge package.
Simple argument re-ordering fixes the problem.
Signed-off-by: Jason Gunthorpe
---
scripts/package/mkspec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
At the very least this effects FC27.
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index 280027fad991c1..61427c6f220922 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -98,7 +98,7 @@ $Mmake %{?_smp_mflags} INSTALL_MOD_PATH=%{buildroot}
KBUILD_SRC= modules_instal
$S$M rm -f %{buildroot}/lib/modules/$KERNELRELEASE/build
$S$M rm -f %{buildroot}/lib/modules/$KERNELRELEASE/source
$S$M mkdir -p %{buildroot}/usr/src/kernels/$KERNELRELEASE
-$S$M tar cf - . $EXCLUDES | tar xf - -C
%{buildroot}/usr/src/kernels/$KERNELRELEASE
+$S$M tar cf - $EXCLUDES . | tar xf - -C
%{buildroot}/usr/src/kernels/$KERNELRELEASE
$S$M cd %{buildroot}/lib/modules/$KERNELRELEASE
$S$M ln -sf /usr/src/kernels/$KERNELRELEASE build
$S$M ln -sf /usr/src/kernels/$KERNELRELEASE source
--
2.16.2
Re: [PATCH v2 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold
Reviewed-by: Nick Desaulniers
[PATCH v2 0/7] Add support for GNU gold
These patches add macros for detecting the linker name and version, and apply fixes and workarounds needed to link the arm64 kernel with GNU gold. Changes since v1: - moved LD_DEAD_CODE_DATA_ELIMINATION fixes to the beginning of the patch set and removed mentions of gold - renamed ld-if-name-version to __ld-ifversion for consistency - cleaned up the erratum changes in arch/arm64/Makefile Sami Tolvanen (7): kbuild: fix LD_DEAD_CODE_DATA_ELIMINATION arm64: keep .altinstructions and .altinstr_replacement kbuild: add ld-name macro kbuild: add __ld-ifversion and linker-specific macros arm64: fix -m for GNU gold arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS arch/arm64/Makefile | 17 + arch/arm64/kernel/module.lds | 4 ++-- arch/arm64/kernel/vmlinux.lds.S | 4 ++-- include/asm-generic/vmlinux.lds.h | 8 scripts/Kbuild.include| 16 5 files changed, 41 insertions(+), 8 deletions(-) -- 2.15.0.531.g2ccb3012c9-goog
[PATCH v2 5/7] arm64: fix -m for GNU gold
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec instead of aarch64linux. Signed-off-by: Sami Tolvanen Acked-by: Yury Norov --- arch/arm64/Makefile | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index b35788c909f1..82a0df6e865e 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -64,14 +64,22 @@ KBUILD_CPPFLAGS += -mbig-endian CHECKFLAGS += -D__AARCH64EB__ AS += -EB LD += -EB +ifeq ($(ld-name),gold) +LDFLAGS+= -maarch64_elf64_be_vec +else LDFLAGS+= -maarch64linuxb +endif UTS_MACHINE:= aarch64_be else KBUILD_CPPFLAGS+= -mlittle-endian CHECKFLAGS += -D__AARCH64EL__ AS += -EL LD += -EL +ifeq ($(ld-name),gold) +LDFLAGS+= -maarch64_elf64_le_vec +else LDFLAGS+= -maarch64linux +endif UTS_MACHINE:= aarch64 endif -- 2.15.0.531.g2ccb3012c9-goog
[PATCH v2 7/7] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS
All current versions of GNU gold crash when linking kernel modules
with ARM64_MODULE_PLTS due to a known bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14592
To work around the problem, this change removes NOLOAD from .plt
and .init.plt.
Signed-off-by: Sami Tolvanen
Acked-by: Ard Biesheuvel
---
arch/arm64/kernel/module.lds | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds
index f7c9781a9d48..eacb5c67f61e 100644
--- a/arch/arm64/kernel/module.lds
+++ b/arch/arm64/kernel/module.lds
@@ -1,4 +1,4 @@
SECTIONS {
- .plt (NOLOAD) : { BYTE(0) }
- .init.plt (NOLOAD) : { BYTE(0) }
+ .plt : { BYTE(0) }
+ .init.plt : { BYTE(0) }
}
--
2.15.0.531.g2ccb3012c9-goog
[PATCH v2 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold
Some versions of GNU gold are known to produce broken code with --fix-cortex-a53-843419 as explained in this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21491 If ARM64_ERRATUM_843419 is disabled and we're using GNU gold, pass --no-fix-cortex-a53-843419 to the linker to ensure the erratum fix is not used even if the linker is configured to enable it by default. This change also adds a warning if the erratum fix is enabled and gold version <1.14 is used. Signed-off-by: Sami Tolvanen --- arch/arm64/Makefile | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 82a0df6e865e..68eed687e468 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -26,8 +26,17 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) ifeq ($(call ld-option, --fix-cortex-a53-843419),) $(warning ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum) else +ifeq ($(call gold-ifversion, -lt, 11400, y), y) +$(warning This version of GNU gold may generate incorrect code with --fix-cortex-a53-843419;\ + see https://sourceware.org/bugzilla/show_bug.cgi?id=21491) +endif LDFLAGS_vmlinux+= --fix-cortex-a53-843419 endif +else + ifeq ($(ld-name),gold) +# Pass --no-fix-cortex-a53-843419 to ensure the erratum fix is disabled +LDFLAGS+= --no-fix-cortex-a53-843419 + endif endif KBUILD_DEFCONFIG := defconfig -- 2.15.0.531.g2ccb3012c9-goog
Re: [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold
On Wed, Nov 29, 2017 at 04:30:33PM -0800, Nick Desaulniers wrote: > Rather than: > > if CONFIG_ARM64_ERRATUM_843419 == y: > ... > if CONFIG_ARM64_ERRATUM_843419 == '': > ... > > could this be: > > if CONFIG_ARM64_ERRATUM_843419 == y: > ... > else > ... > > ? Sure. I'll clean this up in v2. Sami
Re: [PATCH 1/7] kbuild: add ld-name macro and support for GNU gold
On Wed, Nov 29, 2017 at 04:32:52PM -0800, Nick Desaulniers wrote: > Right, but you're still only ever using one linker per build, correct? Correct. LDFLAGS_GOLD makes it move convenient to add gold specific flags without explicit $(ld-name) checks everywhere, but I'm fine with removing it in v2. Sami
Re: [PATCH 7/7] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS
On 29 November 2017 at 23:44, Sami Tolvanen wrote:
> All current versions of GNU gold crash when linking kernel modules
> with ARM64_MODULE_PLTS due to a known bug:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=14592
>
> To work around the problem, this change removes NOLOAD from .plt
> and .init.plt.
>
> Signed-off-by: Sami Tolvanen
Acked-by: Ard Biesheuvel
> ---
> arch/arm64/kernel/module.lds | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds
> index f7c9781a9d48..eacb5c67f61e 100644
> --- a/arch/arm64/kernel/module.lds
> +++ b/arch/arm64/kernel/module.lds
> @@ -1,4 +1,4 @@
> SECTIONS {
> - .plt (NOLOAD) : { BYTE(0) }
> - .init.plt (NOLOAD) : { BYTE(0) }
> + .plt : { BYTE(0) }
> + .init.plt : { BYTE(0) }
> }
> --
> 2.15.0.531.g2ccb3012c9-goog
>
Re: [PATCH 3/7] kbuild: fix LD_DEAD_CODE_DATA_ELIMINATION with GNU gold
On Wed, 29 Nov 2017 15:44:38 -0800 Sami Tolvanen wrote: > Don't remove .head.text or .exitcall.exit when linking with --gc-sections, > and include .init.text.* in .init.text and .init.rodata.* in .init.rodata. > > Signed-off-by: Sami Tolvanen Fine by me, if you consider my other comments. Reviewed-by: Nicholas Piggin
Re: [PATCH 1/7] kbuild: add ld-name macro and support for GNU gold
On Wed, Nov 29, 2017 at 3:44 PM, Sami Tolvanen wrote: > GNU gold may require different flags than GNU ld. Add a macro for > detecting the linker and conditionally add gold specific flags from > LDFLAGS_GOLD. Right, but you're still only ever using one linker per build, correct? Can we get away without 2 distinct flags? > +# Add any flags specific to ld.gold > +ifeq ($(ld-name),gold) > +LDFLAGS+= $(LDFLAGS_GOLD) > +endif > + Patch 1 and 6 have this pattern of always assigning to LDFLAGS_GOLD, then that to LDFLAGS. Wouldn't it be better to check the ld-name and conditionally assign to LDFLAGS? Then LDFLAGS_GOLD is not necessary. For example, what I'm suggesting is what is done in patch 4. > +# ld-name > +# Expands to either bfd or gold > +ld-name = $(shell $(LD) -v 2>&1 | grep -q "GNU gold" && echo gold || echo > bfd) > + This part LGTM.
Re: [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold
On Wed, Nov 29, 2017 at 3:44 PM, Sami Tolvanen wrote: > @@ -26,10 +26,19 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) >ifeq ($(call ld-option, --fix-cortex-a53-843419),) > $(warning ld does not support --fix-cortex-a53-843419; kernel may be > susceptible to erratum) >else > +ifeq ($(call gold-ifversion, -lt, 11400, y), y) > +$(warning This version of GNU gold may generate incorrect code with > --fix-cortex-a53-843419;\ > + see https://sourceware.org/bugzilla/show_bug.cgi?id=21491) > +endif > LDFLAGS_vmlinux+= --fix-cortex-a53-843419 >endif > endif > > +ifeq ($(CONFIG_ARM64_ERRATUM_843419),) > +# https://sourceware.org/bugzilla/show_bug.cgi?id=21491 > +LDFLAGS_GOLD += --no-fix-cortex-a53-843419 > +endif > + Rather than: if CONFIG_ARM64_ERRATUM_843419 == y: ... if CONFIG_ARM64_ERRATUM_843419 == '': ... could this be: if CONFIG_ARM64_ERRATUM_843419 == y: ... else ... ?
[PATCH 4/7] arm64: fix -m for GNU gold
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec instead of aarch64linux. Signed-off-by: Sami Tolvanen Acked-by: Yury Norov --- arch/arm64/Makefile | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index b35788c909f1..82a0df6e865e 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -64,14 +64,22 @@ KBUILD_CPPFLAGS += -mbig-endian CHECKFLAGS += -D__AARCH64EB__ AS += -EB LD += -EB +ifeq ($(ld-name),gold) +LDFLAGS+= -maarch64_elf64_be_vec +else LDFLAGS+= -maarch64linuxb +endif UTS_MACHINE:= aarch64_be else KBUILD_CPPFLAGS+= -mlittle-endian CHECKFLAGS += -D__AARCH64EL__ AS += -EL LD += -EL +ifeq ($(ld-name),gold) +LDFLAGS+= -maarch64_elf64_le_vec +else LDFLAGS+= -maarch64linux +endif UTS_MACHINE:= aarch64 endif -- 2.15.0.531.g2ccb3012c9-goog
