This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 5 Oct 2017 18:08:08 +0100
- Subject: Re: [PATCH 3/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 840E8C059B77
- References: <20171005165012.0528CD835F0@oc3748833570.ibm.com>
On 10/05/2017 05:50 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
>
>> * target.c (default_thread_architecture): Use the sepecified
>> inferior's architecture, instead of the current inferior's
>> architecture (via target_gdbarch).
>
> This causes a number of ICEs in the test suite for me, at the point when
> default_thread_architecture is called from linux_child_follow_fork here:
>
> if (!gdbarch_software_single_step_p (target_thread_architecture
> (child_lp->ptid)))
>
> Note that at this point there is no inferior for the child, and I think
> there will never be one since the child is to be detached immediately.
>
> Given that this is a fork, I guess a simple fix would be to check
> for the parent's thread architecture here instead.
Indeed, sorry about that. I noticed this too this afternoon,
and wrote a fix just like you suggest and was just waiting for
a test run to complete. Results look good, so I'll push it
in in a bit.
Thanks,
Pedro Alves