Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
Date: Tue, 16 Dec 2025 17:12:59 +0100	[thread overview]
Message-ID: <366d1b78-aa6c-4279-bf88-931b6ee687dc@suse.de> (raw)
In-Reply-To: <d6d2a982-1686-4798-b8bf-aa2dc12a9f73@simark.ca>

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.

>> 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.

Thanks,
- Tom

  reply	other threads:[~2025-12-16 16:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16 13:42 Tom de Vries
2025-12-16 15:50 ` Simon Marchi
2025-12-16 16:12   ` Tom de Vries [this message]
2025-12-16 16:53     ` Simon Marchi
2025-12-16 17:02       ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=366d1b78-aa6c-4279-bf88-931b6ee687dc@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox