On Mon, Feb 15, 2021 at 09:00:57PM -0500, Steven Rostedt wrote: > On Mon, 15 Feb 2021 20:06:39 -0500 > Steven Rostedt <[email protected]> wrote: > > > Strange, that when I applied this to the latest kernel on a my build > > system (binutils 2.35), it still created all the necessary mcount > > locations?? > > I know why it worked. If you are using the latest gcc on the latest > mainline, it will not even bother with recordmcount, and will just > create the __mcount_loc sections, as latest gcc knows about ftrace. > > (this is what I get for working on a company holiday) > > Since this is a toolchain issue, perhaps the correct thing to do is to > backport to stable the changes to have it build with -mrecord-mcount if > the build system enables it. > > If you are using the lastest compilers to build stable releases, and > that's causing issues, then you should have the stable releases use the > latest kernel compiler options. > > Greg, > > Can you test the following two backports. It does change the semantics > of what is built, but then again if you are using a newer compiler to > build stable kernels, that can change things too. > > 96f60dfa5819a ("trace: Use -mcount-record for dynamic ftrace") > 07d0408120216 ("tracing: Avoid calling cc-option -mrecord-mcount for every > Makefile") > > I attached the backports to 4.4. (just compiled tested, I'll test them more > tomorrow) >
Yes, they build here for me! Thanks for this. Should I also queue these up for 4.9 and 4.14 which do not have these commits in them either (but somehow do not show the problem, yet)? thanks, greg k-h
