From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GKBOJjT8Q2Ph/wgAWB0awg (envelope-from ) for ; Mon, 10 Oct 2022 07:04:20 -0400 Received: by simark.ca (Postfix, from userid 112) id 99C891E112; Mon, 10 Oct 2022 07:04:20 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=BGcspNXg; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 43F681E0D5 for ; Mon, 10 Oct 2022 07:04:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5C8FA3857B85 for ; Mon, 10 Oct 2022 11:04:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C8FA3857B85 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1665399859; bh=VzW2hHVJFk4Z3Qi0ulaUXpY2gnxvnI2aSx/FKFML4vM=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=BGcspNXgfXRXqgIO1l88E6Gw4edDWZ5E74t7C86YD5uup9YyzrbX+a5Awx4vSUhCa Ts9I+1Givjo9TQI/TiIdMEMSIvyqyS5wp9NI1MIMxYpztwIYFSI1L18I0XNLOurDTG Og+uvE5dPjJ0KNkf/Ai8Pe+C5W4FawODgdTzoebs= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4C44D3858D37 for ; Mon, 10 Oct 2022 11:03:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C44D3858D37 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-488-l1vaqsqTOZqoDj4x6ozGNw-1; Mon, 10 Oct 2022 07:03:17 -0400 X-MC-Unique: l1vaqsqTOZqoDj4x6ozGNw-1 Received: by mail-wr1-f69.google.com with SMTP id s5-20020adf9785000000b0022e1af0e7e8so2636426wrb.11 for ; Mon, 10 Oct 2022 04:03:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VzW2hHVJFk4Z3Qi0ulaUXpY2gnxvnI2aSx/FKFML4vM=; b=dQA0BdoJCazT2s1CEGE1MVr18a4mV8lDGc+DWIIkTuU3/ZTR76pVBU6TAFdgqH2KV3 09eTRIMXtF6YU1dKz1gLrAHIbWVtilmtcB29otiCDNgGvePWZOeK33ZFr5EiZIKQ9cwH CEe1I0iK/vXy0MFu0aXLRBWbCWs3RNRcWvilSZMJ4z0KyohZFQyRaRq3GCew0Vr+A57s v3PKTmiAM5v46r6BAaHWTxRkp4eH5EMxehO4gXV5ZpW/d58H+EJ/ma/dyOEsp02DjAvx 3oNFblVbXmtuBrGriSIku4IBwIhrxe/rwu/3qe7jIlK9DuAbnHh1Yo6lblw+racvHP6V m8pQ== X-Gm-Message-State: ACrzQf2BokdZWkW1rBx/KA7PE8FOR6qR+Cck1nkRFJc1IZteqAkl1rHv aPCQAwd/912T4/BeL5waHojg26EdAVVLREtJAwcOzqI7S7HQAUA/gb/hz5u4HJmrpfmF8clasum c/G0DzMMBN5PevQMpSg74cA== X-Received: by 2002:adf:fcc6:0:b0:22e:3ab7:e170 with SMTP id f6-20020adffcc6000000b0022e3ab7e170mr10729406wrs.263.1665399796697; Mon, 10 Oct 2022 04:03:16 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6B30WognK3H/tpF++2SbTKdt+4BjQ7yNldIKmendQAodca5AndXsBtU1tvWmNTMnKOTDH59g== X-Received: by 2002:adf:fcc6:0:b0:22e:3ab7:e170 with SMTP id f6-20020adffcc6000000b0022e3ab7e170mr10729388wrs.263.1665399796346; Mon, 10 Oct 2022 04:03:16 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id w8-20020adfee48000000b002205a5de337sm8566524wro.102.2022.10.10.04.03.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Oct 2022 04:03:15 -0700 (PDT) To: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] gdb: improve disassembler styling when Pygments raises an exception In-Reply-To: <15cf0c9f-81ae-9bc8-79ba-e5b4eb1f0412@simark.ca> References: <15cf0c9f-81ae-9bc8-79ba-e5b4eb1f0412@simark.ca> Date: Mon, 10 Oct 2022 12:03:15 +0100 Message-ID: <87r0zgdjpo.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Simon Marchi writes: >> +# Check that, if the user is using Python Pygments for disassembler >> +# styling, then the styling correctly switches off when an error is >> +# detected in the Python code. >> +proc test_disassembler_error_handling { } { >> + >> + # This test requires the Python Pygments module to be installed >> + # and used by GDB. >> + if { !$::python_disassembly_styling } { >> + return >> + } >> + >> + save_vars { env(TERM) } { >> + # We need an ANSI-capable terminal to get the output. >> + setenv TERM ansi >> + >> + # Restart GDB with the correct TERM variable setting, this >> + # means that GDB will enable styling. >> + clean_restart_and_disable "restart 4" $::binfile >> + >> + # Disable use of libopcodes for styling. As this function is >> + # only called when Python Pygments module is available, we >> + # should now be using that module to style the disassembler >> + # output. >> + gdb_test_no_output "maint set libopcodes-styling enabled off" >> + >> + # Disassemble a single instruction and ensure that the output >> + # has styling markers in it. >> + set insn_before [get_single_disassembled_insn] >> + gdb_assert { [regexp "\033" $insn_before] } \ >> + "have style markers when Pygments is working fine" >> + >> + # Now replace the standard function that colorizes the >> + # disassembler output, with a new function that always returns >> + # None, this should cause GDB to stop using the Pygments >> + # module for disassembler styling. >> + gdb_py_test_silent_cmd \ >> + [multi_line_input \ >> + "python" \ >> + "def replacement_colorize_disasm(content,gdbarch):" \ >> + " return None" \ >> + "gdb.styling.colorize_disasm = replacement_colorize_disasm" \ >> + "\004"] \ > > Any reason you are using \004 here, instead of end? I don't quite > understand why, but it seems to cause some random failures. Running the > test under `taskset -c 2` makes it fail most of the time. Running it > with check-read1 makes it fail consistently: > > FAIL: gdb.base/style.exp: capture_command_output for x/1i *main > > When changing \004 for end, it passes. I don't have an explanation why > though. Turns out the explanation is really simple once you know what it is :) gdb_py_test_silent_cmd forwards to gdb_test_multiple. The command I was sending above, once multi_line_input has done its thing is like this: python\ndef ...\n return None\ngdb.styling....\n\004 This gets sent to gdb_test_multiple, which then sends the command to GDB, along with a trailing newline - the newline which it thinks will cause the command to dispatch to GDB. So our command ends like this: ....\n\004\n Of course, a \004 doesn't need a trailing newline, it is handled immediately, so that final '\n' is not part of the multi-line python block. And so, after \004 has cause the Python block to finish, and the contents to be processed by the Python interpreter, we still have an unspent newline character in the input stream, this causes GDB to print a second prompt, the gdb.log contains: (gdb) PASS: gdb.base/style.exp: have style markers when Pygments is working fine python >def replacement_colorize_disasm(content,gdbarch): > return None >gdb.styling.colorize_disasm = replacement_colorize_disasm >quit (gdb) PASS: gdb.base/style.exp: setup replacement colorize_disasm function (gdb) FAIL: gdb.base/style.exp: capture_command_output for x/1i *main And so, we have a race with DejaGnu. If the two prompts appear slowly enough, then DejaGnu will match the first one with the end of the 'setup replacement colorize_disasm function', and the second prompt will be used to prematurely match with the end of the 'capture_command_output for x/1i *main' test. If the two prompts appear quickly then both prompts will be matched as part of the 'setup replacement colorize_disasm function' test. The patch I already pushed will resolve this issue completely. Thanks for finding this bug. Andrew