Message ID | 20210414200146.2663044-14-andrii@kernel.org (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | BPF |
Headers | show |
Series | BPF static linker: support externs | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | fail | Series longer than 15 patches |
netdev/tree_selection | success | Clearly marked for bpf-next |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | warning | 8 maintainers not CCed: linux-kselftest@vger.kernel.org yhs@fb.com kpsingh@kernel.org kafai@fb.com ast@kernel.org john.fastabend@gmail.com songliubraving@fb.com shuah@kernel.org |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 32 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
netdev/header_inline | success | Link |
On 4/14/21 1:01 PM, Andrii Nakryiko wrote: > While -Og is designed to work well with debugger, it's still inferior to -O0 > in terms of debuggability experience. It will cause some variables to still be > inlined, it will also prevent single-stepping some statements and otherwise > interfere with debugging experience. So switch to -O0 which turns off any > optimization and provides the best debugging experience. > > Signed-off-by: Andrii Nakryiko <andrii@kernel.org> > --- > tools/testing/selftests/bpf/Makefile | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile > index 6448c626498f..22a88580b491 100644 > --- a/tools/testing/selftests/bpf/Makefile > +++ b/tools/testing/selftests/bpf/Makefile > @@ -21,7 +21,7 @@ endif > > BPF_GCC ?= $(shell command -v bpf-gcc;) > SAN_CFLAGS ?= > -CFLAGS += -g -Og -rdynamic -Wall $(GENFLAGS) $(SAN_CFLAGS) \ > +CFLAGS += -g -O0 -rdynamic -Wall $(GENFLAGS) $(SAN_CFLAGS) \ > -I$(CURDIR) -I$(INCLUDE_DIR) -I$(GENDIR) -I$(LIBDIR) \ > -I$(TOOLSINCDIR) -I$(APIDIR) -I$(OUTPUT) \ > -Dbpf_prog_load=bpf_prog_test_load \ > @@ -201,7 +201,7 @@ $(DEFAULT_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile) \ > $(HOST_BPFOBJ) | $(HOST_BUILD_DIR)/bpftool > $(Q)$(MAKE) $(submake_extras) -C $(BPFTOOLDIR) \ > CC=$(HOSTCC) LD=$(HOSTLD) \ > - EXTRA_CFLAGS='-g -Og' \ > + EXTRA_CFLAGS='-g -O0' \ lol. so much for gcc docs :)
From: Andrii Nakryiko > Sent: 14 April 2021 21:02 > > While -Og is designed to work well with debugger, it's still inferior to -O0 > in terms of debuggability experience. It will cause some variables to still be > inlined, it will also prevent single-stepping some statements and otherwise > interfere with debugging experience. So switch to -O0 which turns off any > optimization and provides the best debugging experience. Surely the selftests need to use the normal compiler options so the compiler is generating the same type of code. Otherwise you are likely to miss out some instructions completely. For normal code I actually prefer using -O2 when dubugging. If/when you need to look at the generated code you can see the wood for the trees, with -O0 the code is typically full of memory read/write to/from the stack. About the only annoying thing is tail-calls. They can get confusing. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Wed, Apr 14, 2021 at 3:15 PM David Laight <David.Laight@aculab.com> wrote: > > From: Andrii Nakryiko > > Sent: 14 April 2021 21:02 > > > > While -Og is designed to work well with debugger, it's still inferior to -O0 > > in terms of debuggability experience. It will cause some variables to still be > > inlined, it will also prevent single-stepping some statements and otherwise > > interfere with debugging experience. So switch to -O0 which turns off any > > optimization and provides the best debugging experience. > > Surely the selftests need to use the normal compiler options > so the compiler is generating the same type of code. > Otherwise you are likely to miss out some instructions completely. > I don't know, it's not like I'm trying to validate that GCC is generating a valid assembly. And there is almost nothing in libbpf and selftests that relies on delicate timing, so I don't think we should worry about changing timing characteristics. And there is nothing performance-critical in libbpf logic itself either, for the most part. So I don't see much harm in running selftests in debug mode. > For normal code I actually prefer using -O2 when dubugging. > If/when you need to look at the generated code you can see > the wood for the trees, with -O0 the code is typically > full of memory read/write to/from the stack. Whenever I try debugging anything in selftest+libbpf+bpftool, if any of those components are built with -O2, it makes it almost impossible to figure anything out in debugger. So I always go back and force all of them to -O0. So that's what this patch is doing, so that I and others don't have to go through this every single time we need to debug something. > > About the only annoying thing is tail-calls. > They can get confusing. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index 6448c626498f..22a88580b491 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -21,7 +21,7 @@ endif BPF_GCC ?= $(shell command -v bpf-gcc;) SAN_CFLAGS ?= -CFLAGS += -g -Og -rdynamic -Wall $(GENFLAGS) $(SAN_CFLAGS) \ +CFLAGS += -g -O0 -rdynamic -Wall $(GENFLAGS) $(SAN_CFLAGS) \ -I$(CURDIR) -I$(INCLUDE_DIR) -I$(GENDIR) -I$(LIBDIR) \ -I$(TOOLSINCDIR) -I$(APIDIR) -I$(OUTPUT) \ -Dbpf_prog_load=bpf_prog_test_load \ @@ -201,7 +201,7 @@ $(DEFAULT_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile) \ $(HOST_BPFOBJ) | $(HOST_BUILD_DIR)/bpftool $(Q)$(MAKE) $(submake_extras) -C $(BPFTOOLDIR) \ CC=$(HOSTCC) LD=$(HOSTLD) \ - EXTRA_CFLAGS='-g -Og' \ + EXTRA_CFLAGS='-g -O0' \ OUTPUT=$(HOST_BUILD_DIR)/bpftool/ \ prefix= DESTDIR=$(HOST_SCRATCH_DIR)/ install @@ -219,7 +219,7 @@ $(BPFOBJ): $(wildcard $(BPFDIR)/*.[ch] $(BPFDIR)/Makefile) \ ../../../include/uapi/linux/bpf.h \ | $(INCLUDE_DIR) $(BUILD_DIR)/libbpf $(Q)$(MAKE) $(submake_extras) -C $(BPFDIR) OUTPUT=$(BUILD_DIR)/libbpf/ \ - EXTRA_CFLAGS='-g -Og' \ + EXTRA_CFLAGS='-g -O0' \ DESTDIR=$(SCRATCH_DIR) prefix= all install_headers ifneq ($(BPFOBJ),$(HOST_BPFOBJ)) @@ -227,7 +227,7 @@ $(HOST_BPFOBJ): $(wildcard $(BPFDIR)/*.[ch] $(BPFDIR)/Makefile) \ ../../../include/uapi/linux/bpf.h \ | $(INCLUDE_DIR) $(HOST_BUILD_DIR)/libbpf $(Q)$(MAKE) $(submake_extras) -C $(BPFDIR) \ - EXTRA_CFLAGS='-g -Og' \ + EXTRA_CFLAGS='-g -O0' \ OUTPUT=$(HOST_BUILD_DIR)/libbpf/ CC=$(HOSTCC) LD=$(HOSTLD) \ DESTDIR=$(HOST_SCRATCH_DIR)/ prefix= all install_headers endif
While -Og is designed to work well with debugger, it's still inferior to -O0 in terms of debuggability experience. It will cause some variables to still be inlined, it will also prevent single-stepping some statements and otherwise interfere with debugging experience. So switch to -O0 which turns off any optimization and provides the best debugging experience. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> --- tools/testing/selftests/bpf/Makefile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)