From: Kevin Buettner Date: Fri, 31 Jul 2020 03:09:05 +0000 (-0700) Subject: Fix gdb.base/corefile2.exp test case for ppc64le X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9ef1ec5dca12fce2d9e9d3711c8a4091611c804d;p=binutils-gdb.git 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 2a194d16fb6..4e7bcbe6ac6 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,10 @@ +2020-07-31 Kevin Buettner + + * 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 * 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 ecba247f508..3c89bd790bd 100644 --- 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)