espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-22 19:09:31 +08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Kevin Buettner
2020-07-30 20:09:05 -07:00
parent e6a6c7676a
commit 9ef1ec5dca
2 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
gdb/testsuite/ChangeLog
View File

@ -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

27
gdb/testsuite/gdb.base/coremaker2.c
View File

@ -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)