| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
check
Following the implementation of exec-file-mismatch based on build-id,
an attach to a process that runs a modified exec-file was triggering
the exec-file-mismatch handling, giving a warning such as:
warning: Mismatch between current exec-file /bd/home/philippe/gdb/git/build_termours/gdb/testsuite/outputs/gdb.base/attach/attach
and automatically determined exec-file /bd/home/philippe/gdb/git/build_termours/gdb/testsuite/outputs/gdb.base/attach/attach
exec-file-mismatch handling is currently "ask"
as the build-ids differ when an exec-file is recompiled.
This patch ensures that the exec-file-mismatch check is done with an up to date
build-id. With this, exec-file-mismatch check will only trigger when the
PID file really differs from the (build-id refreshed) current exec-file.
Note that the additional check does not (yet) reload the symbols if
the exec-file is changed: this reload will happen later if needed.
gdb/ChangeLog
2020-06-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* exec.c (validate_exec_file): Ensure the build-id is up to
date by calling reopen_exec_file (that checks file timestamp
to decide to re-read the file).
gdb/testsuite/ChangeLog
2020-06-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/attach.exp: Test priority of 'exec-file' changed
over 'exec-file-mismatch'.
* gdb.base/attach.c: Mark should_exit volatile.
* gdb.base/attach2.c: Likewise. Add a comment explaining
why the sleep cannot be big.
* gdb.base/attach3.c: New file.
|
|
Modify gdb.base/attach.exp to test the behaviour of the option
exec-file-mismatch. Note that this test can also be run using/
make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS=gdb.base/attach.exp
to test the behaviour of attaching to running program using a gdb server.
Note: when running the test with a gdbserver, the tests in
test_command_line_attach_run fail because the command "run" is not supported.
I tried to extend the condition
if ![isnative] then {
unsupported "commandline attach run test"
return 0
}
but unclear to me how to best do that. The below trials all failed
to work properly:
if { ![isnative] || [target_is_gdbserver] } then {
if { ![isnative] || [use_gdb_stub] } then {
if { ![isnative] || [is_remote target] } then {
=> could never obtain a condition that was true with gdbserver.
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/attach.exp: Test 'set exec-file-mismatch'.
|
|
I have started seeing occasional runaway 'attach' processes these days.
I cannot be certain it is really caused by this patch, for example
grep 'FAIL.*cmdline attach run' does not show anything in my logs.
But as I remember this 'attach' runaway process always happened in GDB (but
I do not remember it in the past months) I think it would be most safe to just
solve it forever by [attached].
gdb/testsuite/ChangeLog
2014-09-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/attach.c: Include unistd.h.
(main): Call alarm. Add label postloop.
* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
gdb_breakpoint, gdb_continue_to_breakpoint.
(test_command_line_attach_run): Kill ${testpid} in one exit path.
|
|
|
