Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Simon Marchi <simark@simark.ca>, Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH][gdb/testsuite] Fix gdb.base/endianity.exp with gcc-4.8
Date: Sat, 19 Dec 2020 09:48:11 +0100	[thread overview]
Message-ID: <208ea7a9-d382-7fe4-89b2-75a9b6aa4e10@suse.de> (raw)
In-Reply-To: <686f81a2-cc07-fe65-02c1-2cb9ec9377e4@simark.ca>

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

On 12/14/20 5:55 PM, Simon Marchi wrote:
> On 2020-12-13 11:23 a.m., Tom de Vries wrote:
>> On 12/13/20 2:56 PM, Joel Brobecker wrote:
>>> Hi Tom,
>>>
>>>> When running test-case gdb.base/endianity.exp using gcc-4.8, we get:
>>>> ...
>>>> (gdb) x/x &o.v^M
>>>> 0x7fffffffd120: 0x00000004^M
>>>> (gdb) XFAIL: gdb.base/endianity.exp: x/x &o.v
>>>> x/xh &o.w^M
>>>> 0x7fffffffd124: 0x0003^M
>>>> (gdb) FAIL: gdb.base/endianity.exp: x/xh &o.w
>>>> ...
>>>>
>>>> The gcc 4.8 compiler does not support the scalar_storage_order attribute, so
>>>> the testcase is compiled without that attribute, and the expected results are
>>>> different.
>>>>
>>>> This is why there's the first XFAIL, and we could xfail the second FAIL for the
>>>> same reason.
>>>>
>>>> Instead, fix this by adapting the expected values based on whether the attribute
>>>> has been used in endianity.c.
>>>>
>>>> Also, remove hard-coding of the byte order in the expected memory printing.
>>>>
>>>> Tested on x86_64-linux, with gcc-4.8, gcc-7, and clang-10.
>>>>
>>>>
>>>> Any comments?
>>>
>>> For me, the whole point of this testcase is to test SSO, so if
>>> the compiler doesn't support it, the testcase loses its value
>>> entirely (to my eyes anyway). As a result of this, I dont' think
>>> bringing the extra complexity that you are suggesting is bringing
>>> any value -- I might argue that it's now hard to read the testcase
>>> an understand what we're trying to do (sorry!).
>>>
>>
>> Np, that's also good feedback, thanks.
>>
>>> In my opinion, rather than an XFAIL, we should just only do
>>> the second half of the testcase if the compiler supports it,
>>> than xfailing the tests. So I would do:
>>>
>>> if { ([test_compiler_info {gcc-[0-5]-*}] || ![test_compiler_info gcc*]) } {
>>>     # The rest of the testcase requires Scalar Storage Order support.
>>>     # This compiler does not support it, so skip the rest.
>>>     return
>>> }
>>>
>>
>> Ack, committed as below.
>>
>> Thanks,
>> - Tom
>>
> 
> Just a small nit, it would be nice to have an "unsupported" call in the
> if to record in the sum file that part of this file was skipped and why.
> 
> Also, I don't like the (pre-existing) check:
> 
>   if { ([test_compiler_info {gcc-[0-5]-*}] || ![test_compiler_info gcc*]) } {
> 
> That makes it so testing with any other compiler than gcc will result in
> this part being skipped.  What if clang gains support for this feature?
> 
> Would it make sense to have a small
> "supports_scalar_storage_order_attribute" util proc in lib/gdb.exp?

How about this?

Thanks,
- Tom


[-- Attachment #2: 0005-gdb-testsuite-Introduce-supports_scalar_storage_order_attribute.patch --]
[-- Type: text/x-patch, Size: 3876 bytes --]

[gdb/testsuite] Introduce supports_scalar_storage_order_attribute

Introduce support test procs:
- supports_scalar_storage_order_attribute, and
- supports_gnuc
and use them in test-case gdb.base/endianity.exp.

Tested on x86_64-linux with gcc-7.5.0, gcc-4.8.5, and clang 10.0.1.

gdb/testsuite/ChangeLog:

2020-12-19  Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (supports_scalar_storage_order_attribute)
	(supports_gnuc): New proc.
	* gdb.base/endianity.exp: Define TEST_SSO.  Eliminate
	test_compiler_info calls.  Add unsupported message.
	* gdb.base/endianity.c: Use TEST_SSO.

---
 gdb/testsuite/gdb.base/endianity.c   |  2 +-
 gdb/testsuite/gdb.base/endianity.exp | 11 ++++++---
 gdb/testsuite/lib/gdb.exp            | 46 ++++++++++++++++++++++++++++++++++++
 3 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/gdb.base/endianity.c b/gdb/testsuite/gdb.base/endianity.c
index ef3b6d4fdb..15cbdd9a26 100644
--- a/gdb/testsuite/gdb.base/endianity.c
+++ b/gdb/testsuite/gdb.base/endianity.c
@@ -26,7 +26,7 @@ struct otherendian
   __complex__ float cplx;
   double d;
 }
-#if defined __GNUC__ && (__GNUC__ >= 6)
+#if TEST_SSO
 #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 __attribute__( ( scalar_storage_order( "big-endian" ) ) )
 #else
diff --git a/gdb/testsuite/gdb.base/endianity.exp b/gdb/testsuite/gdb.base/endianity.exp
index 4520799d04..d54c1b6973 100644
--- a/gdb/testsuite/gdb.base/endianity.exp
+++ b/gdb/testsuite/gdb.base/endianity.exp
@@ -15,7 +15,12 @@
 
 standard_testfile .c
 
-if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
+set test_sso [expr \
+		  [supports_scalar_storage_order_attribute] \
+		  && [supports_gnuc]]
+
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
+	  [list debug additional_flags=-DTEST_SSO=$test_sso]] } {
   return -1
 }
 
@@ -37,12 +42,12 @@ gdb_test "print o.d = -23.125" "= -23.125"
 gdb_test "print o" "= {v = 4, w = 3, x = 2, f = 1.5, cplx = 1.25 \\+ 7.25i, d = -23.125}" \
     "print o after assignment"
 
-if { ([test_compiler_info {gcc-[0-5]-*}] || ![test_compiler_info gcc*]) } {
+if { !$test_sso } {
     # The rest of the testcase requires Scalar Storage Order support.
     # This compiler does not support it, so skip the rest.
+    unsupported "No scalar storage order support"
     return -1
 }
 
 gdb_test "x/x &o.v" "0x04000000"
 gdb_test "x/xh &o.w" "0x0300"
-
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index e812237d67..573d9cc802 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -7669,5 +7669,51 @@ gdb_caching_proc have_fuse_ld_gold {
     return [gdb_simple_compile $me $src executable $flags]
 }
 
+# Return 1 if compiler supports scalar_storage_order attribute, otherwise
+# return 0.
+gdb_caching_proc supports_scalar_storage_order_attribute {
+    set me "supports_scalar_storage_order_attribute"
+    set src {
+	#include <string.h>
+	struct sle {
+	    int v;
+	} __attribute__((scalar_storage_order("little-endian")));
+	struct sbe {
+	    int v;
+	} __attribute__((scalar_storage_order("big-endian")));
+	struct sle sle;
+	struct sbe sbe;
+	int main () {
+	    sle.v = sbe.v = 0x11223344;
+	    int same = memcmp (&sle, &sbe, sizeof (int)) == 0;
+	    int sso = !same;
+	    return sso;
+	}
+    }
+    if { ![gdb_simple_compile $me $src executable ""] } {
+	return 0
+    }
+
+    set result [remote_exec host $obj]
+    set status [lindex $result 0]
+    set output [lindex $result 1]
+    if { $output != "" } {
+	return 0
+    }
+
+    return $status
+}
+
+# Return 1 if compiler supports __GNUC__, otherwise return 0.
+gdb_caching_proc supports_gnuc {
+    set me "supports_gnuc"
+    set src {
+	#ifndef __GNUC__
+	#error "No gnuc"
+	#endif
+    }
+    return [gdb_simple_compile $me $src object ""]
+}
+
 # Always load compatibility stuff.
 load_lib future.exp

  reply	other threads:[~2020-12-19  8:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 15:29 Tom de Vries
2020-12-13 13:56 ` Joel Brobecker
2020-12-13 16:23   ` Tom de Vries
2020-12-14 16:55     ` Simon Marchi
2020-12-19  8:48       ` Tom de Vries [this message]
2020-12-19 13:42         ` Simon Marchi via Gdb-patches
2020-12-19 15:41           ` 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=208ea7a9-d382-7fe4-89b2-75a9b6aa4e10@suse.de \
    --to=tdevries@suse.de \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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