Fix gdb.base/corefile2.exp test case for ppc64le

It turns out that the recently added gdb.base/corefile2.exp test won't
run on ppc64le linux.  The test case fails the internal checks which
ensure that a mmap'd region can be placed within the statically
allocated regions buf_rw[] and buf_ro[].

ppc64le linux apparently has 64k pages, which is much larger than
the 24k regions originally allocated for buf_rw[] and buf_ro[].

This patch increases the size of each region to 256 KiB.

Tested on either rawhide or Fedora 32 for these architectures: x86_64,
x86_64/-m32, ppc64le, aarch64, and s390x.

gdb/testsuite/ChangeLog:

	* gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB.
	(C5_24k): Delete.
	(C5_8k, C5_64k, C5_256k): New macros.
	(buf_ro): Allocate 256 KiB of initialized data.

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 2a194d16fb6ccc40733b84905634ec2066af0a50..4e7bcbe6ac6d32a7a7adef5fa444220f7e0da166 100644 (file)
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2020-07-31  Kevin Buettner  <kevinb@redhat.com>
+
+       * gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB.
+       (C5_24k): Delete.
+       (C5_8k, C5_64k, C5_256k): New macros.
+       (buf_ro): Allocate 256 KiB of initialized data.
+
 2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
 
        * gdb.base/condbreak-bad.exp: Extend the test with scenarios

diff --git a/gdb/testsuite/gdb.base/coremaker2.c b/gdb/testsuite/gdb.base/coremaker2.c
index ecba247f5080fa3b448a1a49385538a360761dec..3c89bd790bd6ad9aca0aa038b567012e4a9d788a 100644 (file)
--- a/gdb/testsuite/gdb.base/coremaker2.c
+++ b/gdb/testsuite/gdb.base/coremaker2.c
@@ -47,12 +47,8 @@ unsigned long long addr;
 char *mbuf_ro;
 char *mbuf_rw;
 
-/* 24 KiB buffer.  */
-char buf_rw[24 * 1024];
-
-/* 24 KiB worth of data.  For this test case, we can't allocate a
-   buffer and then fill it; we want GDB to have to read this data
-   from the executable; it should NOT find it in the core file.  */
+/* 256 KiB buffer.  */
+char buf_rw[256 * 1024];
 
 #define C5_16 \
   0xc5, 0xc5, 0xc5, 0xc5, \
@@ -69,15 +65,22 @@ char buf_rw[24 * 1024];
 #define C5_1k \
   C5_256, C5_256, C5_256, C5_256
 
-#define C5_24k \
-  C5_1k, C5_1k, C5_1k, C5_1k, \
-  C5_1k, C5_1k, C5_1k, C5_1k, \
-  C5_1k, C5_1k, C5_1k, C5_1k, \
-  C5_1k, C5_1k, C5_1k, C5_1k, \
+#define C5_8k \
   C5_1k, C5_1k, C5_1k, C5_1k, \
   C5_1k, C5_1k, C5_1k, C5_1k
 
-const char buf_ro[] = { C5_24k };
+#define C5_64k \
+  C5_8k, C5_8k, C5_8k, C5_8k, \
+  C5_8k, C5_8k, C5_8k, C5_8k
+
+#define C5_256k \
+  C5_64k, C5_64k, C5_64k, C5_64k
+
+/* 256 KiB worth of data.  For this test case, we can't allocate a
+   buffer and then fill it; we want GDB to have to read this data
+   from the executable; it should NOT find it in the core file.  */
+
+const char buf_ro[] = { C5_256k };
 
 int
 main (int argc, char **argv)