public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [pushed 1/2] [gdb/testsuite] Make is_64_target more robust
Date: Fri, 12 May 2023 11:44:10 +0200	[thread overview]
Message-ID: <20230512094412.24801-1-tdevries@suse.de> (raw)

I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and
with target board dwarf64 ran into:
...
FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
...
due to is_target_64 failing because of:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
  -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \
  is_64_target.c^M
gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \
  '-gdwarf -g64' for debug level^M
compiler exited with status 1
...

The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64
fails for both cases.

The reason that is_target_64 is failing for target board dwarf64, is because
of using system compiler 7.5.0 which doesn't support -gdwarf64.

Fix this by making is_target_64 use nodebug instead of debug for compilation.

Tested on x86_64-linux.
---
 gdb/testsuite/lib/gdb.exp | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 50c10333df1..010da097766 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3492,7 +3492,7 @@ gdb_caching_proc is_lp64_target {} {
 # This cannot be decided simply from looking at the target string,
 # as it might depend on externally passed compiler options like -m64.
 gdb_caching_proc is_64_target {} {
-    return [gdb_can_simple_compile is_64_target {
+    return [gdb_can_simple_compile_nodebug is_64_target {
 	int function(void) { return 3; }
 	int dummy[sizeof (&function) == 8 ? 1 : -1];
     }]
@@ -4736,6 +4736,13 @@ proc gdb_can_simple_compile {name code {type object} {compile_flags ""} {default
     return $ret
 }
 
+# As gdb_can_simple_compile, but defaults to using nodebug instead of debug.
+proc gdb_can_simple_compile_nodebug {name code {type object} {compile_flags ""}
+				     {default_compile_flags "nodebug nowarning quiet"}} {
+    return [gdb_can_simple_compile $name $code $type $compile_flags \
+		$default_compile_flags]
+}
+
 # Some targets need to always link a special object in.  Save its path here.
 global gdb_saved_set_unbuffered_mode_obj
 set gdb_saved_set_unbuffered_mode_obj ""

base-commit: 9827805ce1eea094d5b97bf27acdd120e5cdda86
-- 
2.35.3


             reply	other threads:[~2023-05-12  9:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12  9:44 Tom de Vries [this message]
2023-05-12  9:44 ` [pushed 2/2] [gdb/testsuite] Fix gdb.dwarf2/opt-out-not-implptr.exp for -m32 Tom de Vries

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=20230512094412.24801-1-tdevries@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@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: link
Be 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).