diff mbox series

xfs: stop CONFIG_XFS_DEBUG from changing compiler flags

Message ID 20200409080909.3646059-1-arnd@arndb.de (mailing list archive)
State Accepted
Headers show
Series xfs: stop CONFIG_XFS_DEBUG from changing compiler flags | expand

Commit Message

Arnd Bergmann April 9, 2020, 8:08 a.m. UTC
I ran into a linker warning in XFS that originates from a mismatch
between libelf, binutils and objtool when certain files in the kernel
are built with "gcc -g":

x86_64-linux-ld: fs/xfs/xfs_trace.o: unable to initialize decompress status for section .debug_info

After some discussion, nobody could identify why xfs sets this flag
here. CONFIG_XFS_DEBUG used to enable lots of unrelated settings, but
now its main purpose is to enable extra consistency checks and assertions
that are unrelated to the debug info.

Remove the Makefile logic to set the flag here. If anyone relies
on the debug info, this can simply be enabled again with the global
CONFIG_DEBUG_INFO option.

Suggested-by: Christoph Hellwig <hch@infradead.org>
Link: https://lore.kernel.org/lkml/20200409074130.GD21033@infradead.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/xfs/Makefile | 2 --
 1 file changed, 2 deletions(-)

Comments

Brian Foster April 9, 2020, 12:51 p.m. UTC | #1
On Thu, Apr 09, 2020 at 10:08:56AM +0200, Arnd Bergmann wrote:
> I ran into a linker warning in XFS that originates from a mismatch
> between libelf, binutils and objtool when certain files in the kernel
> are built with "gcc -g":
> 
> x86_64-linux-ld: fs/xfs/xfs_trace.o: unable to initialize decompress status for section .debug_info
> 
> After some discussion, nobody could identify why xfs sets this flag
> here. CONFIG_XFS_DEBUG used to enable lots of unrelated settings, but
> now its main purpose is to enable extra consistency checks and assertions
> that are unrelated to the debug info.
> 
> Remove the Makefile logic to set the flag here. If anyone relies
> on the debug info, this can simply be enabled again with the global
> CONFIG_DEBUG_INFO option.
> 
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Link: https://lore.kernel.org/lkml/20200409074130.GD21033@infradead.org/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

Seems reasonable.

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  fs/xfs/Makefile | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
> index 4f95df476181..ff94fb90a2ee 100644
> --- a/fs/xfs/Makefile
> +++ b/fs/xfs/Makefile
> @@ -7,8 +7,6 @@
>  ccflags-y += -I $(srctree)/$(src)		# needed for trace events
>  ccflags-y += -I $(srctree)/$(src)/libxfs
>  
> -ccflags-$(CONFIG_XFS_DEBUG) += -g
> -
>  obj-$(CONFIG_XFS_FS)		+= xfs.o
>  
>  # this one should be compiled first, as the tracing macros can easily blow up
> -- 
> 2.26.0
>
Allison Henderson April 9, 2020, 3:50 p.m. UTC | #2
On 4/9/20 1:08 AM, Arnd Bergmann wrote:
> I ran into a linker warning in XFS that originates from a mismatch
> between libelf, binutils and objtool when certain files in the kernel
> are built with "gcc -g":
> 
> x86_64-linux-ld: fs/xfs/xfs_trace.o: unable to initialize decompress status for section .debug_info
> 
> After some discussion, nobody could identify why xfs sets this flag
> here. CONFIG_XFS_DEBUG used to enable lots of unrelated settings, but
> now its main purpose is to enable extra consistency checks and assertions
> that are unrelated to the debug info.
> 
> Remove the Makefile logic to set the flag here. If anyone relies
> on the debug info, this can simply be enabled again with the global
> CONFIG_DEBUG_INFO option.
> 
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Link: https://urldefense.com/v3/__https://lore.kernel.org/lkml/20200409074130.GD21033@infradead.org/__;!!GqivPVa7Brio!JzJUQORI8aWjYFMvoyVmkgYSofJexLQn7p16KvP39F-NjuIzEXWqypgw0FnCyrdFtmZm$
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Ok, looks good
Reviewed-by: Allison Collins <allison.henderson@oracle.com>

> ---
>   fs/xfs/Makefile | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
> index 4f95df476181..ff94fb90a2ee 100644
> --- a/fs/xfs/Makefile
> +++ b/fs/xfs/Makefile
> @@ -7,8 +7,6 @@
>   ccflags-y += -I $(srctree)/$(src)		# needed for trace events
>   ccflags-y += -I $(srctree)/$(src)/libxfs
>   
> -ccflags-$(CONFIG_XFS_DEBUG) += -g
> -
>   obj-$(CONFIG_XFS_FS)		+= xfs.o
>   
>   # this one should be compiled first, as the tracing macros can easily blow up
>
Dave Chinner April 10, 2020, 1:01 a.m. UTC | #3
On Thu, Apr 09, 2020 at 10:08:56AM +0200, Arnd Bergmann wrote:
> I ran into a linker warning in XFS that originates from a mismatch
> between libelf, binutils and objtool when certain files in the kernel
> are built with "gcc -g":
> 
> x86_64-linux-ld: fs/xfs/xfs_trace.o: unable to initialize decompress status for section .debug_info
> 
> After some discussion, nobody could identify why xfs sets this flag
> here. CONFIG_XFS_DEBUG used to enable lots of unrelated settings, but
> now its main purpose is to enable extra consistency checks and assertions
> that are unrelated to the debug info.

I'm pretty sure it was needed for the original kgdb integration back
in the early 2000s. That was when SGI used to patch their XFS dev
tree with kgdb and debug symbols were needed by the custom kgdb
modules that were ported across from the Irix kernel debugger.

ISTR that the early kcrash kernel dump analysis tools (again,
originated from the Irix "icrash" kernel dump tools) had custom XFS
debug scripts that needed also the debug info to work correctly...

Which is a long way of saying "we don't need it anymore" instead of
"nobody knows why it was set"... :)

With an update to commit message:

Reviewed-by: Dave Chinner <dchinner@redhat.com>
diff mbox series

Patch

diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
index 4f95df476181..ff94fb90a2ee 100644
--- a/fs/xfs/Makefile
+++ b/fs/xfs/Makefile
@@ -7,8 +7,6 @@ 
 ccflags-y += -I $(srctree)/$(src)		# needed for trace events
 ccflags-y += -I $(srctree)/$(src)/libxfs
 
-ccflags-$(CONFIG_XFS_DEBUG) += -g
-
 obj-$(CONFIG_XFS_FS)		+= xfs.o
 
 # this one should be compiled first, as the tracing macros can easily blow up