This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] guile/: Add enum casts
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: gdb-patches at sourceware dot org, Doug Evans <xdje42 at gmail dot com>
- Date: Wed, 28 Oct 2015 19:36:12 +0000
- Subject: Re: [PATCH] guile/: Add enum casts
- Authentication-results: sourceware.org; auth=none
- References: <1446058487-22472-1-git-send-email-palves at redhat dot com> <CAFXXi0mtDwZBXNF1LCe61yEgsU=AcaYz-kQSWiFe6ONpxne2=Q at mail dot gmail dot com>
On 10/28/2015 07:29 PM, Simon Marchi wrote:
> The status comes from gdbscm_disasm_read_memory returning TARGET_XFER_E_IO:
>
> return status != NULL ? TARGET_XFER_E_IO : 0;
>
> Does it make sense that this function returns TARGET_XFER_E_IO, and
> not just -1 (or any other non-zero value) on error? It's an
> all-or-nothing memory read function, unlike those of the xfer_partial
> interface.
>
> I would have done a change similar to what you have done in
> target_read_memory&co: make gdbscm_disasm_read_memory return -1 on
> error, and change
> memory_error (status, memaddr);
> to
> memory_error (TARGET_XFER_E_IO, memaddr);
>
> Would it make sense?
I had the same thoughts when I did the target_read_memory&co patch,
and went through all the memory_error callers. In the end I left
it be because of the IWBN comment:
/* TODO: IWBN to distinguish problems reading target memory versus problems
with the port (e.g., EOF).
We return TARGET_XFER_E_IO here as that's what memory_error looks for. */
return status != NULL ? TARGET_XFER_E_IO : 0;
Either way is fine with me. Doug, what would you prefer?
Cast?
Hardcode TARGET_XFER_E_IO in the memory_error call?
Other?
Thanks,
Pedro Alves