Created attachment 54210 [details] patch to fix the bug works: gcc --help -v 2>/dev/null | grep ffunction-sections (prints the ffunction-section description) doesn't work: gcc -Wl,--some-flag --help -v 2>/dev/null | grep ffunction-sections (nothing is printed) I am sure that this behavior is incorrect. also (but maybe less important): gcc a.c a.c a.c a.c --help -v 2>/dev/null | grep ffunction-sections this prints the help 4 times (as many times as there are input files). I am also sure that this behavior is incorrect. Some programs depend on --help -v to work, for example python. python checks if fwrapv is supported with the mechanism. buildroot uses something called toolchain-wrapper to add default flags to gcc when you call it, if you would check the bootlin compilers in aarch64 they add -Wl,-z,relro by default. So, if you were to compile python with a bootlin compiler with gcc>=10 it will not compile with all the correct flags (no fwrapv). This is just one example (this is where I noticed the bug). The bug was introduced in the following commit: https://github.com/gcc-mirror/gcc/commit/2dcfc8722b6146e479039a2f8994050c772b25e6 (commit 2dcfc8722b6146e479039a2f8994050c772b25e6) So the bug only exists in gcc>=10, and doesn't in gcc<=9. I created a patch to revert a small part of this commit (will send to the gcc patches mailing list as well). I tested the patch. One of the reasons I am sure this is a bug is because of the comment above the if statement: "Ensure we only invoke each subprocess once.", so the help should be printed once and only once.
Considering -fwrapv has been there since GCC 3.4.0, I think python should just change how their configuring. -fwrapv was added in r0-50210-g4fa26a60791ec3 .
I think this behavior is correctly documented too: If the -v option is also specified then --help is also passed on to the various processes invoked by gcc, so that they can display the command-line options they accept. With -Wl,x you only invoke collect2(ld). That is how it has been documented too. I think just python configure is broken.
I agree that the python check is broken, but I do think that the current behavior is incorrect. it doesn't make sense that for N input file, the help will be displayed N times. and that linker options suppress the help message. The comment in the code above the if statement ("Ensure we only invoke each subprocess once.") shows this was the intention, and the commit I talked about broke it without noticing. The fact that this worked till gcc 9.x.x, and stopped working from gcc 10.x.x, also says that this is not the intended behavior, in my opinion.
created a bug report on buildroot as a workaround for the time being: https://bugs.busybox.net/show_bug.cgi?id=15231
So basically from what I understand is buildroot is doing this so they can hardcode supporting only 4k pages. THIS IS BROKEN. Someone could build a kernel and try to use a buildroot built sysroot and it will break ...
Well, this is only for aarch64 and arc, and they do compile the kernel in buildroot, so it seems to work? (never checked myself) By the way, they solve the -Wl,z,relro for kernel/uboot compilation by checking if -D__KERNEL__ or -D__UBOOT__ was specified and then not adding the link flag, which is an eye-opener for me.
Ok, now I understand what you said about the kernel and sysroot. Yes, it is weird. (non buildroot kernel compiled with 64k pages, buildroot sysroot with 4k max).