| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
Fix grammar in some comments and docs:
- machines that doesn't -> machines that don't
- its a -> it's a
- its the -> it's the
- if does its not -> if it does it's not
- one more instructions if doesn't match ->
one more instruction if it doesn't match
- it's own -> its own
- it's first -> its first
- it's pointer -> its pointer
I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public
domain notice, I've left that alone.
Tested on x86_64-linux.
|
|
The mi_clean_restart proc calls the mi_gdb_start proc passing no
arguments.
In this commit I add an extra (optional) argument to the
mi_clean_restart proc, and pass this through to mi_gdb_start.
The benefit of this is that we can now use mi_clean_restart when we
also want to pass the 'separate-mi-tty' or 'separate-inferior-tty'
flags to mi_gdb_start, and avoids having to otherwise duplicate the
contents of mi_clean_restart in different tests.
I've updated the obvious places where this new functionality can be
used, and I'm seeing no test regressions.
Reviewed-By: Pedro Alves <pedro@palves.net>
|
|
This changes some tests to use "require !use_gdb_stub".
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
local-remote-host.exp takes about 44 seconds.
I found two silent timeouts responsible for this.
The first is in mi_gdb_exit, where we have:
...
if { [is_remote host] && [board_info host exists fileid] } {
send_gdb "999-gdb-exit\n"
gdb_expect 10 {
-re "y or n" {
send_gdb "y\n"
exp_continue
}
-re "Undefined command.*$gdb_prompt $" {
send_gdb "quit\n"
exp_continue
}
-re "DOSEXIT code" { }
}
}
...
so in gdb.log we see:
...
999-gdb-exit^M
999^exit^M
=thread-exited,id="1",group-id="i1"^M
=thread-group-exited,id="i1"^M
...
after which expect just waits for the timeout.
Fix this by adding a gdb_expect clause to parse the exit:
...
-re "\r\n999\\^exit\r\n" { }
...
Note that we're not parsing the thread-exited/thread-group-exited messages, because
they may not be present:
...
$ gdb -i=mi
=thread-group-added,id="i1"
(gdb)
999-gdb-exit
999^exit
$
...
After fixing that, we have:
...
(gdb) ^M
saw mi error
PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
force-fail=1: run failure detected
quit^M
&"quit\n"^M
...
What seems to be happening is that default_gdb_exit sends a cli interpreter
quit command to an mi interpreter, after which again expect just waits for the
timeout.
Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
gdb.mi/*.exp test-cases.
After these two fixes, the test-case takes about 4 seconds.
Tested on x86_64-linux.
|
|
I build gdb using -O2, and ran the testsuite using taskset -c 0, and ran into:
...
(gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=delete: setup: adjust sysroot
builtin_spawn gdbserver --once localhost:2385 /connect-with-no-symbol-file^M
/bin/bash: connect-with-no-symbol-file: Permission denied^M
/bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \
Permission denied^M
During startup program exited with code 126.^M
Exiting^M
target remote localhost:2385^M
`connect-with-no-symbol-file' has disappeared; keeping its symbols.^M
localhost:2385: Connection timed out.^M
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=delete: connection to GDBserver succeeded
...
The expected series of events is (skipping disconnect and detach as I don't
think they're relevant to the problem):
- enter scenario "permission"
- cp $exec.bak $exec
- gdbserver start with $exec
- chmod 000 $exec
- connect to gdbserver
- enter scenario "delete"
- cp $exec.bak $exec
- gdbserver start with $exec
- delete $exec
- connect to gdbserver
The problem is that the chmod is executed using remote_spawn:
...
} elseif { $action == "permission" } {
remote_spawn target "chmod 000 $target_exec"
}
...
without waiting on the resulting spawn id, so we're not sure when the
chmod will have effect.
The FAIL we're seeing above is explained by the chmod having effect during the
delete scenario, after the "cp $exec.bak $exec" and before the "gdbserver
start with $exec".
Fix this by using remote_exec instead.
Likewise, fix a similar case in gdb.mi/mi-exec-run.exp.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29726
|
|
After this previous commit I was thinking about the API of
mi_gdb_start. I felt that the idea of passing flags as separate
arguments and using 'args' to gather these into a list, though clever,
was not an intuitive API.
In this commit I modify mi_gdb_start so that it expects a single
argument, which should be a list of flags. Thus, where we previously
would have said:
mi_gdb_start separate-mi-tty separate-inferior-tty
We would now say:
mi_gdb_start { separate-mi-tty separate-inferior-tty }
However, it turns out we never actually call mi_gdb_start passing two
arguments in this way at all. We do in some places do this:
mi_gdb_start separate-inferior-tty
But that's fine, a single string like this works equally well as a
single item list, so this will not need updating.
There is also one place where we do this:
eval mi_gdb_start $start_ops
where $start_ops is a list that might contains 0, 1, or 2 items. The
eval here is used to expand the $start_ops list so mi_gdb_start sees
the list contents as separate arguments. In this case we just need to
drop the use of eval.
I think that the new API is more intuitive, but others might
disagree, in which case I can drop this change.
There should be no change in what is tested after this commit.
|
|
When running the gdb.mi/mi-exec-run.exp test using the
native-extended-gdbserver I see failures like this:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected
There's a race condition here, so you might see a slightly different
set of failures, but I always see some from the 'run failure detected'
test.
NOTE: I also see an additional test failure:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
but that is a completely different issue, and is not being addressed
in this commit.
The problem for the 'run failure detected' test is that we end up
in gdb_expect looking for output from two spawn-ids, one from
gdbserver, and one from gdb. We're looking for one output pattern
from each spawn-id, and for the test to pass we need to see both
patterns.
Now, if gdb exits then this is a test failure (this would indicate gdb
crashing, which is bad), so we have an eof pattern associated with
the gdb spawn-id.
However, in this particular test we expect gdbserver to fail to
execute the binary (the test binary is set non-executable), and so we
get an error message from gdbserver (which matches the pattern), and
then gdbserver exits, this is expected.
The problem is that after spotting the pattern from gdbserver, we
often see the eof from gdbserver before we see the pattern from gdb.
If this happens then we drop out of the gdb_expect without ever seeing
the pattern from gdb, and fail the test.
In this commit, I place the spawn-id of gdbserver into a global
variable, and then use this global variable as the -i option within
the gdb_expect.
Now, once we have seen the expected pattern on the gdbserver spawn-id,
the global variable is cleared. After this the gdb_expect no longer
checks the gdbserver spawn-id for additional output, and so never sees
the eof event. This leaves the gdb_expect running, which allows the
pattern from gdb to be seen, and for the test to pass.
I now see no failures relating to 'run failure detected'.
|
|
Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
causes several Tcl errors to appear. For example,
(gdb)
ERROR: : spawn id exp20 not open
while executing
"expect {
-i exp11 -timeout 10
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp20 not open
UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)
This is happening because of the way this test is implemented:
while {1} {
gdb_expect {
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw mi error"
}
-i "$gdb_spawn_id"
-re "\\^error,msg=\"During startup program exited with code 127" {
set saw_mi_error 1
verbose -log "saw mi error"
}
# and so on
}
}
The first time this loop is executed, `inferior_spawn_id' is valid. When the
first branch of the expect statement is reached, gdbserver has exited, closing
the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed
again. The first branch now refers to a non-existent spawn_id, leading to the error.
This can be fixed by using exp_continue to loop in expect instead of looping around
expect, which is the approach I have used[1]. Note I've had to update the expected
message for the "During startup..." error message when running with gdbserver.
One other small change I've made is to add a log entry which spills the values of
the two variables, saw_mi_error and saw_perm_error (and updated the log output
for the later). This should make the log output clearer about why the test failed.
With this patch installed, all the ERRORs disappear, leaving previously masked
FAILs (which I have not attempted to fix).
[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
assume that it was intentionally written this way, and I've modified the code with
that assumption. I have tested a version using gdb_test_multiple, and that appears
to work fine, too, if that is preferred. [It still employs exp_continue to fix the
spawn_id errors.]
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
In the GDB test suite, there are still multiple invocations of
"target_info exists use_gdb_stub". However, the recommended way of
checking for use_gdb_stub is to call the convenience function of the same
name.
Replace these occurrences and just call "use_gdb_stub" instead.
gdb/testsuite/ChangeLog:
* gdb.ada/exec_changed.exp: Replace "target_info exists
use_gdb_stub" by "use_gdb_stub".
* gdb.ada/start.exp: Likewise.
* gdb.base/async-shell.exp: Likewise.
* gdb.base/attach-pie-misread.exp: Likewise.
* gdb.base/attach-wait-input.exp: Likewise.
* gdb.base/break-entry.exp: Likewise.
* gdb.base/break-interp.exp: Likewise.
* gdb.base/dprintf-detach.exp: Likewise.
* gdb.base/nostdlib.exp: Likewise.
* gdb.base/solib-nodir.exp: Likewise.
* gdb.base/statistics.exp: Likewise.
* gdb.base/testenv.exp: Likewise.
* gdb.mi/mi-exec-run.exp: Likewise.
* gdb.mi/mi-start.exp: Likewise.
* gdb.multi/dummy-frame-restore.exp: Likewise.
* gdb.multi/multi-arch-exec.exp: Likewise.
* gdb.multi/multi-arch.exp: Likewise.
* gdb.multi/tids.exp: Likewise.
* gdb.multi/watchpoint-multi.exp: Likewise.
* gdb.python/py-events.exp: Likewise.
* gdb.threads/attach-into-signal.exp: Likewise.
* gdb.threads/attach-stopped.exp: Likewise.
* gdb.threads/threadapply.exp: Likewise.
* lib/selftest-support.exp: Likewise.
|
|
gdb/ChangeLog:
Update copyright year range in all 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.
|
|
The following scenario:
- gdb started in normal CLI mode.
- separate MI channel created with new-ui
- inferior output redirected with the "set inferior-tty" command.
- use -exec-run in the MI channel to run the inferior
is presently mishandled.
When we create the inferior, in fork-child.c, right after vfork, we'll
close all the file descriptors in the vfork child, and then dup the
tty to file descriptors 0/1/2, create a session, etc. Note that when
we close all descriptors, we close the file descriptors behind
gdb_stdin/gdb_stdout/gdb_stderr of all secondary UIs... So if
anything goes wrong in the child and it calls warning/error, it'll end
up writting to the current UI's stdout/stderr streams, which are
backed by file descriptors that have since been closed. Because this
happens in a vfork region, the corresponding stdin/stdout/stderr in
the parent/gdb end up corrupted.
The fix is to switch to the main UI right after the vfork, so that
gdb_stdin/gdb_stdout/gdb_stderr are correctly mapped to
stdin/stdout/stderr (and thus to file descriptors 0/1/2), so this code
works as it has always worked.
(Technically, we're doing a lot of stuff we shouldn't be doing after a
vfork, while we should only be calling async-signal-safe functions.)
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* fork-child.c (fork_inferior): Switch the child to the main UI
right after vfork. Save/restore the current UI in the parent.
Flush outputs of the main UI instead of the current UI.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-exec-run.exp: New file.
|
