[v2,00/10] Enable undefined behavior sanitizer

Message ID 20180830024416.23386-1-tom@tromey.com
Headers show
Series
  • Enable undefined behavior sanitizer
Related show

Message

Tom Tromey Aug. 30, 2018, 2:44 a.m.
This is v2 of the series to enable the undefined behavior sanitizer
for gdb.  This is done by default in development mode, but can be
disabled.

I believe this version addresses all the review comments.

Tested (*) by the buildbot.

(*) However, as I mentioned in another thread, the s390 builders do
not like this series.  I get many, many failures.  Looking at the
gdb.log, though, the failures seem to be coming from libstdc++ debug
mode -- which this series does not enable.

    Here's a link to one such build in case you are curious:

    Full Build URL:
	    <http://gdb-build.sergiodj.net/builders/RHEL-s390x-m64/builds/8180>

    Testsuite log (gdb.sum and gdb.log) URL(s):
	    <http://gdb-build.sergiodj.net/results/RHEL-s390x-m64/try/5f/5fe3f3e4633df1ea76ff24a2732d7c73dc983b90/0/>

Until this is understood I am reluctant to push this series.

Tom

Comments

Tom Tromey Sept. 12, 2018, 11:48 a.m. | #1
>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:


Tom> This is v2 of the series to enable the undefined behavior sanitizer
Tom> for gdb.  This is done by default in development mode, but can be
Tom> disabled.

Update on this series...

Tom> I believe this version addresses all the review comments.

For the record, subsequently, Pedro and I discussed the need to document
this a bit more.  I'll include a patch for this in the next revision of
the series.

Tom> Tested (*) by the buildbot.

Tom> (*) However, as I mentioned in another thread, the s390 builders do
Tom> not like this series.  I get many, many failures.  Looking at the
Tom> gdb.log, though, the failures seem to be coming from libstdc++ debug
Tom> mode -- which this series does not enable.

This is all explained now.

Sergio pointed out that the builders are enabling -D_GLIBCXX_DEBUG.  I'm
glad that mystery is solved.

A failure with -D_GLIBCXX_DEBUG enabled just results in a crash, without
much useful information to go by.  This is often fine, but in this case
I could only reproduce on s390, where I couldn't log in to reproduce for
myself.

So, I hacked the testsuite Makefile to run just a single test .exp that
I knew to fail, and then arranged to get a real stack trace.  See the
appended patch.

This pointed out that there was a bug in one of the patches in the series.
Namely, this code in dwarf2-frame.c:

	    struct dwarf2_frame_state_reg *retaddr_reg =
	      &fs.regs.reg[fs.retaddr_column];

... will reference past the end of the array in some cases.  When reg is
just an ordinary pointer this is "ok" -- possibly undefined behavior
depending on the index in use, but not likely to cause a crash.  But the
series changes reg to a std::vector, where this is invalid.

Tom

diff --git a/gdb/testsuite/Makefile.in b/gdb/testsuite/Makefile.in
index 07e0928a9f8..3bfc4d9f847 100644
--- a/gdb/testsuite/Makefile.in
+++ b/gdb/testsuite/Makefile.in
@@ -48,7 +48,7 @@ EXPECT = `if [ "$${READ1}" != "" ] ; then \
 
 RUNTEST = $(RUNTEST_FOR_TARGET)
 
-RUNTESTFLAGS =
+override RUNTESTFLAGS := gdb.cp/extern-c.exp
 
 FORCE_PARALLEL =
 
@@ -153,7 +153,11 @@ CHECK_TARGET = $(if $(RACY_ITER),$(addsuffix -racy,$(CHECK_TARGET_TMP)),$(CHECK_
 # because GNU make 3.82 has a bug preventing MAKEFLAGS from being used
 # in conditions.
 check: all $(abs_builddir)/site.exp
-	$(MAKE) $(CHECK_TARGET)
+	-$(MAKE) $(CHECK_TARGET)
+	cat gdb.log
+	/bin/gdb -batch -ex 'run' -ex 'bt' \
+		--args ../gdb -batch -ex 'file outputs/gdb.cp/extern-c/extern-c' \
+		-ex 'break c_func' -ex 'run' -ex 'rbreak c_funcs'
 
 check-read1:
 	$(MAKE) READ1="1" check