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