public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Nils-Christian Kempke <nckempke@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers Date: Tue, 31 May 2022 14:46:24 +0000 (GMT) [thread overview] Message-ID: <20220531144624.60614395A027@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0df017fbca3070682ffa62a3b302a30e028adfb6 commit 0df017fbca3070682ffa62a3b302a30e028adfb6 Author: Nils-Christian Kempke <nils-christian.kempke@intel.com> Date: Tue May 31 16:43:45 2022 +0200 gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers When value-printing a pointer within GDB by default GDB will look for defined symbols residing at the address of the pointer. For the given test the Intel/LLVM compiler stacks both display a symbol associated with a printed pointer while the gnu stack does not. This leads to failures in the test when running the test with CC_FOR_TARGET='clang' CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'" (gdb) b 37 (gdb) r (gdb) f 6 (gdb) info args a = 1 b = 2 c = 3 d = 4 + 5i f = 0x419ed0 "abcdef" g = 0x4041a0 <.BSS4> or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'" (gdb) b 37 (gdb) r (gdb) f 6 (gdb) info args a = 1 b = 2 c = 3 d = 4 + 5i f = 0x52eee0 "abcdef" g = 0x4ca210 <mixed_func_1a_$OBJ> For the compiled binary the Intel/LLVM compilers both decide to move the local variable g into the .bss section of their executable. The gnu stack will keep the variable locally on the stack and not define a symbol for it. Since the behavior for Intel/LLVM is actually expected I adapted the testcase at this point to be a bit more allowing for other outputs. I added the optional "<SYMBOLNAME>" to the regex testing for g. The given changes reduce the test fails for Intel/LLVM stack by 4 each. Diff: --- gdb/testsuite/gdb.fortran/mixed-lang-stack.exp | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp index eace4d439bd..5bed3be8697 100644 --- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp +++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp @@ -129,22 +129,29 @@ proc run_tests { lang } { set f_pattern "$hex \"abcdef\"" } + # When value-printing pointers in GDB, GDB will try and look for any + # associated symbol and print it after the pointer as "<SYMBOL>". For + # this test Intel and LLVM compilers move g to the .bss section, thus + # creating a symbol, while the GNU compiler stack keeps g purely on the + # stack. + set g_pattern "$hex\( <\[^\r\n\]+>\)?" + set args_pattern [multi_line \ "a = 1" \ "b = 2" \ "c = 3" \ "d = ${d_pattern}" \ "f = ${f_pattern}" \ - "g = $hex" ] + "g = ${g_pattern}" ] gdb_test "info args" $args_pattern \ "info args in frame #6" if { $lang == "fortran" } { - set g_pattern " = \\( a = 1\\.5, b = 2\\.5 \\)" + set g_val_pattern " = \\( a = 1\\.5, b = 2\\.5 \\)" } else { - set g_pattern " = \\{a = 1\\.5, b = 2\\.5\\}" + set g_val_pattern " = \\{a = 1\\.5, b = 2\\.5\\}" } - gdb_test "print *g" "${g_pattern}" \ + gdb_test "print *g" "${g_val_pattern}" \ "print object pointed to by g" gdb_test "up" "#7\\s+$hex in mixed_func_1b .*" \ @@ -155,11 +162,11 @@ proc run_tests { lang } { if { $lang == "c" || $lang == "c++" } { set d_pattern "4 \\+ 5i" set e_pattern "\"abcdef\"" - set g_pattern "\{a = 1.5, b = 2.5\}" + set g_val_pattern "\{a = 1.5, b = 2.5\}" } else { set d_pattern "\\(4,5\\)" set e_pattern "'abcdef'" - set g_pattern "\\( a = 1.5, b = 2.5 \\)" + set g_val_pattern "\\( a = 1.5, b = 2.5 \\)" } set args_pattern [multi_line \ @@ -168,7 +175,7 @@ proc run_tests { lang } { "c = 3" \ "d = ${d_pattern}" \ "e = ${e_pattern}" \ - "g = ${g_pattern}" \ + "g = ${g_val_pattern}" \ "_e = 6" ] gdb_test "info args" $args_pattern \
reply other threads:[~2022-05-31 14:46 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220531144624.60614395A027@sourceware.org \ --to=nckempke@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).