From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id B7F1C3858D37 for ; Tue, 14 Mar 2023 13:05:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B7F1C3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B9CBE1F88C; Tue, 14 Mar 2023 13:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1678799134; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=SQB40gN0VzZ9DOfzibVYLUriu2flpUhifWQyujJAxXY=; b=P2xkbQe01JiBwwQcB+adbAAjhzU6BfUq4p33PstWEznn/en9sZRvD4LP6ISYHzZzrUJHgU k4UxypHBtrOAXacAq0aSiTNdEcOSHE7O5utP8ryYQq4SbP5nCSCh/H876w63I3Ur3S+KdV eS4fK/VZksDNl2yvEbeRJp1bVjL6G+E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1678799134; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=SQB40gN0VzZ9DOfzibVYLUriu2flpUhifWQyujJAxXY=; b=nqLKSkB/+6KLfRMC4xQXf3y/i4A2ZbWPmXHOzPi2+Wkr0wBpmzxEN2Ntt6ET2aqFmGTqRw xJgcRv3STw8bloDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A3D0113A1B; Tue, 14 Mar 2023 13:05:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6nnnJh5xEGQibAAAMHmgww (envelope-from ); Tue, 14 Mar 2023 13:05:34 +0000 From: Tom de Vries To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [RFC 0/3] [gdb/dap] Handle DAP command files Date: Tue, 14 Mar 2023 14:05:32 +0100 Message-Id: <20230314130535.6369-1-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: After reporting a failure in test-case gdb.dap/bt-nodebug.exp, I tried to reproduce the failure in the usual way, using "-q -batch -x gdb.in": ... $ gdb -q -batch -iex "set debug dap-log-file dap.log" -i dap -x gdb.in ... but that didn't work. It seems that the interpreter reading in gdb.in doesn't use DAP despite the "-i dap". I also tried modifying gdb.in to use interpreter-exec dap, but that didn't work for me, maybe it's possible though, I don't know. Then I tried: ... $ gdb -q -iex "set debug dap-log-file dap.log" -i dap < gdb.in ... which sort of works, but didn't reproduce the failure due to not waiting for events, something that is dealt with in the test-case using dap_wait_for_event_and_check. So, I've added processing of an input line "WAIT_FOR_EVENTS: " to fix that problem (patch 3). With editing gdb.in came the need to make it a bit more readable, so I made it possible to start Content-Length at a new line (patch 2). Also I've added a patch to log ignored input, which helps to debug parsing issues (patch 1). Using this patch series, and the following gdb.in, I managed to reproduce the problem: ... Content-Length: 54 WAIT_FOR_EVENTS: 1 {"seq": 1, "type": "request", "command": "initialize"} Content-Length: 163 WAIT_FOR_EVENTS: 0 {"seq": 2, "type": "request", "command": "launch", "arguments": {"program": "bt-nodebug"}} Content-Length: 136 WAIT_FOR_EVENTS: 2 {"seq": 3, "type": "request", "command": "setFunctionBreakpoints", "arguments": {"breakpoints": [{"name": "function_breakpoint_here"}]}} Content-Length: 61 WAIT_FOR_EVENTS: 1 {"seq": 4, "type": "request", "command": "configurationDone"} Content-Length: 84 {"seq": 5, "type": "request", "command": "stackTrace", "arguments": {"threadId": 1}} Content-Length: 54 {"seq": 6, "type": "request", "command": "disconnect"} ... Sofar, this hasn't actually helped me to investigate, when doing: ... $ gdb --args gdb -q -iex "set debug dap-log-file dap.log" -i dap ... followed by: ... (gdb) run < gdb.in ... I end up with: ... (gdb) Undefined command: "Content-Length". Try "help". ... which AFAICT means that the input from gdb.in does end up in the inner gdb, but is not parsed as DAP. Tom de Vries (3): [gdb/dap] Add logging of ignored lines [gdb/dap] Allow Content-Length on separate line [gdb/dap] Allow WAIT_FOR_EVENTS input gdb/python/lib/gdb/dap/io.py | 17 ++++++++++++++--- gdb/python/lib/gdb/dap/server.py | 12 +++++++++++- 2 files changed, 25 insertions(+), 4 deletions(-) base-commit: c8b3d02c49943d1fef2cc060dd7115a5ae5f7afe -- 2.35.3