This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] windows-nat.c: Handle ERROR_PARTIAL_COPY in windows_xfer_memory function
- From: Pedro Alves <palves at redhat dot com>
- To: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 02 Sep 2013 14:19:15 +0100
- Subject: Re: [RFA] windows-nat.c: Handle ERROR_PARTIAL_COPY in windows_xfer_memory function
- Authentication-results: sourceware.org; auth=none
- References: <5223bb46 dot c6c0420a dot 5a41 dot 008dSMTPIN_ADDED_BROKEN at mx dot google dot com> <52248978 dot 90500 at redhat dot com> <000301cea7dd$17bc4af0$4734e0d0$ at muller@ics-cnrs.unistra.fr>
On 09/02/2013 02:05 PM, Pierre Muller wrote:
>>> This is not compatible with returning information that only part of the
>>> request length
>>> was read/written.
>>
>> Well, we could just change that interface to make it possible...
>>
>> The thing I don't like with doing this only on the native
>> side, is that we're trying to get to a point where we
>> can share the target backends between GDB and gdbserver:
>
> Well, when you look at the code inside child_xfer_memory,
> you can notice that the return value of ReadProcessMemory or
> WriteProcessMemory
> is discarded, which means that it does behave more or less like the
> new windows-nat.c code (at least in case of ERROR_PARTIAL_COPY)
> for other errors, it might also return garbage...
> anyhow, the calling code compares the returned value to the requested length
> (LEN value)
That's brittle...
> so that the risk of generating a successful read_memory despite a failure
> of ReadProcessMemory function is small... (the uninitialized variable done
> would need to return the value LEN..)
> It could of course still happen theoretically...
This is really no argument for not fixing gdbserver... In fact,
it's an argument _for_ fixing it.
--
Pedro Alves