Re: [GIT PULL 2/4] Kbuild updates for v4.21 part2
From: Masahiro Yamada
Date: Sun Jan 06 2019 - 23:45:05 EST
(+CC Changbin Du, Arnd Bergmann)
On Sun, Dec 30, 2018 at 6:01 AM Linus Torvalds
> On Fri, Dec 28, 2018 at 8:00 AM Masahiro Yamada
> <yamada.masahiro@xxxxxxxxxxxxx> wrote:
> > Introduce a new option CONFIG_NO_AUTO_INLINE as well. With this option,
> > only functions explicitly marked with "inline" will be inlined. This
> > will allow the function tracer to trace more functions.
> Ugh. This causes new and bogus warnings, because gcc doesn't see some
> of the checks.
> For example, the x86 emulate_vsyscall() function now warns that
> warning: âsyscall_nrâ may be used uninitialized in this function
> because addr_to_vsyscall_nr() isn't inlined any more, so gcc doesn't
> see that the return value is always smaller than three (and then it
> doesn't see that we handle all the cases in the switch statement
> So honestly, these "debugging improvements" have a rather nasty side
> effect. I'm not at all convinced that we should do this. It is *not*
> worth causing extra development pain with a totally pointless option
> that changes code generation radically like this. It's going to cause
> lots of extra churn.
Sorry for late reply.
I know this series was rejected,
but I felt guilty about being completely silent.
So, here is just my two cents.
For addr_to_vsyscall_nr(), we can fix it by marking it as 'inline'
IMHO, it is not so bad to tell the compiler what we want.
In most cases, it is just a matter of 'inline' marker,
although I admit this process is kind of painful...
> This branch already added a couple of extra inline markers just to
> make code work reasonably. How many tens (or hundreds) got missed just
> because the build still works, but the lack of inlining means that we
> generate completely garbage code?
I do not have the exact number, but
my impression was "not so many".
Changbin and Arnd might have better insight.
They were trying to eliminate potential problems beforehand.
> I'm going to skip this pull request.
> We have basically always required a certain level of competence from
> the compiler, and this basically says that the compiler can do stupid
> things and we'd have to fix those stupidities by hand.