From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6G9aE30cdGKSgQQAWB0awg (envelope-from ) for ; Thu, 05 May 2022 14:50:37 -0400 Received: by simark.ca (Postfix, from userid 112) id 430C41E058; Thu, 5 May 2022 14:50:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 94E591E00D for ; Thu, 5 May 2022 14:50:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 369D53858036 for ; Thu, 5 May 2022 18:50:36 +0000 (GMT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id 6651C3857353 for ; Thu, 5 May 2022 18:50:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6651C3857353 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f52.google.com with SMTP id w4so7225304wrg.12 for ; Thu, 05 May 2022 11:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=CObGPCjVWUGhlwh3IDS3gS/p20pgRUlQGziwKBvExLI=; b=yc+K3Yiru4sPMmfdyBCPdcbQ6aDCWqXT67XtGYBrEiBATQQZGo3AQ9zalkUyv30NQN 2kl4Eo5neQJCWkt2aenuI4g8J1D0HA1Rj6Cu2+LHNJYj1zqVUAKSYlF7pyGvQITr/ALG ShQo0ichqLIgALleKahYOptk8NcozVDwZVm2wstRpSmzcCTrIwcc798/xX54PKfMlB1j Kh8zAOmCmF2BOGnqsSuT9aHBxETMnm60oiab7s4UolNVnzzS43FXgmFnBPvl+r6+0SqL OZTTXSykIj36/ZT6rooDM2lV2PnQokZzPLyHOyU0EbjT/Z/kAroDCz/WEGvM5YAfCmyI GLAQ== X-Gm-Message-State: AOAM5339rj+Z+HOYiUAHV36tecRRhvX2EQcYS0STTVovZ8hLOfjSXjoD UjH/DoL9D9M9sZWiovp3q9xa8uj9+tU= X-Google-Smtp-Source: ABdhPJwuQazcNWdfa51w7OBuZv7qyiFFlH7TKZ9MPsVuqTvEuCrHd7iR1tkfBxAA/BIj0qvVOQXOJw== X-Received: by 2002:a05:6000:136b:b0:20a:c416:e914 with SMTP id q11-20020a056000136b00b0020ac416e914mr22143515wrz.167.1651776623392; Thu, 05 May 2022 11:50:23 -0700 (PDT) Received: from localhost ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id l6-20020a05600c1d0600b003942a244f34sm5603543wms.13.2022.05.05.11.50.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 May 2022 11:50:22 -0700 (PDT) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 0/3] Fix "b func(std::string)", DMGL_VERBOSE, gdb.cp/no-dmgl-verbose.exp Date: Thu, 5 May 2022 19:50:17 +0100 Message-Id: <20220505185020.3648774-1-pedro@palves.net> X-Mailer: git-send-email 2.36.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" This series evolved from the discussion starting at: [PATCH] Fix gdb.cp/no-dmgl-verbose.exp test https://sourceware.org/pipermail/gdb-patches/2022-April/188542.html Turns out gdb.cp/no-dmgl-verbose.exp is right as long as GDB doesn't use DMGL_VERBOSE (which it doesn't today), _and_ on libstdc++, it is build for pre-C++11 ABI. See "GCC5 and the C++11 ABI", at . And "Dual ABI" at . On systems with compilers that default to modern C++11 ABI (practically everywhere these days), gdb.cp/no-dmgl-verbose.exp exposes that "b func(std::string)" doesn't work any more. This series fixes this, ensuring that the scenario works on both pre-C++11, and C++11 ABIs. It does this by switching GDB to use DMGL_VERBOSE, and removing some related code from gdb/cp-support.c. This is done in patch #1. Patch #2 is preparatory work for patch #3. Patch #3 is about making it so that "b f(std::string)" also works if the current language is C. I noticed that it doesn't work, because the testcase debugs a .o file, and in such case, GDB doesn't figure out that the program's language is C++, and so it assumes the language is C. Without doing "set language c++", "b f(std::string)" would still fail. But I think that should have not been necessary, I think GDB should have been able to set the breakpoint even with "set language c". Tested on x86_64 GNU/Linux with no regressions. Pedro Alves (3): Fix "b f(std::string)", always use DMGL_VERBOSE Always pass an explicit language down to c_type_print Fix "b f(std::string)" when current language is C gdb/ada-typeprint.c | 2 +- gdb/c-exp.y | 1 + gdb/c-lang.c | 8 +- gdb/c-lang.h | 17 +-- gdb/c-typeprint.c | 25 +--- gdb/cp-name-parser.y | 5 +- gdb/cp-support.c | 54 ++++++--- gdb/cp-support.h | 12 ++ gdb/d-lang.c | 2 +- gdb/gnu-v3-abi.c | 3 +- gdb/go-typeprint.c | 2 +- gdb/objc-lang.c | 2 +- gdb/opencl-lang.c | 2 +- gdb/rust-lang.c | 5 +- ...-dmgl-verbose.cc => break-f-std-string.cc} | 0 gdb/testsuite/gdb.cp/break-f-std-string.exp | 112 ++++++++++++++++++ gdb/testsuite/gdb.cp/no-dmgl-verbose.exp | 35 ------ 17 files changed, 192 insertions(+), 95 deletions(-) rename gdb/testsuite/gdb.cp/{no-dmgl-verbose.cc => break-f-std-string.cc} (100%) create mode 100644 gdb/testsuite/gdb.cp/break-f-std-string.exp delete mode 100644 gdb/testsuite/gdb.cp/no-dmgl-verbose.exp base-commit: 8e1ada9e0bd4f57597b835b2d09b100d24c604d8 -- 2.36.0