mirror/binutils-gdb
2
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2024-12-15 04:31:49 +08:00
Code Issues Packages Projects Releases Wiki Activity
e0d8f43169
binutils-gdb/gdb/testsuite/gdb.base/foll-exec-mode.c

46 lines
1.3 KiB
C
Raw Normal View History

New test for follow-exec-mode This patch implements a new GDB test for follow-exec-mode. Although there is a GDB test for debugging across an exec, there is no test for follow-exec-mode. This test is derived from gdb.base/foll-exec.exp, and re-uses execd-prog.c as the program to exec. The following behavior is tested: follow-exec-mode == "same" - 'next' over the exec, check for one inferior - 'continue' past the exec to a breakpoint, check for one inferior - after the exec, use a 'run' command to run the current binary follow-exec-mode == "new" - 'next' over the exec, check for two inferiors - 'continue' past the exec to a breakpoint, check for two inferiors - after the exec, use a 'run' command to run the current binary - after the exec, use the 'inferior' command to switch inferiors, then use a 'run' command to run the current binary Note that single-step breakpoints do not survive across an exec. There has to be a breakpoint in the execed program in order for it to stop right after the exec. gdb/testsuite/ChangeLog: * gdb.base/foll-exec-2.c: New test program. * gdb.base/foll-exec-2.exp: New test.
2015-08-27 04:26:36 +08:00
/* This test program is part of GDB, the GNU debugger.
update copyright year range in GDB files This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2017-01-01 14:50:51 +08:00
Copyright 2015-2017 Free Software Foundation, Inc.
New test for follow-exec-mode This patch implements a new GDB test for follow-exec-mode. Although there is a GDB test for debugging across an exec, there is no test for follow-exec-mode. This test is derived from gdb.base/foll-exec.exp, and re-uses execd-prog.c as the program to exec. The following behavior is tested: follow-exec-mode == "same" - 'next' over the exec, check for one inferior - 'continue' past the exec to a breakpoint, check for one inferior - after the exec, use a 'run' command to run the current binary follow-exec-mode == "new" - 'next' over the exec, check for two inferiors - 'continue' past the exec to a breakpoint, check for two inferiors - after the exec, use a 'run' command to run the current binary - after the exec, use the 'inferior' command to switch inferiors, then use a 'run' command to run the current binary Note that single-step breakpoints do not survive across an exec. There has to be a breakpoint in the execed program in order for it to stop right after the exec. gdb/testsuite/ChangeLog: * gdb.base/foll-exec-2.c: New test program. * gdb.base/foll-exec-2.exp: New test.
2015-08-27 04:26:36 +08:00
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/>. */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
[testsuite] Remove BASEDIR BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html in order to handle the different directory layout in serial testing and parallel testing. BASEDIR is "gdb.base" in serial testing and is "outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't work if the GDBserver is in remote target, like this, $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp' FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited) these tests fail because the executable can't be found. With target board native-gdbserver, the program is spawned this way, spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR is correct. However, with target board remote-gdbserver-on-localhost, the program is spawned spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no sense. I had a fix that pass absolute directory to BASEDIR, but it assumes that directory structure is the same on build and target, and it doesn't work in remote host case. The current fix in this patch is to get the directory from argv[0]. In any case, the program to be exec'ed is at the same directory with the main program. Note that these tests do "next N" to let program stop at the desired line, but it is fragile, because GDB for different targets may skip function prologue slightly differently, so I replace some of them by "tbreak on LINE NUMBER and continue". gdb/testsuite: 2016-02-04 Yao Qi <yao.qi@linaro.org> * gdb.base/foll-exec-mode.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in compilation. * gdb.base/foll-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation. Adjust tests on the number of lines as source code changed. * gdb.base/foll-vfork-exit.c: Include limits.h. (main): Add one line of statement before vfork. * gdb.base/foll-vfork.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation. (setup_gdb): Set tbreak to skip some source lines. * gdb.multi/bkpt-multi-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in compilation. * gdb.multi/multi-arch-exec.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in compilation.
2016-02-04 23:46:37 +08:00
#include <limits.h>
New test for follow-exec-mode This patch implements a new GDB test for follow-exec-mode. Although there is a GDB test for debugging across an exec, there is no test for follow-exec-mode. This test is derived from gdb.base/foll-exec.exp, and re-uses execd-prog.c as the program to exec. The following behavior is tested: follow-exec-mode == "same" - 'next' over the exec, check for one inferior - 'continue' past the exec to a breakpoint, check for one inferior - after the exec, use a 'run' command to run the current binary follow-exec-mode == "new" - 'next' over the exec, check for two inferiors - 'continue' past the exec to a breakpoint, check for two inferiors - after the exec, use a 'run' command to run the current binary - after the exec, use the 'inferior' command to switch inferiors, then use a 'run' command to run the current binary Note that single-step breakpoints do not survive across an exec. There has to be a breakpoint in the execed program in order for it to stop right after the exec. gdb/testsuite/ChangeLog: * gdb.base/foll-exec-2.c: New test program. * gdb.base/foll-exec-2.exp: New test.
2015-08-27 04:26:36 +08:00
int global_i = 100;
[testsuite] Remove BASEDIR BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html in order to handle the different directory layout in serial testing and parallel testing. BASEDIR is "gdb.base" in serial testing and is "outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't work if the GDBserver is in remote target, like this, $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp' FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited) these tests fail because the executable can't be found. With target board native-gdbserver, the program is spawned this way, spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR is correct. However, with target board remote-gdbserver-on-localhost, the program is spawned spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no sense. I had a fix that pass absolute directory to BASEDIR, but it assumes that directory structure is the same on build and target, and it doesn't work in remote host case. The current fix in this patch is to get the directory from argv[0]. In any case, the program to be exec'ed is at the same directory with the main program. Note that these tests do "next N" to let program stop at the desired line, but it is fragile, because GDB for different targets may skip function prologue slightly differently, so I replace some of them by "tbreak on LINE NUMBER and continue". gdb/testsuite: 2016-02-04 Yao Qi <yao.qi@linaro.org> * gdb.base/foll-exec-mode.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in compilation. * gdb.base/foll-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation. Adjust tests on the number of lines as source code changed. * gdb.base/foll-vfork-exit.c: Include limits.h. (main): Add one line of statement before vfork. * gdb.base/foll-vfork.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation. (setup_gdb): Set tbreak to skip some source lines. * gdb.multi/bkpt-multi-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in compilation. * gdb.multi/multi-arch-exec.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in compilation.
2016-02-04 23:46:37 +08:00
int main (int argc, char ** argv)
New test for follow-exec-mode This patch implements a new GDB test for follow-exec-mode. Although there is a GDB test for debugging across an exec, there is no test for follow-exec-mode. This test is derived from gdb.base/foll-exec.exp, and re-uses execd-prog.c as the program to exec. The following behavior is tested: follow-exec-mode == "same" - 'next' over the exec, check for one inferior - 'continue' past the exec to a breakpoint, check for one inferior - after the exec, use a 'run' command to run the current binary follow-exec-mode == "new" - 'next' over the exec, check for two inferiors - 'continue' past the exec to a breakpoint, check for two inferiors - after the exec, use a 'run' command to run the current binary - after the exec, use the 'inferior' command to switch inferiors, then use a 'run' command to run the current binary Note that single-step breakpoints do not survive across an exec. There has to be a breakpoint in the execed program in order for it to stop right after the exec. gdb/testsuite/ChangeLog: * gdb.base/foll-exec-2.c: New test program. * gdb.base/foll-exec-2.exp: New test.
2015-08-27 04:26:36 +08:00
{
int local_j = global_i + 1;
int local_k = local_j + 1;
[testsuite] Remove BASEDIR BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html in order to handle the different directory layout in serial testing and parallel testing. BASEDIR is "gdb.base" in serial testing and is "outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't work if the GDBserver is in remote target, like this, $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp' FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited) these tests fail because the executable can't be found. With target board native-gdbserver, the program is spawned this way, spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR is correct. However, with target board remote-gdbserver-on-localhost, the program is spawned spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no sense. I had a fix that pass absolute directory to BASEDIR, but it assumes that directory structure is the same on build and target, and it doesn't work in remote host case. The current fix in this patch is to get the directory from argv[0]. In any case, the program to be exec'ed is at the same directory with the main program. Note that these tests do "next N" to let program stop at the desired line, but it is fragile, because GDB for different targets may skip function prologue slightly differently, so I replace some of them by "tbreak on LINE NUMBER and continue". gdb/testsuite: 2016-02-04 Yao Qi <yao.qi@linaro.org> * gdb.base/foll-exec-mode.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in compilation. * gdb.base/foll-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation. Adjust tests on the number of lines as source code changed. * gdb.base/foll-vfork-exit.c: Include limits.h. (main): Add one line of statement before vfork. * gdb.base/foll-vfork.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation. (setup_gdb): Set tbreak to skip some source lines. * gdb.multi/bkpt-multi-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in compilation. * gdb.multi/multi-arch-exec.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in compilation.
2016-02-04 23:46:37 +08:00
char prog[PATH_MAX];
int len;
strcpy (prog, argv[0]);
len = strlen (prog);
/* Replace "foll-exec-mode" with "execd-prog". */
memcpy (prog + len - 14, "execd-prog", 10);
prog[len - 4] = 0;
New test for follow-exec-mode This patch implements a new GDB test for follow-exec-mode. Although there is a GDB test for debugging across an exec, there is no test for follow-exec-mode. This test is derived from gdb.base/foll-exec.exp, and re-uses execd-prog.c as the program to exec. The following behavior is tested: follow-exec-mode == "same" - 'next' over the exec, check for one inferior - 'continue' past the exec to a breakpoint, check for one inferior - after the exec, use a 'run' command to run the current binary follow-exec-mode == "new" - 'next' over the exec, check for two inferiors - 'continue' past the exec to a breakpoint, check for two inferiors - after the exec, use a 'run' command to run the current binary - after the exec, use the 'inferior' command to switch inferiors, then use a 'run' command to run the current binary Note that single-step breakpoints do not survive across an exec. There has to be a breakpoint in the execed program in order for it to stop right after the exec. gdb/testsuite/ChangeLog: * gdb.base/foll-exec-2.c: New test program. * gdb.base/foll-exec-2.exp: New test.
2015-08-27 04:26:36 +08:00
printf ("foll-exec is about to execlp(execd-prog)...\n");
[testsuite] Remove BASEDIR BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html in order to handle the different directory layout in serial testing and parallel testing. BASEDIR is "gdb.base" in serial testing and is "outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't work if the GDBserver is in remote target, like this, $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp' FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited) these tests fail because the executable can't be found. With target board native-gdbserver, the program is spawned this way, spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR is correct. However, with target board remote-gdbserver-on-localhost, the program is spawned spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no sense. I had a fix that pass absolute directory to BASEDIR, but it assumes that directory structure is the same on build and target, and it doesn't work in remote host case. The current fix in this patch is to get the directory from argv[0]. In any case, the program to be exec'ed is at the same directory with the main program. Note that these tests do "next N" to let program stop at the desired line, but it is fragile, because GDB for different targets may skip function prologue slightly differently, so I replace some of them by "tbreak on LINE NUMBER and continue". gdb/testsuite: 2016-02-04 Yao Qi <yao.qi@linaro.org> * gdb.base/foll-exec-mode.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in compilation. * gdb.base/foll-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation. Adjust tests on the number of lines as source code changed. * gdb.base/foll-vfork-exit.c: Include limits.h. (main): Add one line of statement before vfork. * gdb.base/foll-vfork.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation. (setup_gdb): Set tbreak to skip some source lines. * gdb.multi/bkpt-multi-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in compilation. * gdb.multi/multi-arch-exec.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in compilation.
2016-02-04 23:46:37 +08:00
execlp (prog, /* Set breakpoint here. */
New test for follow-exec-mode This patch implements a new GDB test for follow-exec-mode. Although there is a GDB test for debugging across an exec, there is no test for follow-exec-mode. This test is derived from gdb.base/foll-exec.exp, and re-uses execd-prog.c as the program to exec. The following behavior is tested: follow-exec-mode == "same" - 'next' over the exec, check for one inferior - 'continue' past the exec to a breakpoint, check for one inferior - after the exec, use a 'run' command to run the current binary follow-exec-mode == "new" - 'next' over the exec, check for two inferiors - 'continue' past the exec to a breakpoint, check for two inferiors - after the exec, use a 'run' command to run the current binary - after the exec, use the 'inferior' command to switch inferiors, then use a 'run' command to run the current binary Note that single-step breakpoints do not survive across an exec. There has to be a breakpoint in the execed program in order for it to stop right after the exec. gdb/testsuite/ChangeLog: * gdb.base/foll-exec-2.c: New test program. * gdb.base/foll-exec-2.exp: New test.
2015-08-27 04:26:36 +08:00
"/execd-prog",
"execlp arg1 from foll-exec",
(char *) 0);
}
Reference in New Issue Copy Permalink