Re: [PATCH] trace-cmd: Fix build with gcc-10

From: Steven Rostedt <rostedt@goodmis.org>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH] trace-cmd: Fix build with gcc-10
Date: Mon, 20 Apr 2020 15:53:20 -0400	[thread overview]
Message-ID: <20200420155320.55d3c3f2@gandalf.local.home> (raw)
In-Reply-To: <20200420154325.6072d96b@gandalf.local.home>

On Mon, 20 Apr 2020 15:43:25 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 17 Apr 2020 21:39:14 +0100
> Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> 
> > The build fails while building with gcc-10 with the error:
> > multiple definition of `common_type_field'  
> 
> I'd say this is a bug in gcc.
> 
> Both variables are static to the files. Why is it complaining?
> 
> If its a new "feature" of gcc, I would look to see if there's a way to
> quiet the warning, and adding that to the Makefile instead.
> 

And when doing a search of "gcc 10" "multiple definitions" the first hit
was this:

  https://patchwork.kernel.org/patch/11372767/

Which is Tzvetomir's patch (which I accepted, but didn't think too much
about it).

I was thinking of just adding -fcommon, but then took a look at the
definition of this:

"-fcommon

    In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the extern keyword, which do not allocate storage.

    The default is -fno-common, which specifies that the compiler places uninitialized global variables in the BSS section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit.

    The -fcommon places uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors.
"

OK, so this has a warning due to linking optimizations, and when there's
common names, it causes linking to do some more tricks, and can cause
issues when linking with C++ programs (like KernelShark).

OK, I'll take this patch, and may even enable a -fno-common to find other
cases of this without having to wait till my distro adds gcc 10 by default.

-- Steve