From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22891 invoked by alias); 21 Aug 2013 14:47:50 -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 22857 invoked by uid 89); 21 Aug 2013 14:47:50 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 21 Aug 2013 14:47:49 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id r7LElewG032083; Wed, 21 Aug 2013 16:47:40 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id r7LEld3t025510; Wed, 21 Aug 2013 16:47:39 +0200 (CEST) Date: Wed, 21 Aug 2013 14:47:00 -0000 Message-Id: <201308211447.r7LEld3t025510@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: palves@redhat.com CC: yao@codesourcery.com, tromey@redhat.com, gdb-patches@sourceware.org In-reply-to: <5214D03C.9040703@redhat.com> (message from Pedro Alves on Wed, 21 Aug 2013 15:35:40 +0100) Subject: 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> X-SW-Source: 2013-08/txt/msg00581.txt.bz2 > Date: Wed, 21 Aug 2013 15:35:40 +0100 > From: Pedro Alves > > On 08/13/2013 08:39 AM, Yao Qi wrote: > > However, when I run this test, I find j@entry is something like, > > j@entry= > > instead of unavailable. > > > > I don't emit a fail for it because I am not very sure it is expected > > to be "unavailable". I am fine to kfail it. > > > > I looked into a little, and looks reading entry value doesn't use > > value availability-aware API. It is not an easy fix to me. > > I looked into this. Here's a patch. Let me know what you think. I think you should simply define the return codes as negative numbers.