From: Yao Qi <yao@codesourcery.com>
To: <asmwarrior@gmail.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [Windows]Fix a bug which cause GDB.exe assert when try to run the inferior
Date: Mon, 24 Feb 2014 06:47:00 -0000 [thread overview]
Message-ID: <530AEA6C.8050002@codesourcery.com> (raw)
In-Reply-To: <530706DD.8060605@codesourcery.com>
On 02/21/2014 03:57 PM, Yao Qi wrote:
> 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.
>
Please update your patch to replace "len ?" with "len != 0 ?" and commit
log we discussed here. You can push it in.
Let me know if you don't have a commit access or have trouble on
committing, I can commit this patch for you.
--
Yao (é½å°§)
next prev parent reply other threads:[~2014-02-24 6:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-20 14:35 asmwarrior
2014-02-21 1:22 ` Yao Qi
2014-02-21 6:12 ` asmwarrior
2014-02-21 7:05 ` Yao Qi
2014-02-21 7:37 ` Eli Zaretskii
2014-02-21 7:59 ` Yao Qi
2014-02-21 8:07 ` Eli Zaretskii
2014-02-24 6:47 ` Yao Qi [this message]
2014-02-24 7:10 ` asmwarrior
2014-02-24 7:50 ` Yao Qi
2014-02-21 10:13 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530AEA6C.8050002@codesourcery.com \
--to=yao@codesourcery.com \
--cc=asmwarrior@gmail.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox