* [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
@ 2025-12-16 13:42 Tom de Vries
2025-12-16 15:50 ` Simon Marchi
0 siblings, 1 reply; 5+ messages in thread
From: Tom de Vries @ 2025-12-16 13:42 UTC (permalink / raw)
To: gdb-patches
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.
Tested on x86_64-linux.
---
gdb/testsuite/gdb.cp/typeid.exp | 48 ++++++++++++++++++---------------
1 file changed, 27 insertions(+), 21 deletions(-)
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}]
+
+ 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
+ } else {
+ fail $gdb_test_name
+ }
+ set missing 1
+ }
+ }
+
+ if { $missing } {
+ continue
+ }
# Note that we test pointer equality rather than object
# equality here. That is because std::type_info's operator==
base-commit: 9529188a184f69d804c9c1c974c51d3b3460e676
--
2.51.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
2025-12-16 13:42 [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE Tom de Vries
@ 2025-12-16 15:50 ` Simon Marchi
2025-12-16 16:12 ` Tom de Vries
0 siblings, 1 reply; 5+ messages in thread
From: Simon Marchi @ 2025-12-16 15:50 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
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.
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?
> 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?
> +
> + 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?
Simon
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
2025-12-16 15:50 ` Simon Marchi
@ 2025-12-16 16:12 ` Tom de Vries
2025-12-16 16:53 ` Simon Marchi
0 siblings, 1 reply; 5+ messages in thread
From: Tom de Vries @ 2025-12-16 16:12 UTC (permalink / raw)
To: Simon Marchi, gdb-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
2025-12-16 16:12 ` Tom de Vries
@ 2025-12-16 16:53 ` Simon Marchi
2025-12-16 17:02 ` Tom de Vries
0 siblings, 1 reply; 5+ messages in thread
From: Simon Marchi @ 2025-12-16 16:53 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
2025-12-16 16:53 ` Simon Marchi
@ 2025-12-16 17:02 ` Tom de Vries
0 siblings, 0 replies; 5+ messages in thread
From: Tom de Vries @ 2025-12-16 17:02 UTC (permalink / raw)
To: Simon Marchi, gdb-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-16 17:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-16 13:42 [PATCH] [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE Tom de Vries
2025-12-16 15:50 ` Simon Marchi
2025-12-16 16:12 ` Tom de Vries
2025-12-16 16:53 ` Simon Marchi
2025-12-16 17:02 ` Tom de Vries
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox