From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VegiGqWOQWnpBgQAWB0awg (envelope-from ) for ; Tue, 16 Dec 2025 11:53:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1765904037; bh=4yjzk2OtcPaCmxf20ypzCYBQoQFFmXfXpKwmMQV+n5s=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=iAvmkUxeH6QNac4Cw0igTzQt2Uqqzgk1gkZJzhwidnmWUhp0ckkCEs6Jzm5Ejk0Fl LSz+nP9gwUdK/Ejz+FLAj+wJpKdZ9paQiYBTkxfdLkmvzvXqaOoeWCiwi4ObVgKU2V 00f9qnq1Xibg8mDFy9A846vbWoRSUGBGCoKDyeow= Received: by simark.ca (Postfix, from userid 112) id 588981E048; Tue, 16 Dec 2025 11:53:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=e3RdZ26C; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BB4FF1E048 for ; Tue, 16 Dec 2025 11:53:56 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 3B2114BA2E2A for ; Tue, 16 Dec 2025 16:53:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B2114BA2E2A Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=e3RdZ26C Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BE4764BA2E1E for ; Tue, 16 Dec 2025 16:53:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BE4764BA2E1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BE4764BA2E1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765904010; cv=none; b=OilBvL90GY18fwiIFHpbxazBQIiNBvG2M6vMnV/dk2iLnzcfx7tvjt47P3TndIlrXmv5pqXLmnJJKG0k4IeeN+LL4dH5YKJ1WP6ZzfExa8LM95wURRFIQkzBHhCxcU1oYROhWsUibou6zxl0JwFNjxfiHRgFpdgYRI3GDD3EDC4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765904010; c=relaxed/simple; bh=4yjzk2OtcPaCmxf20ypzCYBQoQFFmXfXpKwmMQV+n5s=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=nBxXoMN2voFllJ3wT0eVkQuhE16tgdbYPaptqlXCRmmEUp5iDu6AbQd0zDK+Chwg2HTGL9GbtTcTScbyN/r7wzGKeQT6QDpnPC51jdSTMmsaKEHSY1gFVC6E06XDkDxImf2OmAjcTOTKEaM9pM02iP7dMbYHbBZ2681iuurMccU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE4764BA2E1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1765904010; bh=4yjzk2OtcPaCmxf20ypzCYBQoQFFmXfXpKwmMQV+n5s=; h=Date:Subject:To:References:From:In-Reply-To:From; b=e3RdZ26CmwmLv1tlOdPguOR+zGng8pXuCZENj7AFZMn7EVKSJl/W5/psfpqjgVLmh kaGEs9shD+Xv6T8AH72PG5X+vH5L1srripDiR8W03VEH6Ako+iKQFKa9XJmRSIht6w dag+fiCRXU/AzkcajltCuB1HQWVP/tuFmO7+Gbfg= Received: by simark.ca (Postfix) id 511261E048; Tue, 16 Dec 2025 11:53:30 -0500 (EST) Message-ID: <07d87f19-4e01-43b0-b9d8-cc99bd31fb47@simark.ca> Date: Tue, 16 Dec 2025 11:53:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE To: Tom de Vries , gdb-patches@sourceware.org References: <20251216134240.3843501-1-tdevries@suse.de> <366d1b78-aa6c-4279-bf88-931b6ee687dc@suse.de> Content-Language: en-US From: Simon Marchi In-Reply-To: <366d1b78-aa6c-4279-bf88-931b6ee687dc@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 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 On 2025-12-16 11:12, Tom de Vries wrote: > On 12/16/25 4:50 PM, Simon Marchi wrote: >> >> >> On 2025-12-16 08:42, Tom de Vries wrote: >>> On x86_64-linux, if I run test-case gdb.cp/typeid.exp with target boards: >>> - unix/-m64 >>> - unix/-m32 >>> - unix/-fPIE/-pie/-m64 >>> - unix/-fPIE/-pie/-m32 >>> for only target board unix/-fPIE/-pie/-m32 I get: >>> ... >>> (gdb) print &typeid(i)^M >>> could not find typeinfo symbol for 'int'^M >>> (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) >>> print &typeid(i) == &typeid(typeof(i))^M >>> could not find typeinfo symbol for 'int'^M >>> (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) == &typeid(typeof(i)) >>> print &typeid(cp)^M >>> could not find typeinfo symbol for 'char*'^M >>> (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) >>> print &typeid(cp) == &typeid(typeof(cp))^M >>> could not find typeinfo symbol for 'char*'^M >>> (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) == &typeid(typeof(cp)) >>> print &typeid(ccp)^M >>> could not find typeinfo symbol for 'char const*'^M >>> (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) >>> print &typeid(ccp) == &typeid(typeof(ccp))^M >>> could not find typeinfo symbol for 'char const*'^M >>> (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) == &typeid(typeof(ccp)) >>> ... >>> >>> This is yet another configuration for which these tests don't work. >>> >>> We're already allowing this for clang and istarget "powerpc*-*-*". >>> >>> I don't think there is value in trying to detect yet another configuration. >>> >>> Instead, just allow it in general. >> > > Hi Simon, > > thanks for the review. > >> I don't know the history of this test. Why is the type info for these base >> types missing before running? Is it a compiler bug or feature? >> > > I don't think it's either, AFAIU it's an implementation detail. I suspect in this case it's related to relocations. > > But in general, there's nothing that mandates that type info needs to be available before starting an executable, so it's just a YMMV situation. I don't really understand how that works. In my understanding, either there is an entry in the DWARF for the type info, or there isn't. I don't understand how it can appear once the inferior is started. >>> diff --git a/gdb/testsuite/gdb.cp/typeid.exp b/gdb/testsuite/gdb.cp/typeid.exp >>> index e12b032f32b..58f0a928a63 100644 >>> --- a/gdb/testsuite/gdb.cp/typeid.exp >>> +++ b/gdb/testsuite/gdb.cp/typeid.exp >>> @@ -27,29 +27,35 @@ proc do_typeid_tests {started} { >>> # We might see the standard type or gdb's internal type. >>> set type_re "(std::type_info|gdb_gnu_v3_type_info)" >>> - set var {ca b} >>> - set have_base_types 1 >>> - if {!$started} { >>> - if {[test_compiler_info clang-*-* c++]} { >>> - # Note that we test pointer equality rather than object >>> - # Clang doesn't place type information for the base types in >>> - # the executable, and relies on this being linked in from the >>> - # standard library. As a result, type information for these >>> - # variables is only available once the inferior is started. >>> - set have_base_types 0 >>> - } elseif {[istarget "powerpc*-*-*"]} { >>> - # On PowerPC, RTTI typeinfo for base types (i, cp, ccp) may not be >>> - # emitted until the inferior is started. >>> - set have_base_types 0 >>> - } >>> - } >>> - if { $have_base_types } { >>> - lappend var i cp ccp >>> - } >>> + # The typeinfo for some of these variables may or may not be present >>> + # before the inferior has started. Mark these by listing them in >>> + # maybe_missing_var. >>> + set maybe_missing_var {i cp ccp} >>> + set var [concat {ca b} $maybe_missing_var] >>> foreach simple_var $var { >>> - gdb_test "print &typeid($simple_var)" \ >>> - " = \\($type_re \\*\\) $hex.*" >>> + set maybe_missing \ >>> + [expr {[lsearch -exact $maybe_missing_var $simple_var] != -1}] >> >> From the comment, it sounds like the type info for these should be >> available once the inferior is started. So, should maybe_missing stay >> false if $started is true? >> > > Yes, thanks for catching that. > >>> + >>> + set missing 0 >>> + set re [subst_vars { = \($type_re \*\) $hex.*}] >>> + gdb_test_multiple "print &typeid($simple_var)" "" { >>> + -re -wrap $re { >>> + pass $gdb_test_name >>> + } >>> + -re -wrap "could not find typeinfo symbol for '.*'" { >>> + if { $maybe_missing } { >>> + unsupported $gdb_test_name >> >> unsupported or xfail? > > Unsupported. It's not an xfail because the environment is doing nothing wrong. Ok. Approved-By: Simon Marchi Simon