From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27416 invoked by alias); 23 Aug 2013 01:08:40 -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 27401 invoked by uid 89); 23 Aug 2013 01:08:40 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.2 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 01:08:10 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VCfrD-0007TL-9C from Yao_Qi@mentor.com ; Thu, 22 Aug 2013 18:08:07 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Aug 2013 18:08:07 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Aug 2013 18:08:07 -0700 Message-ID: <5216B5C9.3010402@codesourcery.com> Date: Fri, 23 Aug 2013 01:08:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: Mark Kettenis , , Subject: Re: [COMMIT] Re: [PATCH] PR gdb/15871: Unavailable entry value is not shown correctly References: <1376379586-24150-1-git-send-email-yao@codesourcery.com> <1376379586-24150-3-git-send-email-yao@codesourcery.com> <87siy4gsn4.fsf@fleche.redhat.com> <521458A8.7060304@codesourcery.com> <5214D03C.9040703@redhat.com> <201308211447.r7LEld3t025510@glazunov.sibelius.xs4all.nl> <5214DD85.5060605@redhat.com> <52156841.8030105@codesourcery.com> <5215E241.6010008@redhat.com> In-Reply-To: <5215E241.6010008@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-08/txt/msg00658.txt.bz2 On 08/22/2013 06:04 PM, Pedro Alves wrote: > I meant deprecated_xfer_memory, which does: > > 0 means that we can't handle this. If errno has been set, it is the > error which prevented us from doing it (FIXME: What about bfd_error?). > > and using errno values as error indication in target.h methods. E.g., > target_read_memory: > > /* Read LEN bytes of target memory at address MEMADDR, placing the results in > GDB's memory at MYADDR. Returns either 0 for success or an errno value > if any error occurs. > > using errno values limits what we can return here. There's no > errno for , for example. So, it'd be better if > we returned target_xfer_error instead. If we needed to indicate > an errno or a bfd error in addition, new TARGET_XFER_E_ERRNO or > TARGET_XFER_E_BFD values could be added to target_xfer_error > (and the caller would then have to consult errno or bfd_error > in addition then). > OK, it is clear to me. I'd like to write this down in section "Internals" in http://sourceware.org/gdb/wiki/ProjectIdeas , let me know what do you think. Use target_xfer_error instead of errno. Some xfer_memory functions (such as target_read_memory and deprecated_xfer_memory) are using errno to indicate any error occurs. This limites what we can return here, because we can't return some GDB-specific errors, such as . If we need to indicate an errno, bfd error for example, a new TARGET_XFER_E_BFD can be added to target_xfer_error. See http://sourceware.org/ml/gdb-patches/2013-08/msg00589.html for more info. >> > >>> >>+/* Report a target xfer memory error by throwing a suitable >>> >>+ exception. */ >>> >>+ >>> >>+static void >>> >>+target_xfer_memory_error (enum target_xfer_error err, CORE_ADDR memaddr) >>> >>+{ >>> >>+ switch (err) >>> >>+ { >>> >>+ case TARGET_XFER_E_IO: >>> >>+ /* Actually, address between memaddr and memaddr + len was out of >>> >>+ bounds. */ >> > >> >This line of comment doesn't make much sense in the context of this >> >function. > I think it makes some sense if you consider the context that the caller > always has a length handy. But yeah. This is a preexisting issue > though (see memory_error, this new function can be looked at as > a refactor). Maybe what we should do is actually pass in the > length, and show the range to the user instead of just the first > address. Sometimes that info is useful, as it may not be the first > address in the requested range that actually is inaccessible. > Yeah, printing the range is useful some times. -- Yao (齐尧)