Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE

[Simon Marchi <simark@simark.ca>]

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.marchi@efficios.com>

Simon