binutils-gdb/gdb/testsuite/gdb.reverse/insn-reverse.c

61 lines
1.8 KiB
C
Raw Normal View History

/* This testcase is part of GDB, the GNU debugger.
Copyright 2015-2018 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
typedef void (*testcase_ftype) (void);
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
/* The arch-specific files need to implement both the initialize function
and define the testcases array. */
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
#if (defined __aarch64__)
#include "insn-reverse-aarch64.c"
#elif (defined __arm__)
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
#include "insn-reverse-arm.c"
#elif (defined __x86_64__) || (defined __i386__)
#include "insn-reverse-x86.c"
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
#else
/* We get here if the current architecture being tested doesn't have any
record/replay instruction decoding tests implemented. */
static testcase_ftype testcases[] = {};
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
/* Dummy implementation in case this target doesn't have any record/replay
instruction decoding tests implemented. */
static void
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
initialize (void)
{
}
#endif
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
/* GDB will read n_testcases to know how many functions to test. The
functions are implemented in arch-specific files and the testcases
array is defined together with them. */
static int n_testcases = (sizeof (testcases) / sizeof (testcase_ftype));
int
main ()
{
int i = 0;
Refactor gdb.reverse/insn-reverse.c Changes in v2: - Renamed arch-specific files to insn-reverse-<arch>.c. - Adjusted according to reviews. This patch prepares things for an upcoming testcase for record/replay support on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by a few #if blocks, and right now it only handles arm/aarch64. If we move forward with requiring more tests for record/replay on different architectures, i think this has the potential to become cluttered with a lot of differing arch-specific code in the same file. I've broken up the main file into other files with arch-specific bits (insn-reverse-<arch>.c). The main file will hold the generic pieces that will take care of calling the tests. The arch-specific c files are then included at the top of the generic c file. I've also added a generic initialize function since we need to run pre-test checks on x86 to make sure the rdrand/rdseed instructions are supported, otherwise we will run into a SIGILL. The arch-specific files will implement their own initialize function with whatever makes sense. Right now the aarch64 and arm files have an empty initialization function. Does this look reasonable? gdb/testsuite/ChangeLog: 2017-01-26 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own files. (initialize): New function conditionally defined. (testcases): Move within conditional block. (main): Call initialize. * gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits of gdb.reverse/insn-reverse.c. * gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of gdb.reverse/insn-reverse.c.
2017-01-26 17:34:42 +01:00
/* Initialize any required arch-specific bits. */
initialize ();
for (i = 0; i < n_testcases; i++)
testcases[i] ();
return 0;
}