This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] PR gdb/15871: Unavailable entry value is not shown correctly
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: palves at redhat dot com
- Cc: yao at codesourcery dot com, tromey at redhat dot com, gdb-patches at sourceware dot org
- Date: Wed, 21 Aug 2013 17:43:36 +0200 (CEST)
- Subject: Re: [PATCH] PR gdb/15871: Unavailable entry value is not shown correctly
- References: <1376379586-24150-1-git-send-email-yao at codesourcery dot com> <1376379586-24150-3-git-send-email-yao at codesourcery dot com> <87siy4gsn4 dot fsf at fleche dot redhat dot com> <521458A8 dot 7060304 at codesourcery dot com> <5214D03C dot 9040703 at redhat dot com> <201308211447 dot r7LEld3t025510 at glazunov dot sibelius dot xs4all dot nl> <5214DD85 dot 5060605 at redhat dot com>
> Date: Wed, 21 Aug 2013 16:32:21 +0100
> From: Pedro Alves <palves@redhat.com>
>
> On 08/21/2013 03:47 PM, Mark Kettenis wrote:
> >> Date: Wed, 21 Aug 2013 15:35:40 +0100
> >> From: Pedro Alves <palves@redhat.com>
> >>
> >> 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=<error reading variable: Cannot access memory at address 0x8049788>
> >>> 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.
>
> I think that's really a matter of taste. But maybe my taste is
> broken... It's quite common to return "-errno" as error indication.
> The Linux kernel uses that convention for example.
Yeah. I was tempted to add that you've been exposed to too much Linux
kernel programming ;).
Anyway, I'd argue it's more than a matter of taste. Even in the
little bit of code you used the enum values both with and without a
minus sign. That's confusing. Thanks for fixing this. Diff looks
reasonable to me.