Re: [PATCH] ftrace: Do not reference symbols in sections without size

[Steven Rostedt]

On Tue, 16 Feb 2021 16:54:58 +0100
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

> On Tue, Feb 16, 2021 at 09:45:39AM -0600, Josh Poimboeuf wrote:
> > On Tue, Feb 16, 2021 at 09:51:21AM -0500, Steven Rostedt wrote:  
> > > On Tue, 16 Feb 2021 12:04:06 +0100
> > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >   
> > > > 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)?  
> > >
> > > This bothers me. I want to know exactly why this is a problem.  
> > 
> > I actually see the same problem with 4.9 and 4.14, using the same
> > config.  
> 

Interesting. I removed the "-mrecordmcount" option from 5.10.16, and I'm
currently building it, and so far it has no issues. :-/

This is on a fresh install of archlinux using binutils 2.36-3.

> Ok, that's good to know.
> 
> > It's very config-specific.  Something has to convince the toolchain to
> > not reference those two weak functions by section.  
> 
> I've queued up all 3 patches (Steven collapsed 2 into 1 it seems) for
> 4.4.y, 4.9.y, and 4.14.y now.

Which were the three patches. And if I collapsed it into 1, that was by
mistake :-/  I was doing the work on the archlinux VM and was using quilt
to fix up the backport (as I usually do), but I was using vim instead of my
normal emacs (yes I'm one of those), and may have screwed things up.

> 
> > > That said, it is fine to backport those patches, and I would include 4.9
> > > and 4.14, as I would think you have a similar requirement that we have in
> > > the stable-rt trees. That is you shouldn't experience a regression going
> > > from an older kernel to a newer one because the older one had a fix
> > > backported to it that a newer one did not. Basically the same rationale that
> > > all fixes go into Linus's tree before backporting. We do the same on the
> > > stable-rt, where all fixes go in all maintained stable trees that are newer
> > > than the one you are backporting to.
> > > 
> > > Although, it does allow more to be traced than what recordmcount enables.
> > > But hopefully it doesn't cause any issues. Maybe I should do some ftrace
> > > testing before you go and release any of those stables with those patches.
> > > 
> > > I'm looking to see if this new "feature" of binutils isn't causing trouble
> > > elsewhere. I'm thinking that ftrace is just the canary here.  
> > 
> > It already caused quite a bit of trouble with objtool (as did a previous
> > similar change by the Clang assembler).  
> 
> I feel like we go through this every major binutils release.  Why isn't
> "build the Linux kernel" part of the binutils regression test suite by
> now?  :)

Perhaps it builds the latest kernel fine? As I said, I'm currently testing
a 5.10 build (couldn't get the 4.4 to boot, so I wanted to see if the issue
is on 5.10 as that's the kernel they were using).

-- Steve