* libelf-0.175 breaks objtool @ 2019-02-05 18:38 Steven Rostedt 2019-02-06 2:16 ` Josh Poimboeuf 0 siblings, 1 reply; 13+ messages in thread From: Steven Rostedt @ 2019-02-05 18:38 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: LKML Just a FYI. After a recent upgrade in debian testing, I was not able to build the kernel. I have a custom build of gcc, so I thought it was strange that I was getting something like this (took this from the web, as I don't have the error anymore with the work around, and currently doing a full build): objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info objdump: kernel/.tmp_signal.o: file format not recognized CC arch/x86/kernel/platform-quirks.o objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info objdump: mm/.tmp_swap_slots.o: file format not recognized The web showed this was an error in Arch Linux, with the latest libelf-0.175. I was confused to why an upgrade broke my build since I don't even use the distro gcc to build my kernel. But then realized it was objtool (after doing a make V=1). To make sure that this was the case, I used the gcc command (leaving it out here as it was very long) from a make V=1 to get an object file to play with. Then tried out: $ objdump -dr arch/x86/events/intel/.tmp_rapl.o Which dumped the contents of .tmp_rapl.o nicely. Then performed: $ ./tools/objtool/objtool orc generate --module --no-fp --retpoline "arch/x86/events/intel/.tmp_rapl.o"; And then tried again the objdump, but this time I got: $ objdump -dr arch/x86/events/intel/.tmp_rapl.o objdump: arch/x86/events/intel/.tmp_rapl.o: unable to initialize decompress status for section .debug_info objdump: arch/x86/events/intel/.tmp_rapl.o: unable to initialize decompress status for section .debug_info objdump: arch/x86/events/intel/.tmp_rapl.o: file format not recognized The work around I did was that I found an older libelf on another box, copied it to this box and made the symlink point to it. Low and behold, objtool worked again. Anyone else stumble across this? -- Steve ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2019-02-05 18:38 libelf-0.175 breaks objtool Steven Rostedt @ 2019-02-06 2:16 ` Josh Poimboeuf 2019-02-06 17:16 ` Steven Rostedt 0 siblings, 1 reply; 13+ messages in thread From: Josh Poimboeuf @ 2019-02-06 2:16 UTC (permalink / raw) To: Steven Rostedt; +Cc: LKML On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote: > Just a FYI. > > After a recent upgrade in debian testing, I was not able to build the > kernel. I have a custom build of gcc, so I thought it was strange that > I was getting something like this (took this from the web, as I don't > have the error anymore with the work around, and currently doing a full > build): > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > objdump: kernel/.tmp_signal.o: file format not recognized > CC arch/x86/kernel/platform-quirks.o > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > objdump: mm/.tmp_swap_slots.o: file format not recognized I installed debian testing on a VM, which has libelf 0.175-2, but I can't recreate. Can you share your config? -- Josh ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2019-02-06 2:16 ` Josh Poimboeuf @ 2019-02-06 17:16 ` Steven Rostedt 2020-04-06 21:07 ` Arnd Bergmann 0 siblings, 1 reply; 13+ messages in thread From: Steven Rostedt @ 2019-02-06 17:16 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: LKML On Tue, 5 Feb 2019 20:16:11 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote: > > Just a FYI. > > > > After a recent upgrade in debian testing, I was not able to build the > > kernel. I have a custom build of gcc, so I thought it was strange that > > I was getting something like this (took this from the web, as I don't > > have the error anymore with the work around, and currently doing a full > > build): > > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > objdump: kernel/.tmp_signal.o: file format not recognized > > CC arch/x86/kernel/platform-quirks.o > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > objdump: mm/.tmp_swap_slots.o: file format not recognized > > I installed debian testing on a VM, which has libelf 0.175-2, but I Hmm, I only have libelf-0.175 (no -2) > can't recreate. Can you share your config? > It's just a distro config. Ah, I think it's because I'm compiling my own home built gcc. There seems to be an incompatibility with the binutils that I used and with libelf-0.175. If I build with just the distro gcc, it works. Bah, this means I need to recreate my gcc that I use to build my kernels with :-p As I like to control which gcc I use. -- Steve ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2019-02-06 17:16 ` Steven Rostedt @ 2020-04-06 21:07 ` Arnd Bergmann 2020-04-06 22:16 ` Josh Poimboeuf 0 siblings, 1 reply; 13+ messages in thread From: Arnd Bergmann @ 2020-04-06 21:07 UTC (permalink / raw) To: Steven Rostedt; +Cc: Josh Poimboeuf, LKML On Wed, Feb 6, 2019 at 7:32 PM Steven Rostedt <rostedt@goodmis.org> wrote: > On Tue, 5 Feb 2019 20:16:11 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote: > > > Just a FYI. > > > > > > After a recent upgrade in debian testing, I was not able to build the > > > kernel. I have a custom build of gcc, so I thought it was strange that > > > I was getting something like this (took this from the web, as I don't > > > have the error anymore with the work around, and currently doing a full > > > build): > > > > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > > objdump: kernel/.tmp_signal.o: file format not recognized > > > CC arch/x86/kernel/platform-quirks.o > > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > > objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized > > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > > objdump: mm/.tmp_swap_slots.o: file format not recognized > > > > I installed debian testing on a VM, which has libelf 0.175-2, but I > > Hmm, I only have libelf-0.175 (no -2) > > > can't recreate. Can you share your config? > > > > It's just a distro config. Ah, I think it's because I'm compiling my > own home built gcc. There seems to be an incompatibility with the > binutils that I used and with libelf-0.175. If I build with just the > distro gcc, it works. > > Bah, this means I need to recreate my gcc that I use to build my > kernels with :-p As I like to control which gcc I use. I now see the same problem that you reported using the gcc-9 toolchain I provide on https://kernel.org/pub/tools/crosstool/. Do you have any other information that might help me fix it? Arnd ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-06 21:07 ` Arnd Bergmann @ 2020-04-06 22:16 ` Josh Poimboeuf 2020-04-06 22:31 ` Arnd Bergmann 0 siblings, 1 reply; 13+ messages in thread From: Josh Poimboeuf @ 2020-04-06 22:16 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Steven Rostedt, LKML, Peter Zijlstra On Mon, Apr 06, 2020 at 11:07:15PM +0200, Arnd Bergmann wrote: > On Wed, Feb 6, 2019 at 7:32 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Tue, 5 Feb 2019 20:16:11 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote: > > > > Just a FYI. > > > > > > > > After a recent upgrade in debian testing, I was not able to build the > > > > kernel. I have a custom build of gcc, so I thought it was strange that > > > > I was getting something like this (took this from the web, as I don't > > > > have the error anymore with the work around, and currently doing a full > > > > build): > > > > > > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > > > objdump: kernel/.tmp_signal.o: file format not recognized > > > > CC arch/x86/kernel/platform-quirks.o > > > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > > > objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized > > > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > > > objdump: mm/.tmp_swap_slots.o: file format not recognized > > > > > > I installed debian testing on a VM, which has libelf 0.175-2, but I > > > > Hmm, I only have libelf-0.175 (no -2) > > > > > can't recreate. Can you share your config? > > > > > > > It's just a distro config. Ah, I think it's because I'm compiling my > > own home built gcc. There seems to be an incompatibility with the > > binutils that I used and with libelf-0.175. If I build with just the > > distro gcc, it works. > > > > Bah, this means I need to recreate my gcc that I use to build my > > kernels with :-p As I like to control which gcc I use. > > I now see the same problem that you reported using the gcc-9 > toolchain I provide on https://kernel.org/pub/tools/crosstool/. > > Do you have any other information that might help me fix it? This sounds like an issue I saw before where the toolchain wants to compress debuginfo (DWARF debug_info sections). The "fix" was to add '-gz=none' to KCFLAGS. But if it's a desired feature then we could probably teach objtool to deal with it. It ignores DWARF anyway. -- Josh ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-06 22:16 ` Josh Poimboeuf @ 2020-04-06 22:31 ` Arnd Bergmann 2020-04-07 15:46 ` Arnd Bergmann 0 siblings, 1 reply; 13+ messages in thread From: Arnd Bergmann @ 2020-04-06 22:31 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Steven Rostedt, LKML, Peter Zijlstra On Tue, Apr 7, 2020 at 12:16 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Mon, Apr 06, 2020 at 11:07:15PM +0200, Arnd Bergmann wrote: > > On Wed, Feb 6, 2019 at 7:32 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > On Tue, 5 Feb 2019 20:16:11 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > > On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote: > > > > > Just a FYI. > > > > > > > > > > After a recent upgrade in debian testing, I was not able to build the > > > > > kernel. I have a custom build of gcc, so I thought it was strange that > > > > > I was getting something like this (took this from the web, as I don't > > > > > have the error anymore with the work around, and currently doing a full > > > > > build): > > > > > > > > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > > > > objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info > > > > > objdump: kernel/.tmp_signal.o: file format not recognized > > > > > CC arch/x86/kernel/platform-quirks.o > > > > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > > > > objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info > > > > > objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized > > > > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > > > > objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info > > > > > objdump: mm/.tmp_swap_slots.o: file format not recognized > > > > > > > > I installed debian testing on a VM, which has libelf 0.175-2, but I > > > > > > Hmm, I only have libelf-0.175 (no -2) > > > > > > > can't recreate. Can you share your config? > > > > > > > > > > It's just a distro config. Ah, I think it's because I'm compiling my > > > own home built gcc. There seems to be an incompatibility with the > > > binutils that I used and with libelf-0.175. If I build with just the > > > distro gcc, it works. > > > > > > Bah, this means I need to recreate my gcc that I use to build my > > > kernels with :-p As I like to control which gcc I use. > > > > I now see the same problem that you reported using the gcc-9 > > toolchain I provide on https://kernel.org/pub/tools/crosstool/. > > > > Do you have any other information that might help me fix it? > > This sounds like an issue I saw before where the toolchain wants to > compress debuginfo (DWARF debug_info sections). The "fix" was to add > '-gz=none' to KCFLAGS. > > But if it's a desired feature then we could probably teach objtool to > deal with it. It ignores DWARF anyway. This sounds odd, as I have CONFIG_DEBUG_INFO disabled in all my randconfig builds. It's also odd that I only see the problem in two specific files: arch/x86/realmode/rm/trampoline_64.o (in half of the randconfig builds) and fs/xfs/xfs_trace.o (in only one configuration so far). With this patch I can avoid the first one, which is unconditionally built with -g (why?): --- a/arch/x86/realmode/rm/Makefile +++ b/arch/x86/realmode/rm/Makefile @@ -69,7 +69,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE # --------------------------------------------------------------------------- KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ - -I$(srctree)/arch/x86/boot + -I$(srctree)/arch/x86/boot -gz=none KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables GCOV_PROFILE := n I'll look at the other one tomorrow. Arnd ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-06 22:31 ` Arnd Bergmann @ 2020-04-07 15:46 ` Arnd Bergmann 2020-04-07 16:32 ` Josh Poimboeuf 0 siblings, 1 reply; 13+ messages in thread From: Arnd Bergmann @ 2020-04-07 15:46 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Steven Rostedt, LKML, Peter Zijlstra On Tue, Apr 7, 2020 at 12:31 AM Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Apr 7, 2020 at 12:16 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > It's also odd that I only see the problem in two specific files: > arch/x86/realmode/rm/trampoline_64.o (in half of the randconfig builds) > and fs/xfs/xfs_trace.o (in only one configuration so far). > > With this patch I can avoid the first one, which is unconditionally > built with -g (why?): > > --- a/arch/x86/realmode/rm/Makefile > +++ b/arch/x86/realmode/rm/Makefile > @@ -69,7 +69,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE > # --------------------------------------------------------------------------- > > KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ > - -I$(srctree)/arch/x86/boot > + -I$(srctree)/arch/x86/boot -gz=none > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables > GCOV_PROFILE := n > > I'll look at the other one tomorrow. I found where -g gets added in both cases, and adding -gz=none seems to address all randconfigs with CONFIG_DEBUG_INFO=n: --- a/fs/xfs/Makefile +++ b/fs/xfs/Makefile @@ -7,7 +7,7 @@ ccflags-y += -I $(srctree)/$(src) # needed for trace events ccflags-y += -I $(srctree)/$(src)/libxfs -ccflags-$(CONFIG_XFS_DEBUG) += -g +ccflags-$(CONFIG_XFS_DEBUG) += -g $(call cc-option,-gz=none) obj-$(CONFIG_XFS_FS) += xfs.o diff --git a/arch/x86/Makefile b/arch/x86/Makefile index f16e1fa52a28..17dd9ab538ed 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -40,6 +40,7 @@ REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector) #REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -Wno-address-of-packed-member) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align4)) +REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -gz=none) export REALMODE_CFLAGS # BITS is used as extension for files which are available in a 32 bit I'm now building again with CONFIG_DEBUG_INFO enabled on x86, to see if that triggers the same problem elsewhere. Arnd ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-07 15:46 ` Arnd Bergmann @ 2020-04-07 16:32 ` Josh Poimboeuf 2020-04-07 18:44 ` Arnd Bergmann 0 siblings, 1 reply; 13+ messages in thread From: Josh Poimboeuf @ 2020-04-07 16:32 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Steven Rostedt, LKML, Peter Zijlstra On Tue, Apr 07, 2020 at 05:46:23PM +0200, Arnd Bergmann wrote: > On Tue, Apr 7, 2020 at 12:31 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Apr 7, 2020 at 12:16 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > It's also odd that I only see the problem in two specific files: > > arch/x86/realmode/rm/trampoline_64.o (in half of the randconfig builds) > > and fs/xfs/xfs_trace.o (in only one configuration so far). > > > > With this patch I can avoid the first one, which is unconditionally > > built with -g (why?): > > > > --- a/arch/x86/realmode/rm/Makefile > > +++ b/arch/x86/realmode/rm/Makefile > > @@ -69,7 +69,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE > > # --------------------------------------------------------------------------- > > > > KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ > > - -I$(srctree)/arch/x86/boot > > + -I$(srctree)/arch/x86/boot -gz=none > > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables > > GCOV_PROFILE := n > > > > I'll look at the other one tomorrow. > > I found where -g gets added in both cases, and adding -gz=none > seems to address all randconfigs with CONFIG_DEBUG_INFO=n: > > --- a/fs/xfs/Makefile > +++ b/fs/xfs/Makefile > @@ -7,7 +7,7 @@ > ccflags-y += -I $(srctree)/$(src) # needed for trace events > ccflags-y += -I $(srctree)/$(src)/libxfs > > -ccflags-$(CONFIG_XFS_DEBUG) += -g > +ccflags-$(CONFIG_XFS_DEBUG) += -g $(call cc-option,-gz=none) Maybe they shouldn't have -g in the first place? -- Josh ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-07 16:32 ` Josh Poimboeuf @ 2020-04-07 18:44 ` Arnd Bergmann 2020-04-07 19:30 ` Arnd Bergmann 2020-04-09 7:41 ` Christoph Hellwig 0 siblings, 2 replies; 13+ messages in thread From: Arnd Bergmann @ 2020-04-07 18:44 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Steven Rostedt, LKML, Peter Zijlstra, linux-xfs On Tue, Apr 7, 2020 at 6:33 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > On Tue, Apr 07, 2020 at 05:46:23PM +0200, Arnd Bergmann wrote: > > On Tue, Apr 7, 2020 at 12:31 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > On Tue, Apr 7, 2020 at 12:16 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > It's also odd that I only see the problem in two specific files: > > > arch/x86/realmode/rm/trampoline_64.o (in half of the randconfig builds) > > > and fs/xfs/xfs_trace.o (in only one configuration so far). > > > > > > With this patch I can avoid the first one, which is unconditionally > > > built with -g (why?): > > > > > > --- a/arch/x86/realmode/rm/Makefile > > > +++ b/arch/x86/realmode/rm/Makefile > > > @@ -69,7 +69,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE > > > # --------------------------------------------------------------------------- > > > > > > KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ > > > - -I$(srctree)/arch/x86/boot > > > + -I$(srctree)/arch/x86/boot -gz=none > > > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > > > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables > > > GCOV_PROFILE := n > > > > > > I'll look at the other one tomorrow. > > > > I found where -g gets added in both cases, and adding -gz=none > > seems to address all randconfigs with CONFIG_DEBUG_INFO=n: > > > > --- a/fs/xfs/Makefile > > +++ b/fs/xfs/Makefile > > @@ -7,7 +7,7 @@ > > ccflags-y += -I $(srctree)/$(src) # needed for trace events > > ccflags-y += -I $(srctree)/$(src)/libxfs > > > > -ccflags-$(CONFIG_XFS_DEBUG) += -g > > +ccflags-$(CONFIG_XFS_DEBUG) += -g $(call cc-option,-gz=none) > > Maybe they shouldn't have -g in the first place? That is very possible. The -g has been there since xfs was originally merged back in 2002, and I could not figure out why it was there (unlike the -DSTATIC="" and -DDEBUG flags that are set in the same line). On the other hand, my feeling is that setting -g should not cause problems with objtool, if CONFIG_DEBUG_INFO is ok. Arnd ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-07 18:44 ` Arnd Bergmann @ 2020-04-07 19:30 ` Arnd Bergmann 2020-04-09 7:41 ` Christoph Hellwig 1 sibling, 0 replies; 13+ messages in thread From: Arnd Bergmann @ 2020-04-07 19:30 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Steven Rostedt, LKML, Peter Zijlstra, linux-xfs On Tue, Apr 7, 2020 at 8:44 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Apr 7, 2020 at 6:33 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Tue, Apr 07, 2020 at 05:46:23PM +0200, Arnd Bergmann wrote: > That is very possible. The -g has been there since xfs was originally merged > back in 2002, and I could not figure out why it was there (unlike the > -DSTATIC="" > and -DDEBUG flags that are set in the same line). > > On the other hand, my feeling is that setting -g should not cause problems > with objtool, if CONFIG_DEBUG_INFO is ok. Nevermind, I now see the same problem in lots of files in a configuration setting these options: CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_REDUCED=y # CONFIG_DEBUG_INFO_SPLIT is not set CONFIG_DEBUG_INFO_DWARF4=y CONFIG_DEBUG_INFO_BTF=y Not sure which of these are actually relevant, but I had other configurations setting DEBUG_INFO that are not affected. Arnd ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-07 18:44 ` Arnd Bergmann 2020-04-07 19:30 ` Arnd Bergmann @ 2020-04-09 7:41 ` Christoph Hellwig 2020-04-09 8:25 ` Arnd Bergmann 1 sibling, 1 reply; 13+ messages in thread From: Christoph Hellwig @ 2020-04-09 7:41 UTC (permalink / raw) To: Arnd Bergmann Cc: Josh Poimboeuf, Steven Rostedt, LKML, Peter Zijlstra, linux-xfs On Tue, Apr 07, 2020 at 08:44:11PM +0200, Arnd Bergmann wrote: > That is very possible. The -g has been there since xfs was originally merged > back in 2002, and I could not figure out why it was there (unlike the > -DSTATIC="" > and -DDEBUG flags that are set in the same line). > > On the other hand, my feeling is that setting -g should not cause problems > with objtool, if CONFIG_DEBUG_INFO is ok. I suspect we shouldn't force -g ourselves in xfs. Care to send a patch? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-09 7:41 ` Christoph Hellwig @ 2020-04-09 8:25 ` Arnd Bergmann 2020-04-10 0:46 ` Dave Chinner 0 siblings, 1 reply; 13+ messages in thread From: Arnd Bergmann @ 2020-04-09 8:25 UTC (permalink / raw) To: Christoph Hellwig Cc: Josh Poimboeuf, Steven Rostedt, LKML, Peter Zijlstra, linux-xfs On Thu, Apr 9, 2020 at 9:41 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Tue, Apr 07, 2020 at 08:44:11PM +0200, Arnd Bergmann wrote: > > That is very possible. The -g has been there since xfs was originally merged > > back in 2002, and I could not figure out why it was there (unlike the > > -DSTATIC="" > > and -DDEBUG flags that are set in the same line). > > > > On the other hand, my feeling is that setting -g should not cause problems > > with objtool, if CONFIG_DEBUG_INFO is ok. > > I suspect we shouldn't force -g ourselves in xfs. Care to send a patch? Done. On a related topic, I noticed how the CONFIG_DEBUG flag used to control whether functions marked STATIC get inlined or not, but now they are always marked noinline, apparently in an attempt to get more readable object code even when not debugging. I also see that during early v2.6, XFS used 'STATIC' almost exclusively, while newly added functions tend to use plain 'static' instead. Is this something worth revisiting to see if inlining would make a difference to performance or are you reasonably sure it does not? Arnd ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: libelf-0.175 breaks objtool 2020-04-09 8:25 ` Arnd Bergmann @ 2020-04-10 0:46 ` Dave Chinner 0 siblings, 0 replies; 13+ messages in thread From: Dave Chinner @ 2020-04-10 0:46 UTC (permalink / raw) To: Arnd Bergmann Cc: Christoph Hellwig, Josh Poimboeuf, Steven Rostedt, LKML, Peter Zijlstra, linux-xfs On Thu, Apr 09, 2020 at 10:25:14AM +0200, Arnd Bergmann wrote: > On Thu, Apr 9, 2020 at 9:41 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > On Tue, Apr 07, 2020 at 08:44:11PM +0200, Arnd Bergmann wrote: > > > That is very possible. The -g has been there since xfs was originally merged > > > back in 2002, and I could not figure out why it was there (unlike the > > > -DSTATIC="" > > > and -DDEBUG flags that are set in the same line). > > > > > > On the other hand, my feeling is that setting -g should not cause problems > > > with objtool, if CONFIG_DEBUG_INFO is ok. > > > > I suspect we shouldn't force -g ourselves in xfs. Care to send a patch? > > Done. > > On a related topic, I noticed how the CONFIG_DEBUG flag used to control > whether functions marked STATIC get inlined or not, but now they are always > marked noinline, apparently in an attempt to get more readable object code > even when not debugging. I also see that during early v2.6, XFS used > 'STATIC' almost exclusively, while newly added functions tend to use plain > 'static' instead. > > Is this something worth revisiting to see if inlining would make a difference > to performance or are you reasonably sure it does not? The "noinline" here is really "noinline_for_stack", but it predates the noinline_for_stack annotation and never got updated. i.e. the noinline was added because of the historic stack usage problems we had with 4k stacks on x86 and 8k stacks on x86-64. We had to split large functions up to reduce the number of on-stack variables in them, but that was then being undone by the compiler deciding to automatically inline single use static functions. I know the x86-64 stack issues have gone away now we have CONFIG_VMAP_STACK, but people can still turn that off so we still have to be careful about stack usage caused by inlining single use functions... Hence I'm not sure we can just remove this - we'd need to go back and investigate what impact it has on stack usage in the writeback allocation path and other historic problematic code paths to determine if they should still be annotated or not. They could be converted with s/STATIC/static noinline_for_stack/ on a case by case basis, and then the rest could probably just be case converted with sed... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-04-10 0:46 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-05 18:38 libelf-0.175 breaks objtool Steven Rostedt 2019-02-06 2:16 ` Josh Poimboeuf 2019-02-06 17:16 ` Steven Rostedt 2020-04-06 21:07 ` Arnd Bergmann 2020-04-06 22:16 ` Josh Poimboeuf 2020-04-06 22:31 ` Arnd Bergmann 2020-04-07 15:46 ` Arnd Bergmann 2020-04-07 16:32 ` Josh Poimboeuf 2020-04-07 18:44 ` Arnd Bergmann 2020-04-07 19:30 ` Arnd Bergmann 2020-04-09 7:41 ` Christoph Hellwig 2020-04-09 8:25 ` Arnd Bergmann 2020-04-10 0:46 ` Dave Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).