Messages in this thread | | | Date | Mon, 20 Apr 2020 14:36:12 -0500 | From | Josh Poimboeuf <> | Subject | Re: [GIT pull] perf/urgent for 5.7-rc2 |
| |
On Mon, Apr 20, 2020 at 12:21:46PM -0700, Linus Torvalds wrote: > On Mon, Apr 20, 2020 at 11:17 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > If you added something bad to a file, and just rebuilt that file, you > > wouldn't see the objtool warning until later when you build the entire > > kernel. > > Yes, that's not optimal, but I think I'd personally still prefer that > behavior. Especially since I seldom build single files, and in fact > rather seldom build without some "make -j32" or similar: so build > errors don't happen linearly in the first place. > > > (Of course the same complaint would apply to vmlinux.o > > validation.) But the warning shows the .o file, which could be > > confusing. > > The warning should show the proper loe-level *.o file, so I don't see > what's confusing about that. > > Yes, the error would happen while trying to link (say) > kernel/built-in.a, and 'make' would report that creating that archive > had failed, but 'objtool' itself would report the particular object > file it was working on that had issues.
My workflow is often
$ vi kernel/livepatch/core.c $ make kernel/livepatch/core.o
That way I don't have to wait to see what I broke (compile or objtool).
And if whatever I changed was in response to an objtool warning for kernel/livepatch/core.o, and the warning didn't show up after doing the above, I might stupidly assume I fixed it.
That's what I meant about it being confusing. Maybe that's just me though.
> So the errors should be pretty obvious. But like PeterZ, the makefile > magic escapes me.
Ditto...
-- Josh
| |