2018-07-06 23:39 GMT+09:00 Gabriel C <nix.or.die@xxxxxxxxx>: > 2018-07-06 16:13 GMT+02:00 Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>: >> Hi. >> >> 2018-07-06 19:41 GMT+09:00 Kirill A. Shutemov <kirill@xxxxxxxxxxxxx>: >>> On Fri, Jul 06, 2018 at 03:37:58PM +0900, Masahiro Yamada wrote: >>>> >> > > Also see https://bugzilla.kernel.org/show_bug.cgi?id=200385 , >>>> >> > > >>>> >> > > 0a1756bd2897951c03c1cb671bdfd40729ac2177 is acting up >>>> >> > > too with the same symptoms >>>> >> > >>>> >> > I tracked it down to -flto in LDFLAGS. I'll look more into this. >>>> >> >>>> >> -flto in LDFLAGS screws up this part of paging_prepare(): >>>> > >>>> > +Masahiro, Michal. >>>> > >>>> > I've got it wrong. *Any* LDFLAGS option passed to make this way: >>>> > >>>> > make LDFLAGS="..." >>>> > >>>> > would cause a issue. Even empty. >>>> > >>>> > It overrides all assignments to the variable in the makefile. >>>> > As result the image is built without -pie and linker doesn't generate >>>> > position independed code. >>>> > >>>> > Looks like the patch below helps, but my make-fu is poor. >>>> > I don't see many override directives in kernel makefiles. >>>> > It makes me think that there's a better way to fix this. >>>> > >>>> > Hm? >>>> >>>> >>>> LDFLAGS is for internal-use. >>>> Please do not override it from the command line. >>> >>> Can we generate a build error if a user try to override LDFLAGS, CFLAGS or >>> other critical internal-use-only variables? >> >> Yes, Make can check where variables came from. >> >> >>> This breakage was rather hard to debug. We need to have some kind of >>> fail-safe for the future. >>> >>>> You want to pass your own linker flags >>>> for building vmlinux and modules, >>>> but do not want to pass them to >>>> the decompressor (arch/x86/boot/compressed). >>>> >>>> Correct? >>> >>> I personally don't think that changing compiler/linker options for kernel >>> build is good idea in general. >>> >>>> Kbuild provides a way for users >>>> to pass additional linker flags to modules. >>>> (LDFLAGS_MODULE) >>>> >>>> >>>> But, there is no way to do that for vmlinux. >>>> >>>> It is easy to support it, though. >>>> >>>> https://patchwork.kernel.org/patch/10510833/ >>>> >>>> If this is the one you want, I can merge this. >>>> >>>> >>>> make LDFLAGS_KERNEL=... LDFLAGS_MODULE=... >>>> will allow you to append linker flags. >>> >>> Okay. It makes me wounder if we should taint kernel in such cases? >>> Custom compiler/linker flags are risky and can lead to weird bugs. >> >> OK. >> So, what problem are we discussing? >> >> >>> I've got it wrong. *Any* LDFLAGS option passed to make this way: >>> >>> make LDFLAGS="..." >> >> In your previous mail, I thought you were asking me how to pass >> custom linker flags. >> >> If not, we do not need to think about that case. >> Just say "Do not do that". > > I am sorry but I have a hard time to get your logic here. > > You are saying : the *env* variable LDFLAGS as well passing > LDFLAGS to make , which your build allows should not be use > because is for 'internal usage' .. ? > > Well that logic you have here is wrong and wrong for any project > not just for the kernel, Why 'my logic'? LDFLAGS has been long used internally since the old days, before I ever worked on the kernel. I shared my knowledge about the kernel build system. The current situation is not nice, but why are you blaming me for the code I did not add ? Note: I have never said 'the *env* variable LDFLAGS' > If you know 'parts' need have particular flags then 'you' have to > ensure nothing > overrides these or nothing at all can chage these. > > So swap your logic and apped LDFLAGS to your private > 'call_it_whatever_you_wish_KERNEL_NEED_BE_THERE_ANY_KIND_FLAGS' > and don't allow these to be changed at all , when you > *know* they have be there. > > > Teling users to not use LD/C/CXX flags is not really going to work right ? > > > BR -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
