From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27632 invoked by alias); 9 Oct 2018 18:10:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 27623 invoked by uid 89); 9 Oct 2018 18:10:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=hide X-HELO: resqmta-po-06v.sys.comcast.net Received: from resqmta-po-06v.sys.comcast.net (HELO resqmta-po-06v.sys.comcast.net) (96.114.154.165) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Oct 2018 18:10:13 +0000 Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-06v.sys.comcast.net with ESMTP id 9uqbg3DN3Vp6y9wSRg2rUJ; Tue, 09 Oct 2018 18:10:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1539108611; bh=vQyvrJg7AtOWvHpOz8YyUZZNsqU+aWgZZjYQ0OxaCRM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=gsXAqcJXMDNWUnau5GLiMRBIWPd8a0iM9t285/6Tg9hpQ+CM+4PNCTx6TPzqTMdf/ iiZQQQQgWjpbqj0B2I9f4HR3p26qHBxz5f/3EpqED3od5fRu+l2cCFE/zUtST8qQiE JTs3DBbPqJdxCXoVtSNBYrktCLhD8z+44IeeoEoL30b7SfKYqlfwPiyZTk6Xt/uS2C GM38oUIXyi7bT8Abc09hxHUpPwp1N7YLuENlM5UOC1jzvJI4eoi9SwppvOstfmKYOu z0kuEfgLrgsQSbl0G6ZhHjUt5Hra1Vgx8m2mN1kYG5c4dhx1cVuNvDaKWiqGjbuzwf AjH19DvKcvdFg== Received: from [192.168.10.125] ([73.60.223.101]) by resomta-po-16v.sys.comcast.net with ESMTPSA id 9wSQgm16ok4KV9wSQgb55D; Tue, 09 Oct 2018 18:10:11 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [PATCH][gdb] fix unsigned overflow in charset.c From: Paul Koning In-Reply-To: <9ea7a1f6-5c3f-c569-6bba-ca9e21711de1@FreeBSD.org> Date: Tue, 09 Oct 2018 18:10:00 -0000 Cc: Pedro Alves , gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DCE0AB8-5647-4AD1-B0AA-3A8350C3BE6D@comcast.net> References: <7B48D309-445E-4141-A87A-1F3D5FA70EFD@comcast.net> <1acace4a-a5c6-abaf-f070-9c2e6768b6f2@redhat.com> <9ea7a1f6-5c3f-c569-6bba-ca9e21711de1@FreeBSD.org> To: John Baldwin X-SW-Source: 2018-10/txt/msg00233.txt.bz2 > On Oct 9, 2018, at 1:57 PM, John Baldwin wrote: >=20 > On 10/9/18 10:40 AM, Paul Koning wrote: >>=20 >>=20 >>> On Oct 9, 2018, at 1:31 PM, Pedro Alves wrote: >>>=20 >>> On 10/09/2018 06:19 PM, Paul Koning wrote: >>>> This fixed an overflow in pointer arithmetic that crashes GDB on Mac O= S. >>>=20 >>> _unsigned_ overflow? That isn't undefined. Do we really want to trap >>> those? I don't think GCC's version does that. >>>=20 >>> From:=20 >>> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#silencing-u= nsigned-integer-overflow >>> seems like there's a way to disable it. >>>=20 >>> Thanks, >>> Pedro Alves >>=20 >> You're right, it was an LLVM build. I know unsigned overflow is well de= fined with integers; is that true for pointers? >>=20 >> Given that GDB triggers this issue, should the GDB build do that LLVM wo= rkaround if LLVM is used to build it?=20=20 >>=20 >> But it seems simpler to use the proposed patch; clearly the intent is to= back up a pointer by -(space_left) and doing that operation on a signed ty= pe seems like a logical thing to do, it makes the intended meaning clear. >=20 > I also ran into the same failure using LLVM's ubsan on FreeBSD but in a d= ifferent > use of obstack_blank_fast(). If we wanted to fix this, I wonder if we'd = instead > want to fix it centrally in obstack_blank_fast (e.g. by using a ptrdiff_t= cast) > rather than fixing various consumers of the API. That would be a change = to > libiberty though, not just gdb. I suppose. But casts in macros scare me, they can hide mistakes. It seems= more reasonable to have the caller be responsible for creating a value of = the correct type. Since it's an adjustment, I suppose the cast should be f= or ptrdiff_t rather than ssize_t? paul