FreeBSD recently added a real vDSO in its shared page for the amd64
architecture. The vDSO is mapped at the address given by the
AT_KPRELOAD ELF auxiliary vector entry. To find the end of the
mapping range, parse the list of virtual map entries used by 'info
proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or
via the kinfo_getvmmap function for native targets (fetched from the
native target as the TARGET_OBJECT_FREEBSD_VMMAP object).
This silences warnings on recent FreeBSD/amd64 kernels due to not
finding symbols for the vdso:
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
I think gdb is probably better off having fewer languages involved
when generating code. 'sh' is unavoidable for build-time generation,
but for other things, let's use Python.
This rewrites make-target-delegates in Python. I've stuck pretty
closely to the original code in this rewrite, so it may look slightly
weird from a Python perspective.
The only output difference is that a copyright header is now
generated, using the code introduced in the previous patch.
make-target-delegates.py is simpler to invoke, as it knows the correct
input file to scan and it creates the output file itself.
This moves the copyright code from gdbarch.py to a new Python source
file, gdbcopyright.py. The function in this file will find the
copyright dates by scanning the calling script. This will be reused
in a future patch.
This involved minor changes to the output of gdbarch.py. Also, I've
updated copyright.py to remove the reference to gdbarch.sh. We don't
need to mention gdbarch.py there, either.
PR build/12440 points out that "make distclean" is broken in gdb.
Most of the breakage comes from other projects in the tree, but we can
fix some of the issues, which is what this patch does.
Note that the yacc output files, like c-exp.c, are left alone. In a
source distribution, these are included in the tarball, and if the
user builds in-tree, we would not want to remove them.
While that seems a bit obscure, it seems to me that "distclean" is
only really useful for in-tree builds anyway -- out-of-tree I simply
delete the entire build directory and start over.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12440
PR cli/17332, filed around 8 years ago, points out a typo in the docs
-- in one example, the command and its output are obviously out of
sync. This patch fixes it. I'm checking this in as obvious.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17332
If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:
(gdb) attach 6500
Attaching to process 6500
ptrace: Operation not permitted.
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.
It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.
With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
$ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
Additionally, handle the other cases when test with RUNTESTFLAGS=
"--target_board=native-extended-gdbserver".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
In the current code, there is no test result when execute the following
commands:
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
It is better to print explicit test result in can_spawn_for_attach.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
The patch series "gdb: Add basic support for LoongArch" has been
merged into master, list Tiezhu Yang as LoongArch maintainer.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
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.]
I got this warning from py-infthread.c using the Fedora 34 system GCC:
../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]
I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
'if' whose condition is always true -- but GCC can't know this. This
patch avoids the warning by adding a harmless initialization.
As noted in an earlier patch, the Ada lexer does not handle multi-byte
bracket sequences. This patch adds support for these for character
literals. gdb does not generally seem to handle the Ada wide string
types, so for the time being these continue to be excluded -- but an
explicit error is added to make this more clear.
In Ada, an enum can contain character literals. GNAT encodes these
values in a special way. For example, the Unicode character U+0178
would be represented as 'QW0178' in the DWARF:
<3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
<1130> DW_AT_name : (indirect string, offset: 0x19ff): QW0178
<1134> DW_AT_const_value : 2
gdb handles this reasonably well, but failed to handle the 'QWW'
encoding, which is used for characters outside the base plane.
Also, while working on this, I noticed that gdb will print the decimal
value for an enum character constant:
(gdb) print Char_X
$2 = 1 'x'
This is a nice feature, IMO, because in this situation the 'x' enum
constant does not have its usual decimal value -- it has the value
that's assigned based on the enumeration type.
However, gdb did not do this when it decided to print the constant
using the bracket notation:
(gdb) print Char_Thorn
$3 = ["de"]
This patch changes gdb to print the decimal value here as well, and to
put the bracket notation in single quotes -- otherwise gdb will be
printing something that it can't then read. Now it looks like:
(gdb) print Char_Thorn
$3 = 4 '["de"]'
Note that gdb can't read longer bracket notations, like the other ones
printed in this test case:
(gdb) print Char_King
$4 = 3 '["01fa00"]'
While I think this is a bug, I plan to fix it separately.
Finally, in the new test case, the copyright dates are chosen this way
because this all started as a copy of an existing test.
This adds a new read-only attribute gdb.InferiorThread.details, this
attribute contains a string, the results of target_extra_thread_info
for the thread, or None, if target_extra_thread_info returns nullptr.
As the string returned by target_extra_thread_info is unstructured,
this attribute is only really useful for echoing straight through to
the user, but, if a user wants to write a command that displays the
same, or a similar 'Thread Id' to the one seen in 'info threads', then
they need access to this string.
Given that the string produced by target_extra_thread_info varies by
target, there's only minimal testing of this attribute, I check that
the attribute can be accessed, and that the return value is either
None, or a string.
This is a snafu that I encountered while implementing the previous
patch, which attempted to use gdb_is_target_native. This proc and
gdb_is_target_remote both rely on gdb_is_target_1, which actually
cannot be called without gdb already running.
This patch adds appropriate warning comments to these procs and
causes gdb_is_target_1 to issue a Tcl error if it is called without a
gdb instance already running. This should prevent unwitting callers
from using this at the wrong time.
When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
the test suite throws several ERRORs on native-gdbserver/-m{32,64},
and native-extended-gdbsever/-m{32,64}:
[on native-extended-gdbserver/-m64]
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
ERROR: failed to extract expected results
ERROR: failed to extract expected results
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
ERROR: failed to extract expected results for lbound
This occurs because the tests require inferior I/O which we do not have
access to while using these targets.
This patch skips these tests when running on non-native targets.
I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
while executing
"expect {
-i exp11 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
I don't have a problem with the latter ERROR nor the UNRESOLVED
messages. However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.
This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.
With this commit in place, the log messages look like this instead:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".
gdb-add-index may trigger debuginfod's first-use notice. The notice
is misleading in this case. It instructs the user to modify .gdbinit
in order to permanently enable/disable debuginfod but gdb-add-index
invokes gdb with -nx which ignores .gdbinit.
Additionally debuginfod is not needed for gdb-add-index since the
symbol file is given as an argument and should already be present
locally.
Fix this by disabling debuginfod when gdb-add-index invokes gdb.
This commit adds operator+= and operator+ overloads for adding
gdb::unique_xmalloc_ptr<char> to a std::string. I could only find 3
places in GDB where this was useful right now, and these all make use
of operator+=.
I've also added a self test for gdb::unique_xmalloc_ptr<char>, which
makes use of both operator+= and operator+, so they are both getting
used/tested.
There should be no user visible changes after this commit, except when
running 'maint selftest', where the new self test is visible.
Joel noticed that if the remote dies unexpectedly during a command --
you can simulate this by using "continue" and then killing gdbserver
-- then the CLI will print a new prompt, but MI will not. Later, we
found out that this was also filed in bugzilla as PR mi/23820.
The output looks something like this:
| (gdb)
| cont
| &"cont\n"
| ~"Continuing.\n"
| ^running
| *running,thread-id="all"
| (gdb)
| [... some output from GDB during program startup...]
| =thread-exited,id="1",group-id="i1"
| =thread-group-exited,id="i1"
| &"Remote connection closed\n"
Now, what about that "(gdb)" in the middle?
That prompt comes from this questionable code in
mi-interp.c:mi_on_resume_1:
/* This is what gdb used to do historically -- printing prompt
even if it cannot actually accept any input. This will be
surely removed for MI3, and may be removed even earlier. */
if (current_ui->prompt_state == PROMPT_BLOCKED)
fputs_unfiltered ("(gdb) \n", mi->raw_stdout);
... which seems like something to remove. But maybe the intent here
is that this prompt is sufficient, and MI clients must be ready to
handle output coming after a prompt. On the other hand, if this code
*is* removed, then nothing would print a prompt in this scenario.
Anyway, the CLI and the TUI handle emitting the prompt here by hooking
into gdb::observers::command_error, but MI doesn't install an observer
here.
This patch adds the missing observer and arranges to show the MI
prompt. Regression tested on x86-64 Fedora 34.
It seems like this area could be improved a bit, by having
start_event_loop call the prompt-displaying code directly, rather than
indirecting through an observer. However, I haven't done this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820
PR testsuite/7142 -- old enough to have been converted from Gnats --
points out that test_list_filename_and_function in gdb.base/list.exp
has "fails" that are unmatched with passes. This patch cleans this up
a little.
Co-authored-by: Tom Tromey <tromey@adacore.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142
This patch adds support for wild template parameter list matches, similar
to how ABI tags or function overloads are now handled.
With this patch, users will be able to "gloss over" the details of matching
template parameter lists. This is accomplished by adding (yet more) logic
to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
by the user.
Here's a simple example using gdb.linespec/cpls-ops.exp:
Before
------
(gdb) ptype test_op_call
type = struct test_op_call {
public:
void operator()(void);
void operator()(int);
void operator()(long);
void operator()<int>(int *);
}
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x400583 in test_op_call::operator()(int)
at cpls-ops.cc:43
1.2 y 0x40058e in test_op_call::operator()()
at cpls-ops.cc:47
1.3 y 0x40059e in test_op_call::operator()(long)
at cpls-ops.cc:51
The breakpoint at test_op_call::operator()<int> was never set.
After
-----
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x400583 in test_op_call::operator()(int)
at cpls-ops.cc:43
1.2 y 0x40058e in test_op_call::operator()()
at cpls-ops.cc:47
1.3 y 0x40059e in test_op_call::operator()(long)
at cpls-ops.cc:51
1.4 y 0x4008d0 in test_op_call::operator()<int>(int*)
at cpls-ops.cc:57
Similar to how scope lookups work, passing "-qualified" to the break command
will cause a literal lookup of the symbol. In the example immediately above,
this will cause GDB to only find the three non-template functions.
This patch attempts to make a start at adding unit tests for
strncmp_iw_with_mode. While there is quite a bit of testing
of this function in other tests, these are currently end-to-end
tests.
This patch attempts to cover the basics of string matching, white
space, C++ ABI tags, and several other topics. However, one area
that is ostensibly missing is testing the `match_for_lcd' feature.
This is otherwise tested as part of our end-to-end DejaGNU-based
testing.
PR fortran/28801 points out a gdb crash that can be provoked by
certain Fortran code. The bug is that f77_get_upperbound assumes the
property is either a constant or undefined, but in this case it is
PROP_LOCEXPR.
This patch fixes the crash by making this function (and the
lower-bound one as well) do the correct check before calling
'const_val'.
Thanks to Andrew for writing the test case.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801
Commit 14b3360508 ("do_target_wait_1: Clear
TARGET_WNOHANG if the target isn't async.") broke some multi-target
tests, such as gdb.multi/multi-target-info-inferiors.exp. The symptom
is that execution just hangs at some point. What happens is:
1. One remote inferior is started, and now sits stopped at a breakpoint.
It is not "async" at this point (but it "can async").
2. We run a native inferior, the event loop gets woken up by the native
target's fd.
3. In do_target_wait, we randomly choose an inferior to call target_wait
on first, it happens to be the remote inferior.
4. Because the target is currently not "async", we clear
TARGET_WNOHANG, resulting in synchronous wait. We therefore block
here:
#0 0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6
#1 0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
#2 0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134
#3 0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240
#4 0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365
#5 0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444
#6 0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471
#7 0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393
#8 0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446
#9 0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928
#10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037
#11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147
#12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337
#13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612
#14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636
#15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697
#16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716
#17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061
Before the aforementioned commit, we would not have cleared
TARGET_WNOHANG, the remote target's wait would have returned nothing,
and we would have consumed the native target's event.
After applying this revert, the testsuite state looks as good as before
for me on Ubuntu 20.04 amd64.
Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f
Make use of a range based for loop to iterate over a static global
array, removing the need to have a null entry at the end of the
array.
There should be no user visible changes after this commit.
On modern Darwin's, there appears to be a new circumstance in which a
MACH_NOTIFY_DEAD_NAME message can be received, and which was not
previously accounted for: to signal the WIFSTOPPED condition in the
debuggee. In that case the debuggee is not dead yet (and in fact,
counting it as dead would cause a zombie leak - A process in such a
state reparents to PID 1, but cannot be killed).
- Read and ignore such messages (counting on the next exception message
to let us know of the inferior's new state again)
- Refactor logging so as to clearly distinguish between the
MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or
something else), and warn in the last case
Co-authored-by: Louis-He <1726110778@qq.com>
Co-authored-by: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1
Commit 29ef4c0699 ("gdb/linux-tdep.c: Add Perms to the 'info proc
mappings' output") has broken test gdb.base/info-proc.exp on Linux,
because it changes the output of "info proc mappings" in a way that the
test does not expect (my bad for not testing before pushing).
I looked at how FreeBSD handles this, since I remembered it did show
permission flags. It looks like this:
Start Addr End Addr Size Offset Flags File
0x200000 0x243000 0x43000 0x0 r-- CN-- /usr/local/bin/tmux
(I think that `Flags` and the flags not being aligned is not
intentional)
The test passes on FreeBSD, because the test looks for four hex numbers
in a row and ignores the rest:
".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"
I suggest fixing it on Linux by moving the flags column to the same
place as in the FreeBSD output. It makes things a bit more consistent
between OSes, and we don't have to touch the test.
At the same time, make use of the actual length of the permission's
string to specify the number of characters to print.
Before this patch, the output looks like:
Start Addr End Addr Perms Size Offset objfile
0x55dd4b544000 0x55dd4b546000 r--p 0x2000 0x0 /usr/bin/sleep
and after, it looks like:
Start Addr End Addr Size Offset Perms objfile
0x5622ae662000 0x5622ae664000 0x2000 0x0 r--p /usr/bin/sleep
Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f
Change read_mapping to return a structure instead of taking many output
parameters. Change the string + length output parameters (permissions
and device) to be gdb::string_view, since that's what string_view is
for (a non-NULL terminated view on a string). No changes in behavior
expected.
Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112
PR c++/28901 points out a bug in C++ overload resolution. When
comparing two overloads, one might be better than the other for
certain parameters -- but, if that one also has some invalid
conversion, then it should never be considered the better choice.
Instead, a valid-but-not-apparently-quite-as-good overload should be
preferred.
This patch fixes this problem by changing how overload comparisons are
done. I don't believe it should affect any currently valid overload
resolution; nor should it affect resolutions where all the choices are
equally invalid.
Subclasses of inf_ptrace_target have to opt-in to using the event_pipe
by implementing the can_async_p and async methods. For subclasses
which do this, inf_ptrace_target provides is_async_p, async_wait_fd
and closes the pipe in the close target method.
inf_ptrace_target also provides wrapper routines around the event pipe
(async_file_open, async_file_close, async_file_flush, and
async_file_mark) for use in target methods such as async.
inf_ptrace_target also exports a static async_file_mark_if_open
function which can be used in SIGCHLD signal handlers.
ptrace on FreeBSD cannot be used against running processes and instead
fails with EBUSY. This meant that 'info threads' would fail if any of
the threads were running (for example when using schedule-multiple=on
in gdb.base/fork-running-state.exp). Instead of throwing errors, just
return nullptr as no thread name is better than causing info threads to
fail completely.
Move the message from 'show debug fbsd-lwp' to 'show debug fbsd-nat'
since it is helpful for debugging async target support and not just
LWP support.
Use target_pid_to_str to format the ptid and log the step and signo
arguments.
This is a fairly simple version of async target support.
Synchronous mode still uses blocking waitpid() calls in
inf_ptrace::wait() unlike the Linux native target which always uses
WNOHANG and uses sigsuspend() for synchronous operation.
Asynchronous mode registers an event pipe with the core as a file
handle and writes to the pipe when SIGCHLD is raised. TARGET_WNOHANG
is handled by inf_ptrace::wait().
- Handle TARGET_WNOHANG by passing WNOHANG to waitpid and returning
TARGET_WAITKIND_IGNORE if there are no events to report.
- Handle a race in async mode where SIGCHLD might signal the event
pipe for an event that has already been reported. If the event was
the exit of the last child process, waitpid() will fail with ECHILD
rather than returning a pid of 0. For this case, return
TARGET_WAITKIND_NO_RESUMED.
Previously this returned a TARGET_WAITKIND_SIGNALLED event for
inferior_ptid. However, inferior_ptid is invalid during ::wait()
methods after the multi-target changes, so this was triggering an
assertion further up the stack.
Previously, TARGET_WNOHANG was cleared if a target supported async
mode even if async mode wasn't currently enabled. This change only
permits TARGET_WNOHANG if async mode is enabled.
Now that target_resume always enables async mode after target::resume
returns, these calls are redundant.
The other place that target resume methods are invoked outside of
target_resume are as the beneath target in record_full_wait_1. In
this case, async mode should already be enabled when supported by the
target before the resume method is invoked due to the following:
In general, targets which support async mode run as async until
::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are
no unwaited for children (either they have exited or are stopped).
When that occurs, the loop in wait_one disables async mode. Later
if a stopped child is resumed, async mode is re-enabled in
do_target_resume before waiting for the next event.
In the case of record_full_wait_1, this function is invoked from the
::wait target method when fetching an event. If the underlying
target supports async mode, then an earlier call to do_target_resume
to resume the child reporting an event in the loop in
record_full_wait_1 would have already enabled async mode before
::wait was invoked. In addition, nothing in the code executed in
the loop in record_full_wait_1 disables async mode. Async mode is
only disabled higher in the call stack in wait_one after ::wait
returns.
It is also true that async mode can be disabled by an
INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of
the places that invoke that are in the gdb core which is "above" a
target ::wait method.
Note that there is an earlier call to enable async mode in
linux_nat_target::resume. That call also marks the async event pipe
to report an existing event after enabling async mode, so it needs to
stay.
Enabling async mode above the target layer removes duplicate code in
::resume methods of async-capable targets. Commit 5b6d1e4fa4
("Multi-target support") enabled async mode in do_target_resume after
target_resume returns which is a step in this direction. However,
other callers of target_resume such as target_continue do not enable
async mode. Rather than enabling async mode in each of the callers
after target_resume returns, enable async mode at the end of
target_resume.
Currently there are two problems with the detection of
source-highlight via pkg-config in GDB's configure script:
1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output
to AC_LINK_IFELSE, which results in the "-L/some/path
-lsource-highlight" preceding the conftest.cpp, which can result in a
failure to find symbols referenced in conftest.cpp, if the linker is
using --as-needed by default.
2. The CFLAGS variable is used to pass the 'pkg-config --cflags'
output to AC_LINK_IFELSE. However, as the current language is C++,
AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags
returned from pkg-config will not be seen.
This patch fixes both of these mistakes, allowing GDB to correctly
configure and build using source-highlight installed into a custom
prefix, e.g. ~/opt/gdb-git (because the system version of
source-highlight is too old).
The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad8801
([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
disable pagination, and in aae1c79a03 (PR python/12227..., 2010-12-07)
to point to the data directory, but its default value mentioned in the
testsuite's README was not kept up to date.
To avoid it getting out of sync even more, point the reader to the
definition of the variable in lib/gdb.exp, and move the explanation of
the different flags there. Also adjust the example in the README
so it follows the flags added in 55c3ad8801.
Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7
I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
added recently. This test was added in commit:
commit d08cbc5d32
Date: Wed Dec 22 12:57:44 2021 +0000
gdb: unbuffer all input streams when not using readline
The failures I see only occurred when my machine was very heavily
loaded.
In this test I send multiple commands from dejagnu to gdb with a
single send_gdb call. In a well behaving world what I want to happen
is that the gdb console sees both commands arrive and echos the text
of those commands. Then gdb starts processing the first command,
prints the result, and then processes the second command, and prints
the result.
However, what I saw in my loaded environment was that only after
sending the two commands, only the first command was echoed to gdb's
terminal. Then gdb started processing the first command, and started
to write the output. Now, mixed in with the first command output, the
second command was echoed to gdb's terminal. Finally, gdb would
finish printing the first command output, and would read and handle
the second command.
This mixing of command echoing with the first command output was
causing the test matching patterns to fail.
In this commit I change the command I use in the test from a CLI
command to an MI command, this reduces the number of lines of output
that come from the test, CLI commands sent through the MI interpreter
are echoed back like this:
(gdb)
set $a = "FIRST COMMAND"
&"set $a = \"FIRST COMMAND\"\n"
^done
(gdb)
While this is not the case for true MI command:
(gdb)
-data-evaluate-expression $a
^done,value="\"FIRST COMMAND\""
(gdb)
Less output makes for simpler patterns to match against.
Next, when sending two command to gdb I was previously trying to spot
the output of the first command followed by the prompt with nothing
between. This is not really needed, for the first command I can look
for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
looking for the output of the second command.
So long as the second pattern matches up to the gdb prompt, then I can
be sure than nothing is left over in the expect buffer to muck up
later matches.
As to see the second command output gdb must have read in the second
command, the second command output never suffers from the corruption
that the first command output does.
Since making this change, I've not seen a failure in this test.
