Re: [Windows]Fix a bug which cause GDB.exe assert when try to run the inferior

[Yao Qi <yao@codesourcery.com>]

On 02/21/2014 03:37 PM, Eli Zaretskii wrote:
>> Date: Fri, 21 Feb 2014 15:03:31 +0800
>> From: Yao Qi <yao@codesourcery.com>
>> CC: <gdb-patches@sourceware.org>
>>
>> 2014-02-21  Yuanhui Zhang  <asmwarrior@gmail.com>
>>
>> 	* windows-nat.c (windows_xfer_shared_libraries): Return
>> 	TARGET_XFER_EOF if LEN is zero.
> 
> Indeed.  May I also suggest to point to the details of the underlying
> problem, or include its summary, in the ChangeLog entry?
> 

I prefer to put the details of the underlying problem in commit log,
but I am fine to include its summary in the ChangeLog entry.

How about this?

In commit log:

A GDB internal error is found on native mingw32 target.

(gdb) run
../../binutils-gdb/gdb/target.c:1483: internal-error:
target_xfer_partial: Assertion `*xfered_len > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

This error was introduced by the following snippet in commit
9b409511d07fe375284701af34909fb539029caf

> @@ -2536,27 +2538,30 @@ windows_xfer_shared_libraries (struct target_ops *ops,
>      }
>  
>    obstack_free (&obstack, NULL);
> -  return len;
> +  *xfered_len = (ULONGEST) len;
> +  return TARGET_XFER_OK;
>  }

In the original code, len is returned, which could be 0, but after that
commit, only TARGET_XFER_OK is returned, which is wrong.  If len is 0,
TARGET_XFER_EOF should be returned.  (it is 0 in enum
target_xfer_status declaration).

gdb:

2014-02-21  Yuanhui Zhang  <asmwarrior@gmail.com>

	* windows-nat.c (windows_xfer_shared_libraries): Return
	TARGET_XFER_EOF if LEN is zero to fix an assert failure when
	requested object is TARGET_OBJECT_LIBRARIES.

-- 
Yao (齐尧)