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

[Tom de Vries <tdevries@suse.de>]

On 12/16/25 5:53 PM, Simon Marchi wrote:
> 
> 
> 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.
> 

Well, runtime relocations can make data valid that was invalid before.

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

Ack, I'll push this, thanks.

- Tom