From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21448 invoked by alias); 11 May 2018 16:46:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21393 invoked by uid 89); 11 May 2018 16:46:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=proposing, ideally, processes X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 May 2018 16:46:01 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 154A0406F124; Fri, 11 May 2018 16:46:00 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F83A2026DEF; Fri, 11 May 2018 16:45:59 +0000 (UTC) Subject: Re: [RFC] (windows) GDB/MI crash when using "-list-thread-groups --available" To: Simon Marchi , Joel Brobecker References: <1525978704-70543-1-git-send-email-brobecker@adacore.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 11 May 2018 17:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-05/txt/msg00305.txt.bz2 On 05/10/2018 10:02 PM, Simon Marchi wrote: > > So when an inferior is started, "-list-thread-groups --available" works correctly on Windows?  What is the target beneath then, which provides the list of available processes on Windows? After the inferior is started, the Windows target is pushed in the target stack, so there will be a target beneath, either the exec target, or the dummy target directly. Either of those returns TARGET_XFER_E_IO for this target object. The issue here is that before the inferior is started, the Windows target is not pushed on the target stack. See target_get_osdata. > which provides the list of available processes on Windows? I don't think the feature works at all on Windows. It's probably returning an empty list of processes. > > Looking at how it works on Linux, it's the process stratum, inf_ptrace_target, that answers this request.  On Windows, shouldn't windows_nat_target answer this request?  After all, it's the responsibility of windows_nat_target to communicate with the Windows OS to debug processes natively on it. Yeah, it's just that the Windows port doesn't really implement the feature at all, AFAICT. Ideally it'd be implemented. Otherwise, I guess handling the case of not having a target beneath here is reasonable. > >> Also, The testcase I am proposing fails on the -list-thread-groups test >> when run on GNU/Linux because, on that platform, the command returns >> more output than the expect buffer can handle, resulting in an UNRESOLVED >> status. How does one usually handle this? The only why I can think of >> is a loop of gdb_test_multiple... Other ideas? > > What's the difference between the new test case and gdb.mi/list-thread-groups-available.exp?  In that one too, -list-thread-groups --available is executed with no inferior started.  It also uses mi_gdb_test though, so it probably hits the same limitation. I've actually saw that testcase fail before because of this issue. :-) I probably saw it when I was running many test jobs in parallel (thus many processes) or something like that. > > As a quick and dirty hack, is it possible to just increase temporarily the size of the buffer to something that will surely be large enough?  Otherwise, using gdb_test_multiple or maybe gdb_expect to consume the output little by little sounds good. Yeah, the best way to address this is to consume output in chunks, with exp_continue. That fixes it for good. See for example: commit 11859c310cd6b6fd892337a5ee1d36921e6d08d8 Author: Andrew Burgess AuthorDate: Mon Apr 9 00:18:34 2018 +0100 gdb/testsuite: Handle targets with lots of registers I'd prefer that over increasing buffer sizes. Thanks, Pedro Alves