From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100221 invoked by alias); 15 Jun 2015 13:36:18 -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 100211 invoked by uid 89); 15 Jun 2015 13:36:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 15 Jun 2015 13:36:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 37467289A0; Mon, 15 Jun 2015 09:36:15 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jt-12blyW2nj; Mon, 15 Jun 2015 09:36:15 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 084BBD3C65; Mon, 15 Jun 2015 09:36:15 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 944C2406D9; Mon, 15 Jun 2015 06:36:13 -0700 (PDT) Date: Mon, 15 Jun 2015 13:36:00 -0000 From: Joel Brobecker To: Yao Qi Cc: Martin Simmons , gdb-patches@sourceware.org Subject: Re: [PATCH] Prevent internal-error when computing $pc in ARM assembly code Message-ID: <20150615133613.GE25717@adacore.com> References: <201505200949.t4K9nlqt015737@heapu.cam.lispworks.com> <20150609184408.GG2855@adacore.com> <86wpz5s31d.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86wpz5s31d.fsf@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-06/txt/msg00305.txt.bz2 > > It would be good to have a few more details about what causes us > > to be in a situation where we'd be failing to read memory at > > an address. Perhaps just showing the disassembled code and > > a quick explanation of what happens might be sufficient. > > I agree with Joel that we need more details about the problem you are > trying to fix. I think the problem comes from improper unwinding of a function having an unusual frame, causing us to use a bogus return address which could be anywhere, including in an unreadable memory area. -- Joel