From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99935 invoked by alias); 14 Dec 2016 22:05:31 -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 99920 invoked by uid 89); 14 Dec 2016 22:05:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:f2ee7ac, H*f:sk:f2ee7ac X-HELO: mail-qk0-f173.google.com Received: from mail-qk0-f173.google.com (HELO mail-qk0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Dec 2016 22:05:29 +0000 Received: by mail-qk0-f173.google.com with SMTP id q130so37058198qke.1 for ; Wed, 14 Dec 2016 14:05:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1inQ1wPbPTb8Awf0hoz+Cyzs7C5UvQLdbdAGEUyJkDc=; b=SaX5Q0jyTxj1OLz7CbMdIkK2DScpyVS2imclrlNbkFgvXt0NB50nyfg6aSWzZDo9nZ 3TbpLTAEwvpmpmRf1TyvK8I8UYGimBSg+bdCTloPsjmcZp2rKswGEI58BjgpMHsJB9U6 t4PYOlwPjLIIvE9jyRTcZDPDycX7UOIDqus1LeiwQeyvkgZx/RdbHVfklNvZlWuk9mEV KqqK+oJb6qp/x91Bb1A3n9jxl0Ega28Wanuq1PXNdT3rmgmIOpvLLwWKmBCd1ePDwlMS R5uTo2ME8uvJ6SbLxQv14q9NtfMfZZ+5rS44QidU0ptuOEvW6FeUWOYnsQ8IXcntR9hN Z0TQ== X-Gm-Message-State: AKaTC01WgB59e1XMt1egtkXoGXyH4JNIgirlsGERdXDzvW0LfMyYafcIgROHv2XoV0mBF/Mo52fRttT4Vf2P0Q== X-Received: by 10.233.216.71 with SMTP id u68mr99819767qkf.161.1481753127920; Wed, 14 Dec 2016 14:05:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.11 with HTTP; Wed, 14 Dec 2016 14:05:27 -0800 (PST) In-Reply-To: References: <20161212104825.GA25542@E107787-LIN> From: Yao Qi Date: Wed, 14 Dec 2016 22:05:00 -0000 Message-ID: Subject: Re: [RFC] PR 20939: Handle error in disassembly To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00301.txt.bz2 On 16-12-14 17:31:18, Pedro Alves wrote: > > Did you try to find the discussions around when the current > interface based on throwing (using longjmp at the time) was added? > Maybe the "return -1" option was considered back then, but > discarded for some reason? Such interface was added in 1993, 5d0734a7d74cf01b73303aeb884b719b4b220035 there wasn't any discussions. > > E.g., looks like simply "return -1" would lose the actual > address that failed to be read, in case opcodes does several > reads in sequence and its not the first that fails. We could > add some other means to get at that, of course. > I thought about this beofre. We can't get the actual address that failed to be read today, because we read a piece of memory in dis_asm_read_memory, but only report error from the starting address. So I think it isn't very important to report the error with the accurate memory address failed to be read. -- Yao