From patchwork Wed Sep 12 11:48:30 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Tromey X-Patchwork-Id: 29328 Received: (qmail 106012 invoked by alias); 12 Sep 2018 11:49:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 105979 invoked by uid 89); 12 Sep 2018 11:49:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=mystery, Hx-languages-length:2641 X-HELO: gateway20.websitewelcome.com Received: from gateway20.websitewelcome.com (HELO gateway20.websitewelcome.com) (192.185.45.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Sep 2018 11:49:35 +0000 Received: from cm15.websitewelcome.com (cm15.websitewelcome.com [100.42.49.9]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 15DBF400E032E for ; Wed, 12 Sep 2018 06:49:34 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 03dHgcbBBbXuJ03dsgvcIc; Wed, 12 Sep 2018 06:49:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PmcWXJsKovo5C2+/Erw0tQGUmYUSqHCpzRdJ5M/JJVI=; b=lAd/U0hJGYXQe1mUy+roZasqv7 vEySasILhJK9UGBLktCV+l5pWG1m25vP76ZexsuKeKBSIIUHVjGdqwONcGUya5VtMzctMCX+wBADT 7jHGd6oSAw4lIfu09lQ/QH4TY; Received: from 97-122-189-157.hlrn.qwest.net ([97.122.189.157]:57704 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g03dH-004Cfe-Fh; Wed, 12 Sep 2018 06:48:31 -0500 From: Tom Tromey To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 00/10] Enable undefined behavior sanitizer References: <20180830024416.23386-1-tom@tromey.com> Date: Wed, 12 Sep 2018 05:48:30 -0600 In-Reply-To: <20180830024416.23386-1-tom@tromey.com> (Tom Tromey's message of "Wed, 29 Aug 2018 20:44:06 -0600") Message-ID: <87lg87j5rl.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 >>>>> "Tom" == Tom Tromey 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