| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit
c221b2f77080 Testsuite: Add gdb_can_simple_compile
changed the source file name extension of the test program from .s to .c
resulting in compile fails. This, in turn, causes is_aarch32_target
checks to fail.
Change the test source from an assembly program to a C program using
inline assembly.
is_amd64_regs_target had a similar problem, which was fixed by commit
224d30d39365 testsuite: fix is_amd64_regs_target
This fix — and commit message — are mostly copied from it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I think there is a problem with the disable_breakpoints_in_shlibs
function: it can disable breakpoint locations without calling
notify_breakpoint_modified. This means that the Python API's
breakpoint_modified event will not trigger, nor will the MI send a
breakpoint modified event.
I started looking at disable_breakpoints_in_shlibs because of an
earlier commit:
commit 8c48ec7a6160aed0d1126c623443935e4435cd41
Date: Thu Aug 29 12:34:15 2024 +0100
gdb: handle dprintf breakpoints when unloading a shared library
Currently disable_breakpoints_in_shlibs is only called from one
location, clear_solib in solib.c. clear_solib also calls
notify_solib_unloaded for every solib in the program_space of
interest, and notify_solib_unloaded will call
disable_breakpoints_in_unloaded_shlib via the solib_unloaded
observer. These two function, disable_breakpoints_in_shlibs and
disable_breakpoints_in_unloaded_shlib are very similar in what they
do.
I think that we can remove the disable_breakpoints_in_shlibs call, and
instead, tweak how we call disable_breakpoints_in_unloaded_shlib in
order to get the same end result, except that, after this change, we
will call notify_breakpoint_modified, which means the Python API event
will trigger, and the MI events will be emitted.
All that disable_breakpoints_in_shlibs does is disable some
breakpoints.
Meanwhile, disable_breakpoints_in_unloaded_shlib, will disable the
same set of breakpoints, call notify_breakpoint_modified, and
then (for some breakpoint types) print a message telling the user that
the breakpoint has been disabled. However, this function will ignore
any breakpoints that are already disabled.
As disable_breakpoints_in_shlibs disables the same set of breakpoints,
the result of the current code is that disable_breakpoints_in_shlibs
serves only to prevent the notify_breakpoint_modified call, which I
think is wrong, and to prevent the user message being printed, which I
think is reasonable.
If we remove the disable_breakpoints_in_shlibs call without making any
additional changes, then we start to see some message printed in cases
like this:
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
warning: Temporarily disabling breakpoints for unloaded shared library "/tmp/shared-lib-test/libfoo.so"
Temporary breakpoint 3 at 0x40113e: file test.c, line 9.
Starting program: /tmp/shared-lib-test/test.x
Notice the 'warning:' line, which is new. I think this is confusing
because, in most cases the breakpoint will be enabled again by the
time the inferior reaches `main` and stops.
In the future I'm interested in exploring if GDB could be smarter
about when to print these 'Temporarily disabling breakpoints ...'
messages so that if the 'start' command does mean a breakpoint is left
disabled, then the user would be informed. However, I don't propose
doing that work immediately, and certainly not in this commit. For
now, my intention is to leave things as they are right now, GDB
doesn't warn about disabling breakpoints during an inferior re-start.
To achieve this I think we need to pass a new argument to
disable_breakpoints_in_unloaded_shlib which controls whether we should
print a message about the breakpoint being disabled or not. With this
added we can now silence the warning when the inferior is
restarted (i.e. when disable_breakpoints_in_unloaded_shlib is called
from clear_solib), but keep the warning for cases like stepping over a
dlclose() call in the inferior.
After this commit, GDB now emits breakpoint modified events (in Python
and/or MI) when a breakpoint is disabled as a result of all shared
libraries being unloaded. This will be visible in two places that I
can thing of, the 'nosharedlibrary' command, and when an inferior is
restarted.
|
|
Consider this backtrace within GDB:
#0 notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083
#1 0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523
#2 0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641
#3 0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476
#4 0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298
Whenever breakpoint_re_set is called we re-build the commands that the
dprintf b/p will execute and store these into the breakpoint. The
commands are re-built in update_dprintf_command_list and stored into
the breakpoint object in breakpoint_set_commands.
Now sometimes these commands can change, dprintf_breakpoint::re_set
explains one case where this can occur, and I'm sure there must be
others. But in most cases the commands we recalculate will not
change. This means that the breakpoint modified event which is
emitted from breakpoint_set_commands is redundant.
This commit aims to eliminate the redundant breakpoint modified events
for dprintf breakpoints. This is done by adding a commands_equal call
to the start of breakpoint_set_commands.
The commands_equal function is a new function which compares two
command_line objects and returns true if they are identical. Using
this function we can check if the new commands passed to
breakpoint_set_commands are identical to the breakpoint's existing
commands. If the new commands are equal then we don't need to change
anything on the new breakpoint, and the breakpoint modified event can
be skipped.
The test for this commit stops at a dlopen() call in the inferior,
sets up a dprintf breakpoint, then uses 'next' to step over the
dlopen() call. When the library loads GDB call breakpoint_re_set,
which calls dprintf_breakpoint::re_set. But in this case we don't
expect the calculated command string to change, so we don't expect to
see the breakpoint modified event.
|
|
With commit fb2ded33c1e519659743047ed7817166545b6d91, I added
Fedora's gstack script to gdb. Some issues have arisen since
then, and this patch addresses those issues:
. As Sam James recently noted[1], PKGVERSION and VERSION
need to be quoted.
. A Fedora user reported the misuse of --readnever, which
causes gstack to omit filename and line number information in the
backtrace[Red Hat BZ 2354997].
[1] https://inbox.sourceware.org/gdb-patches/d19d6bc17e0a160ce27fc572079f11a587c0e168.1742424869.git.sam@gentoo.org/
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2354997
|
|
Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces
the following incorrect backtrace:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
#2 0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50
#3 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The expected output, which we get with `bt`, is:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer
frame ids having already been computed and stashed. Unlike other
frames, frame #0's id does not get computed immediately.
The test passes with `bt` because when applying python frame filters,
the call to `bootstrap_python_frame_filters` happens to compute the id
of frame #0. When `get_prev_frame_maybe_check_cycle` later tries to
stash frame #2's id, the cycle is detected.
The test fails with `bt -no-filters` because frame #0's id has not been
stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash
frame #2's id which succeeds and the cycle is only detected later when
trying to stash frame #4's id. Doing `stepi` after the incorrect
backtrace would then trigger an assertion failure when trying to stash
frame #0's id because it is a duplicate of #2's already stashed id.
In `get_prev_frame_always_1`, if this_frame is inline frame 0, then
compute and stash its frame id before returning the previous frame.
This ensures that the id of inline frame 0 has been stashed before
`get_prev_frame_maybe_check_cycle` is called on older frames.
The test case has been updated to run both `bt` and `bt -no-filters`.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
|
|
In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run
into:
...
(gdb) inferior 2
[Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)]
[Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running)
(gdb) print global_var = 555
$1 = 555
(gdb) print global_var
$2 = 556
(gdb) FAIL: $exp: all-stop: access mem \
(print global_var after writing, inf=2, iter=1)
...
I managed to reproduce this on current trunk using a reproducer patch (posted
in the PR).
The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix
gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced
an increment of global_var at the start of main.
This created a race between:
- gdb modifying global_var, and
- the inferior modifying global_var.
Fix this by:
- adding a new empty function setup_done,
- adding a call to setup_done after the increment of global_var, and
- rather than running to main, running to setup_done.
Tested on x86_64-linux.
PR testsuite/32822
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822
|
|
In the AIX systems available for testing in the gcc compile farm, the
default debug information format is stabs. This is a problem for many
reasons, mainly that stabs is not as complete as dwarf and stabs is
being deprecated in the next release. In the current state, we have:
PASS: 39798
FAIL: 7405
When running these tests, I unfortunately didn't have the foresight to
save the number of unsupported and untested cases.
To improve testing there, this patch changes the gdb_compile TCL proc, so
that if we're running tests in AIX, we requested debug info, and we
haven't explicitly asked for some debuginfo format, gdb_compile will add
-gdwarf to the compilation line, forcing DWARF to be used. After this
patch, we get:
PASS: 74548
FAIL: 5963
So not only do we have fewer failures, there are tens of thousands of
tests that are no longer skipped.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
GDB's compile subsystem is deeply tied to GDB's ability to understand
DWARF. A future patch will add the option to disable DWARF at configure
time, but for that to work, the compile subsystem will need to be
entirely disabled as well, so this patch adds that possibility.
I also think there is motive for a security conscious user to disable
compile for it's own sake. Considering that the code is quite
unmaintained, and depends on an equally unmaintained gcc plugin, there
is a case to be made that this is an unnecessary increase in the attack
surface if a user knows they won't use the subsystem. Additionally, this
can make compilation slightly faster and the final binary is around 3Mb
smaller. But these are all secondary to the main goal of being able to
disable dwarf at configure time.
To be able to achieve optional compilation, some of the code that
interfaces with compile had to be changed. All parts that directly
called compile things have been wrapped by ifdefs checking for compile
support. The file compile/compile.c has been setup in a similar way to
how python's and guile's main file has been setup, still being compiled
but only for with placeholder command.
Finally, to avoid several new errors, a new TCL proc was introduced to
gdb.exp, allow_compile_tests, which checks if the "compile" command is
recognized before the inferior is started and otherwise skips the compile
tests. All tests in the gdb.compile subfolder have been updated to use
that, and the test gdb.base/filename-completion also uses this. The proc
skip_compile_feature_tests to recognize when the subsystem has been
disabled at compile time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Commit 3aaca06b672 ("gdb: fix color_option_def compile error (clang)")
fixed a compilation error in color_option_def when building with
clang. It seemed to me that it would be good to add a compile test
for this code.
|
|
The gdb.rocm/precise-memory.exp test currently checks that the "amdgpu
precise-memory" setting can be set. It does not test that this setting
has any meaningful effect.
This patch extends this test to ensure that precise-memory has the
expected behaviour.
Change-Id: I58f72a51a566f04fc89114b94ee656c2e7ac35bb
Approved-by: Pedro Alves <pedro@palves.net>
|
|
Remove hip_devices_support_precise_memory as this is not used anymore.
Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967
Approved-by: Pedro Alves <pedro@palves.net>
|
|
hip_devices_support_precise_memory
The gdb.rocm/precise-memory.exp test adjusts its behaviour based on the
value returned by hip_devices_support_precise_memory. This function has
static assumption regarding HW capabilities, which might not be
accurate.
Adjust the test so it does not assume anything about HW capabilities,
but instead just ensure that GDB behaves consistently.
Change-Id: Ie1f9c6219b88b94f6d461a254b2ad616b92db6b9
Approved-by: Pedro Alves <pedro@palves.net>
|
|
Currently GDB's source cache doesn't track whether the entries within
the cache are styled or not. This is pretty much fine, the assumption
is that any time we are fetching source code, we do so in order to
print it to the terminal, so where possible we always want styling
applied, and if styling is not applied, then it is because that file
cannot be styled for some reason.
Changes to 'set style enabled' cause the source cache to be flushed,
so future calls to fetch source code will regenerate the cache entries
with styling enabled or not as appropriate.
But this all assumes that styling is either on or off, and that
switching between these two states isn't done very often.
However, the Python API allows for individual commands to be executed
with styling turned off via gdb.execute(). See commit:
commit e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
Date: Thu Feb 13 15:39:31 2025 +0000
gdb/python: new styling argument to gdb.execute
Currently the source cache doesn't handle this case. Consider this:
(gdb) list main
... snip, styled source code displayed here ...
(gdb) python gdb.execute("list main", True, False, False)
... snip, styled source code is still shown here ...
In the second case, the final `False` passed to gdb.execute() is
asking for unstyled output.
The problem is that, `get_source_lines` calls `ensure` to prime the
cache for the file in question, then `extract_lines` just pulls the
lines of interest from the cached contents.
In `ensure`, if there is a cache entry for the desired filename, then
that is considered good enough. There is no consideration about
whether the cache entry is styled or not.
This commit aims to fix this, after this commit, the `ensure` function
will make sure that the cache entry used by `get_source_lines` is
styled correctly.
I think there are two approaches I could take:
1. Allow multiple cache entries for a single file, a styled, and
non-styled entry. The `ensure` function would then place the
correct cache entry into the last position so that
`get_source_lines` would use the correct entry, or
2. Have `ensure` recalculate entries if the required styling mode is
different to the styling mode of the current entry.
Approach #1 is better if we are rapidly switching between styling
modes, while #2 might be better if we want to keep more files in the
cache and we only rarely switch styling modes.
In the end I chose approach #2, but the good thing is that the changes
are all contained within the `ensure` function. If in the future we
wanted to change to strategy #1, this could be done transparently to
the rest of GDB.
So after this commit, the `ensure` function checks if styling is
currently possible or not. If it is not, and the current entry is
styled, then the current entry only is dropped from the cache, and a
new, unstyled entry is created. Likewise, if the current entry is
non-styled, but styling is required, we drop one entry and
recalculate.
With this change in place, I have updated set_style_enabled (in
cli/cli-style.c) so the source cache is no longer flushed when the
style settings are changed, the source cache will automatically handle
changes to the style settings now.
This problem was discovered in PR gdb/32676.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix two typos in gdb.threads/infcall-from-bp-cond-simple.exp.
|
|
While investigating PR32785 I noticed a missing return statement in
worker_func, and compiling with -Wreturn-type showed another in
function_that_segfaults:
...
$ gcc gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c -Wreturn-type
infcall-from-bp-cond-simple.c: In function ‘function_that_segfaults’:
infcall-from-bp-cond-simple.c:46:1: warning: \
control reaches end of non-void function [-Wreturn-type]
46 | }
| ^
infcall-from-bp-cond-simple.c: In function ‘worker_func’:
infcall-from-bp-cond-simple.c:58:1: warning: \
control reaches end of non-void function [-Wreturn-type]
58 | }
| ^
...
Fix these by adding the missing returns.
|
|
This commit changes type_to_type_object() so that each it is called
with a particular struct type * it returns the very same gdb.Type
object.
This is done in the same way as for gdb.Symtab objects in earlier commit
("gdb/python: preserve identity for gdb.Symtab objects") except that
types may be either objfile-owned or arch-owned.
Prior this commit, arch-owned objects we not put into any list (like
objfile-owned ones) so they could not be easily looked up. This commit
changes the code so arch-owned list are put into per-architecture list
which is then used (solely) for looking up arch-owned gdb.Type.
Another complication comes from the fact that when objfile is about to
be freed, associated gdb.Type instances are not merely invalidated
(like it is done with gdb.Symtab or gdb.Symbol objects) but instead the
type is copied and the copy is arch-owned. So we need two different
"deleters", one for objfile-owned types that copies the type (as before)
and then insert the object to per-architecture list and another one
for arch-owned types.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit changes symtab_to_symtab_object() so that each it is called
with a particular struct symtab * it returns the very same gdb.Symtab
object.
This is done by searching per-objfile linked list of instances and - if
found - return it rather than creating new gdb.Symtab.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, gdb.execute emits styled output when the command is sending
its output to GDB's stdout, and produces unstyled output when the
output is going to a string.
But it is not unreasonable that a user might wish to capture styled
output from a gdb.execute call, for example, the user might want to
display the styled output are part of some larger UI output block.
At the same time, I don't think it makes sense to always produce
styled output when capturing the output in a string; if what the user
wants is to parse the output, then the style escape sequences make
this far harder.
I propose that gdb.execute gain a new argument 'styling'. When False
we would always produce unstyled output, and when True we would
produce styled output if styling is not disabled by some other means.
For example, if GDB's 'set style enabled' is off, then I think
gdb.execute() should respect that. My assumption here is that
gdb.execute() might be executed by some extension. If the extension
thinks "styled output world work here", but the user hates styled
output, and has turned it off, then the extension should not be
forcing styled output on the user.
I chose 'styling' instead of 'styled' as the Python argument name
because we already use 'styling' in gdb.Value.format_string, and we
don't use 'styled' anywhere else. This is only a little bit of
consistency, but I still think it's a good thing.
The default for 'styling' will change depending on where the output is
going. When gdb.execute is sending the output to GDB's stdout then
the default for 'styling' is True. When the output is going to a
string, then the default for 'styling' will be False. Not only does
this match the existing behaviour, but I think this makes sense. By
default we assume that output captured in a string is going to be
parsed, and therefore styling markup is unhelpful, while output going
to stdout should receive styling.
This fixes part of the problem described in PR gdb/32676. That bug
tries to capture styled source listing in a string, which wasn't
previously possible.
There are some additional issues with capturing source code; GDB
caches the source code in the source code cache. However, GDB doesn't
check if the cached content is styled or not. As a consequence, if
the first time the source of a file is shown it is unstyled, then the
cached will hold the unstyled source code, and future requests will
return that unstyled source. I'll address this issue in a separate
patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On arm-linux, I run into:
...
gdb compile failed, ld: warning: enum_cond.o uses variable-size enums yet \
the output is to use 32-bit enums; use of enum values across objects may fail
UNTESTED: gdb.base/enum_cond.exp: failed to compile
...
Fix this by using -nostdlib.
Tested on arm-linux and x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In the commit:
commit 0df62bf09ecf242e3a932255d24ee54407b3c593
Date: Fri Oct 22 07:19:33 2021 +0000
gdb: Support some escaping of args with startup-with-shell being off
nat/fork-inferior.c was updated such that when we are starting an
inferior without a shell we now remove escape characters. The
benefits of this are explained in that commit, but having made this
change we can now make an additional change.
Currently, in construct_inferior_arguments, when startup_with_shell is
false we construct the inferior argument string differently than when
startup_with_shell is true; when true we apply some escaping to
special shell character, when false we don't.
This commit simplifies construct_inferior_arguments by removing the
!startup_with_shell case, and instead we now apply escaping in all
cases. This is fine because, thanks to the above commit the escaping
will be correctly removed again when we call into nat/fork-inferior.c.
We should think of construct_inferior_arguments and
nat/fork-inferior.c as needing to cooperate in order for argument
handling to work correctly.
construct_inferior_arguments converts a list of separate arguments
into a single string, and nat/fork-inferior.c splits that single
string back into a list of arguments. It is critical that, if
nat/fork-inferior.c is expecting to remove a "layer" of escapes, then
construct_inferior_arguments must add that expected "layer",
otherwise, we end up stripping more escapes than expected.
The great thing (I think) about the new configuration, is that GDB no
longer cares about startup_with_shell at the point the arguments are
being setup. We only care about startup_with_shell at the point that
the inferior is started. This means that a user can set the inferior
arguments, and then change the startup-with-shell setting, and GDB
will do what they expect.
Under the previous system, where construct_inferior_arguments changed
its behaviour based on startup_with_shell, the user had to change the
setting, and then set the arguments, otherwise, GDB might not do what
they expect.
There is one slight issue with this commit though, which will be
addressed by the next commit.
For GDB's native targets construct_inferior_arguments is reached via
two code paths; first when GDB starts and we combine arguments from
the command line, and second when the Python API is used to set the
arguments from a sequence. It's the command line argument handling
which we are interested in.
Consider this:
$ gdb --args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "\$FOO".
Notice that the argument has become \$FOO, the '$' is now quoted.
This is because, by quoting the argument in the shell command that
started GDB, GDB was passed a literal $FOO with no quotes. In order
to ensure that the inferior sees this same value, GDB added the extra
escape character. When GDB starts with a shell we pass \$FOO, which
results in the inferior seeing a literal $FOO.
But what if the user _actually_ wanted to have the shell GDB uses to
start the inferior expand $FOO? Well, it appears this can't be done
from the command line, but from the GDB prompt we can just do:
(gdb) set args $FOO
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
And now the inferior will see the shell expanded version of $FOO.
It might seem like we cannot achieve the same result from the GDB
command line, however, it is possible with this trick:
$ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
(gdb) show startup-with-shell
Use of shell to start subprocesses is off.
And now the $FOO is not escaped, but GDB is no longer using a shell to
start the inferior, however, we can extend our command line like this:
$ gdb -eiex 'set startup-with-shell off' \
-ex 'set startup-with-shell on' \
--args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
(gdb) show startup-with-shell
Use of shell to start subprocesses is on.
Use an early-initialisation option to disable startup-with-shell, this
is done before command line argument processing, then a normal
initialisation option turns startup-with-shell back on after GDB has
processed the command line arguments!
Is this useful? Yes, absolutely. Is this a good user experience?
Absolutely not. And I plan to add a new command line option to
GDB (and gdbserver) that will allow users to achieve the same
result (this trick doesn't work in gdbserver as there's no
early-initialisation there) without having to toggle the
startup-with-shell option. The new option can be found in the series
here:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
The problem is that, that series is pretty long, and getting it
reviewed is just not possible. So instead I'm posting the individual
patches in smaller blocks, to make reviews easier.
So, what's the problem? Well, by removing the !startup_with_shell
code path from GDB, there is no longer a construct_inferior_arguments
code path that doesn't quote inferior arguments, and so there's no
longer a way, from the command line, to set an unquoted '$FOO' as an
inferior argument. Obviously, this can still be done from GDB's CLI
prompt.
The trick above is completely untested, so this regression isn't going
to show up in the testsuite.
And the breakage is only temporary. In the next commit I'll add a fix
which restores the above trick.
Of course, I hope that this fix will itself, only be temporary. Once
the new command line options that I mentioned above are added, then
the fix I add in the next commit can be removed, and user should start
using the new command line option.
After this commit a whole set of tests that were added as xfail in the
above commit are now passing.
A change similar to this one can be found in this series:
https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
which I reviewed before writing this patch. I don't think there's any
one patch in that series that exactly corresponds with this patch
though, so I've listed the author of the original series as co-author
on this patch.
Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
I found another Ada test where LLVM optimizes away an unused local
variable. This patch fixes this problem -- but note the test now
fails for a different (currently expected) reason.
|
|
I noticed that it was not possible to return a string containing non
utf-8 characters using gdb.execute(). For example, using the binary
from the gdb.python/py-source-styling.exp test:
(gdb) file ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling
Reading symbols from ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling...
(gdb) set style enabled off
(gdb) list 26
21 int some_variable = 1234;
22
23 /* The following line contains a character that is non-utf-8. This is a
24 critical part of the test as Python 3 can't convert this into a string
25 using its default mechanism. */
26 char c[] = "�"; /* List this line. */
27
28 return 0;
29 }
(gdb) python print(gdb.execute('list 26', to_string=True))
Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte
Error occurred in Python: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte
It is necessary to disable styling before the initial 'list 26',
otherwise the source will be passed through GNU source highlight, and
GNU source highlight seems to be smart enough to figure out the
character encoding, and convert it to UTF-8. This conversion is then
cached in the source cache, and the later Python gdb.execute call will
get back a pure UTF-8 string.
If source styling is disabled, then GDB caches the string without the
conversion to UTF-8, now the gdb.execute call gets back the string
with a non-UTF-8 character within it, and Python throws an error
during its attempt to create a string object.
I'm not, at this point, proposing a solution that tries to guess the
source file encoding, though I guess such a thing could be done.
Instead, I think we should make use of the host_charset(), as set by
the user with 'set host-charset ....' during the creation of the
Python string.
To do this, in execute_gdb_command, we should switch from
PyUnicode_FromString, which requires the input be a UTF-8 string, to
using PyUnicode_Decode, which allows GDB to specify the string
encoding. We will use host_charset().
With this done, it is now possible to list the file contents using
gdb.execute(), with the contents passing through a string:
(gdb) set host-charset ISO-8859-1
(gdb) python print(gdb.execute('list 26', to_string=True), end='')
21 int some_variable = 1234;
22
23 /* The following line contains a character that is non-utf-8. This is a
24 critical part of the test as Python 3 can't convert this into a string
25 using its default mechanism. */
26 char c[] = "À"; /* List this line. */
27
28 return 0;
29 }
(gdb)
There are already plenty of other places in GDB's Python code where we
use PyUnicode_Decode to create a string from something that might
contain user generated content, so I believe this is the correct
approach.
|
|
Commit:
commit be382ece165eefa3e65f61bfb6b2aa2ee95dd6b4
Date: Wed Feb 12 09:35:26 2025 -0700
Check for compiler support in scalar_storage.exp
Introduced an undefined variable use in gdb.ada/scalar_storage.exp,
fixed by this commit.
|
|
On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:
$ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"
I think I stumble on this bug [1], preventing to do the
disassembling that the test needs:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
Reading symbols from testsuite/outputs/gdb.base/style/style...
(gdb) x/1i *main
DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
(gdb)
The regexp in get_single_disassembled_insn fails to match, the insn
variable doesn't get set, and we get one of those unreadable TCL stack
traces:
ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/style.exp.
ERROR: tcl error code TCL READ VARNAME
ERROR: can't read "insn": no such variable
while executing
"return $insn"
(procedure "get_single_disassembled_insn" line 4)
invoked from within
"get_single_disassembled_insn"
("uplevel" body line 18)
invoked from within
"uplevel 1 $body"
invoked from within
...
Check the return value of the regexp call, return an empty string on
failure. Log a failure, so that we have a trace that something went
wrong, in case the tests done by the caller happen to pass by change.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Change-Id: I5123d4cc0034da85a093a8531a22e972c10d94ca
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On openSUSE Tumbleweed, with glibc 2.41, when running test-case
gdb.base/step-over-syscall.exp I run into:
...
(gdb) stepi^M
0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M
1: x/i $pc^M
=> 0x7ffff7cfd09b <__abort_lock_rdlock+29>: syscall^M
(gdb) p $eax^M
$1 = 14^M
(gdb) FAIL: $exp: fork: displaced=off: syscall number matches
FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout)
...
We're stepi-ing through fork trying to find the fork syscall, but encounter
another syscall.
The test-case attempts to handle this:
...
gdb_test_multiple "stepi" "find syscall insn in $syscall" {
-re ".*$syscall_insn.*$gdb_prompt $" {
# Is the syscall number the correct one?
if {[syscall_number_matches $syscall]} {
pass $gdb_test_name
} else {
exp_continue
}
}
-re "x/i .*=>.*\r\n$gdb_prompt $" {
incr steps
if {$steps == $max_steps} {
fail $gdb_test_name
} else {
send_gdb "stepi\n"
exp_continue
}
}
}
...
but fails to do so because it issues an exp_continue without issuing a new
stepi command, and consequently the "find syscall insn in fork" test times
out.
Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping
one syscall would produce:
...
FAIL: $exp: fork: displaced=off: syscall number matches
PASS: $exp: fork: displaced=off: syscall number matches
DUPLICATE: $exp: fork: displaced=off: syscall number matches
...
Fix this by:
- not producing PASS or FAIL in syscall_number_matches, and
- issuing stepi when encountering another syscall.
While we're at it, fix indentation in syscall_number_matches.
Tested on x86_64-linux, specifically:
- openSUSE Tumbleweed (glibc 2.41), and
- openSUSE Leap 15.6 (glibc 2.38).
PR testsuite/32780
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32780
|
|
The new gcore-memory-usage.exp test puts a PID into a test case name,
causing spurious comparison failures. This patch changes the test
name to avoid this.
|
|
I accidentally pushed my work-in-progress branch... revert that. Sorry
for the noise :(.
The list of commits reverted are:
ae2a50a9ae15 attempt to revamp to the CU/TU list
e9386435c94f gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"
6cbd64aa3eb0 gdb/dwarf: add dwarf_source_language_name
32a187da7622 libiberty: move DW_LANG_* definitions to dwarf2.def
b3fa38aef59d gdb/dwarf: move index unit vectors to debug names reader and use them
30ba74418982 gdb/dwarf: track comp and type units count
bedb4e09f292 gdb/dwarf: remove unnecessary braces
b4f18de12c77 gdb/dwarf: use ranged for loop in some pots
Change-Id: I80aed2847025f5b15c16c997680783b39858a703
|
|
Change-Id: I1c8214413583d540c10c9a2322ef2a21f8bb54e7
|
|
When running test-case gdb.base/step-over-syscall.exp with target board
unix/-m32 on an AMD processor, I run into:
...
(gdb) x/2i $pc^M
=> 0xf7fc9575 <__kernel_vsyscall+5>: syscall^M
0xf7fc9577 <__kernel_vsyscall+7>: int $0x80^M
(gdb) PASS: $exp: fork: displaced=off: pc before/after syscall instruction
stepi^M
[Detaching after fork from child process 65650]^M
0xf7fc9579 in __kernel_vsyscall ()^M
1: x/i $pc^M
=> 0xf7fc9579 <__kernel_vsyscall+9>: pop %ebp^M
(gdb) $exp: fork: displaced=off: stepi fork insn
print /x $pc^M
$2 = 0xf7fc9579^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi
FAIL: $exp: fork: displaced=off: pc after stepi matches insn addr after syscall
...
The problem is that the syscall returns at the "pop %ebp" insn, while the
test-case expects it to return at the "int $0x80" insn.
This is similar to the problem I fixed in commit 14852123287 ("[gdb/testsuite]
Fix gdb.base/step-over-syscall.exp with -m32"), just that the syscall sequence
used there used the "sysenter" insn instead of the "syscall" insn.
Fix this by extending the fix for commit 14852123287 to also handle the
"syscall" insn.
Tested on x86_64-linux, both using an AMD and Intel processor.
PR testsuite/32439
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32439
|
|
PR symtab/31010 points out that something like "ptype INT" will expand
all CUs in a typical program. The OP further points out that the
original patch for PR symtab/30520:
https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html
... did solve the problem, but the patch changed after (my) review and
reintroduced the bug.
In cooked_index_functions::expand_symtabs_matching, the final
component of a split name is compared with the entry's name using the
usual method of calling get_symbol_name_matcher.
This code iterates over languages and tries to split the original name
according to each style. But, the Ada splitter uses the decoded name
-- "int". This causes every C or C++ CU to be expanded.
Clearly this is wrong. And, it seems to me that looping over
languages and trying to guess the splitting style for the input text
is probably bad. However, fixing the problem is not so easy (again
due to Ada). I've filed a follow-up bug, PR symtab/32733, for this.
Meanwhile, this patch changes the code to be closer to the
originally-submitted patch. This works because the comparison is now
done between the full name and the "lookup_name_without_params"
object, which is a less adulterated variant of the original input.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31010
Tested-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch applies a few fixes to gdb.ada/fun_overload_menu.exp.
It adds some comments to the source and uses this to extract line
numbers. This is used to ensure that two otherwise-equivalent results
are in fact different, so that the test really checks that the result
is correct.
It also changes the test_menu proc to accept a list of possible
results. This lets the test work regardless of the order in which the
menu items are presented by gdb.
Finally, like an earlier patch, it changes the test to optionally
accept unqualified names from gdb.
|
|
With some forthcoming changes to GNAT, the two Get_Value functions in
this test case will end up with the same name (with the current GNAT,
one ends up with a "__2" suffix). This change will cause one test to
set multiple breakpoints; this patch changes the test to work with
either version of the compiler.
|
|
The "Rec" type in ptype-o.exp is currently named "prog__rec" by the
compiler. However, with my changes to GNAT, the type will no longer
have a prefix, as it is local to a procedure.
Changing this to just use "rec" works fine with the new compiler, but
then fails with older compilers. To allow correct operation with both
compilers, this patch simply moves the type into a new package. This
doesn't affect the meaning of the test, which is just ensuring that
ptype/o works in a certain case.
Note that the more obvious fix of just using "ptype/o rec" does not
work with the current GNAT. I haven't investigated this but I did
file a bug to track it:
https://sourceware.org/bugzilla/show_bug.cgi?id=32169
|
|
Currently, when a type is declared in a subprogram that isn't part of
a package, gdb will give this type a qualified name. E.g., in the
program for gdb.ada/arr_arr.exp:
procedure Foo is
type Array2_First is array (24 .. 26) of Integer;
gdb will name this type 'foo.array2_first'.
However, with some coming changes to GNAT (and with the remainder of
this series applied as well), this will no longer happen. Instead,
such types will be given their local name. IMO this makes more sense
anyway.
This patch updates most of the Ada tests to allow either form in the
spots where it matters. Both are accepted so that the tests continue
to work with older versions of GNAT. (A few tests are handled in
separate patches; this patch only contains the straightforward
changes.)
|
|
For a long time, Fedora has been carrying an out-of-tree patch with a
similar test to the one proposed in this patch, that ensures that the
memory requirements don't grow with the inferior's memory. It's been
so long that the context for why this test exists has been lost, but
it looked like it could be interesting for upstream.
The test runs twice, once with the inferior allocating 4Mb of memory,
and the other allocating 64Mb. My plan was to find the rate at which
things increase based on inferior size, and have that tested to ensure
we're not growing that requirement accidentally, but my testing
actually showed memory requirements going down as the inferior increases,
so instead I just hardcoded that we need less than 2Mb for the command,
and it can be tweaked later if necessary.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that if you hack some clean_restart calls into
paramless.exp, the test will fail. That is, the test currently relies
on the desired CUs already being expanded when trying to set a
breakpoint -- which is clearly a bug, the CU expansion state should
not affect "break".
I tracked this down to incorrect construction of a lookup_name_info in
cooked_index_functions::expand_symtabs_matching.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32510
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Currently, gnat-llvm does not ship a shared libgnat. This patch
changes the relevant test to check whether linking with -shared
actually works.
|
|
gnat-llvm does not support the -Og flag. This arranges to check for
this flag before using it.
|
|
gnat-llvm does not support the -fgnat-encodings option, and does not
emit GNAT encodings at all -- it only supports the equivalent of GCC's
"minimal" encodings; which is to say, ordinary DWARF.
This patch changes gdb to test whether gnatmake supports this flag and
adapt accordingly. foreach_gnat_encoding is changed to pretend that
the "minimal" mode is in effect, as some test examine the mode.
|
|
A couple of Ada tests check whether the C compiler supports
-fvar-tracking. However, this doesn't really work when using
gnat-llvm, because that will invoke clang under the hood. This patch
arranges to check gnatmake instead, which is more robust even when
toolchains are mix-and-matched.
|
|
This introduces ada_simple_compile, an Ada-specific analog of
gdb_simple_compile. gdb_compile_test is split into two procs to make
this possible. ada_simple_compile isn't used in this patch but will
be by later patches in this series.
|
|
gnat-llvm does not currently handle Scalar_Storage_Order. This patch
changes the scalar_storage.exp test to check the compiler error
messages and report "unsupported" in this case. This way, the test
ought to start working automatically if this feature is added to
gnat-llvm.
|
|
I think debug-names-tu.exp.tcl only passes by accident -- the type
unit does not have a language, which gdb essentially requires.
This isn't noticeable right now because the type unit in question is
expanded in one phase and then the symbol found in another. However,
I'm working on a series that would regress this.
This patch partially fixes the problem by correcting the test case,
adding the language to the TU.
Hoewver, it then goes a bit further and arranges for this information
not to be written to .debug_names. Whether or not a type should be
considered "static" seems like something that is purely internal to
gdb, so this patch has the entry-creation function apply the
appropriate transform.
It also may make sense to change the "debug_names" proc in the test
suite to process attributes more like the ordinary "cu" proc does.
|
|
On aarch64-linux, in test-case gdb.base/nostdlib.exp I run into:
...
(gdb) continue^M
Continuing.^M
warning: Temporarily disabling breakpoints for unloaded shared library \
"/lib/ld-linux-aarch64.so.1"^M
^M
Breakpoint 2, _start () at nostdlib.c:20^M
20 {^M
(gdb) FAIL: $exp: pie=pie: continue to marker
...
This happens as follows:
- the test-case sets a breakpoint on *_start,
- the breakpoint resolves to *_start in the executable,
- the executable is started, and the breakpoint resolves to *_start in the
dynamic linker,
- execution stops at *_start in the dynamic linker,
- the test-case issues a continue, expecting to continue to the breakpoint on
marker,
- while continuing, the dynamic linker is reported as unloaded,
- the breakpoint again resolves to *_start in the executable,
- execution stops at *_start in the executable, and
- the test-case concludes that it failed to "continue to marker".
This doesn't happen on x86_64-linux. There, after the executable is started,
the breakpoint again resolves to *_start in the exec.
This is similar to what happens when printing _start.
On aarch64-linux, we print the _start in the dynamic linker:
...
$ gdb -q -batch outputs/gdb.base/nostdlib/nostdlib-pie \
-ex "b _start" \
-ex run \
-ex "print _start" \
-ex "info break"
Breakpoint 1 at 0x2bc: file nostdlib.c, line 23.
Breakpoint 1.2, _start () at ../sysdeps/aarch64/dl-start.S:22
22 ENTRY (_start)
$1 = {void (void)} 0xfffff7fd6ac0 <_start>
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x0000aaaaaaaa02bc in _start at nostdlib.c:23
1.2 y 0x0000fffff7fd6ac0 in _start at dl-start.S:22
...
On x86_64-linux, we print the _start in the exec:
...
Breakpoint 1 at 0x2c5: file nostdlib.c, line 23.
Breakpoint 1.2, 0x00007ffff7fe4f00 in _start () from \
/lib64/ld-linux-x86-64.so.2
$1 = {void (void)} 0x5555555542c1 <_start>
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x00005555555542c5 in _start at nostdlib.c:23
1.2 y 0x00007ffff7fe4f00 <_start>
...
The difference may be down to the availability of debug info for the _start in
the dynamic linker.
Finally, the described scenario on aarch64-linux is not deterministic. The
behavior depends on the dynamic linker being reported as unloaded, which has
been classified as a GLIBC bug, so that might get fixed.
Ideally this test-case would stop at both *_start in the executable and the
dynamic linker, but in absense of a way to specify this reliably (see PR32748),
fix this by making this a temporary breakpoint, ensuring that the breakpoint
will only trigger once.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/32743
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32743
|
|
I noticed a
// namespace selftests
comment, which doesn't follow our comment formatting convention. I did
a find & replace to fix all the offenders.
Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c
|
|
Implement the target_ops displaced stepping methods to add displaced
stepping support when debugging AMD GPU programs. The knowledge of how
to prepare and finish displaced steps is provided by the amd-dbgapi
library, so the code here is relatively straightforward. No need to
parse instructions or handle fixups, that is done by the lib We just
need to remember, for each thread doing a displaced step, the displaced
stepping id given by the library.
Add a test to exercise the new functionality. The compiler generates
DWARF that GDB doesn't understand yet [1], so trying to step over a
breakpoint with DWARF present gives:
(gdb) si
Unhandled dwarf expression opcode 0xe9
The test purposefully builds the binary without DWARF info to circumvent
this.
[1] https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
Change-Id: I53f459221a42d4b02a6041eadb8cf554500e2162
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
|
|
Consider the test-case sources main.c and foo.c:
$ cat main.c
extern int foo (void);
int
main (void)
{
return foo ();
}
$ cat foo.c
extern int foo (void);
int
foo (void)
{
return 0;
}
and main.c compiled with debug info, and foo.c without:
$ gcc -g main.c -c
$ gcc foo.c -c
$ gcc -g main.o foo.o
In TUI mode, if we run to foo:
$ gdb -q a.out -tui -ex "b foo" -ex run
it gets us "[ No Source Available ]":
┌─main.c─────────────────────────────────────────┐
│ │
│ │
│ │
│ [ No Source Available ] │
│ │
│ │
└────────────────────────────────────────────────┘
(src) In: foo L?? PC: 0x400566
...
Breakpoint 1, 0x0000000000400566 in foo ()
(gdb)
But after resizing (pressing ctrl-<minus> in the gnome-terminal), we
get instead the source for main.c:
┌─main.c─────────────────────────────────────────┐
│ 3 int │
│ 4 main (void) │
│ 5 { │
│ 6 return foo (); │
│ 7 } │
│ │
│ │
└────────────────────────────────────────────────┘
(src) In: foo L?? PC: 0x400566
...
Breakpoint 1, 0x0000000000400566 in foo ()
(gdb)
which is inappropriate because we're stopped in function foo, which is
not in main.c.
The problem is that, when the window is resized, GDB ends up calling
tui_source_window_base::rerender. The rerender function has three
cases, one for when the window already has some source code
content (which is not the case here), a case for when the inferior is
active, and we have a selected frame (which is the case that applies
here), and a final case for when the inferior is not running.
For the case which we end up in, the source code window has no
content, but the inferior is running, so we have a selected frame, GDB
calls the get_current_source_symtab_and_line() function to get the
symtab_and_line for the current location.
The get_current_source_symtab_and_line() will actually return the last
recorded symtab and line location, not the current symtab and line
location.
What this means, is that, if the current location has no debug
information, get_current_source_symtab_and_line() will return any
previously recorded location, or failing that, the default (main)
location.
This behaviour of get_current_source_symtab_and_line() also causes
problems for the 'list' command. Consider this pure CLI session:
(gdb) break foo
Breakpoint 1 at 0x40110a
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, 0x000000000040110a in foo ()
(gdb) list
1 extern int foo (void);
2
3 int
4 main (void)
5 {
6 return foo ();
7 }
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x40110a).
(gdb)
However, if we look at how GDB's TUI updates the source window during
a normal stop, we see that GDB does a better job of displaying the
expected contents. Going back to our original example, when we start
GDB with:
$ gdb -q a.out -tui -ex "b foo" -ex run
we do get the "[ No Source Available ]" message as expected. Why is
that?
The answer is that, in this case GDB uses tui_show_frame_info to
update the source window, tui_show_frame_info is called each time a
prompt is displayed, like this:
#0 tui_show_frame_info (fi=...) at ../../src/gdb/tui/tui-status.c:269
#1 0x0000000000f55975 in tui_refresh_frame_and_register_information () at ../../src/gdb/tui/tui-hooks.c:118
#2 0x0000000000f55ae8 in tui_before_prompt (current_gdb_prompt=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/tui/tui-hooks.c:165
#3 0x000000000090ea45 in std::_Function_handler<void(char const*), void (*)(char const*)>::_M_invoke (__functor=..., __args#0=@0x7ffc955106b0: 0x31ef930 <top_prompt+16> "(gdb) ") at /usr/include/c++/9/bits/std_function.h:300
#4 0x00000000009020df in std::function<void(char const*)>::operator() (this=0x5281260, __args#0=0x31ef930 <top_prompt+16> "(gdb) ") at /usr/include/c++/9/bits/std_function.h:688
#5 0x0000000000901c35 in gdb::observers::observable<char const*>::notify (this=0x31dda00 <gdb::observers::before_prompt>, args#0=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/../gdbsupport/observable.h:166
#6 0x00000000008ffed8 in notify_before_prompt (prompt=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/event-top.c:518
#7 0x00000000008fff08 in top_level_prompt () at ../../src/gdb/event-top.c:534
#8 0x00000000008ffdeb in display_gdb_prompt (new_prompt=0x0) at ../../src/gdb/event-top.c:487
If we look at how tui_show_frame_info figures out what source to
display, it doesn't use get_current_source_symtab_and_line(), instead,
it finds a symtab_and_line directly from a frame_info_pt. This means
we are not dependent on get_current_source_symtab_and_line() returning
the current location (which it does not).
I propose that we change tui_source_window_base::rerender() so that,
for the case we are discussing here (the inferior has a selected
frame, but the source window has no contents), we move away from using
get_current_source_symtab_and_line(), and instead use find_frame_sal
instead, like tui_show_frame_info does.
This means that we will always use the inferior's current location.
Tested on x86_64-linux.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reported-By: Andrew Burgess <aburgess@redhat.com>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32614
|
|
After test-case gdb.mi/mi-break.exp, a gdb instance is left running.
The test-case starts two instances using mi_clean_restart, one using
separate-mi-tty.
For each instance, gdb_exit is called once, from two different locations:
- mi_clean_restart, and
- gdb_finish.
But this doesn't seem to be effective for the separate-mi-tty case.
Fix this by calling gdb_mi_exit at the end of proc test_break.
Likewise in a few more more test-case.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32709
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709
|
|
We currently check the TERM environment variable any time we call one
of the ui_file::can_emit_style_escape() functions. This seems
excessive.
During GDB's startup we also check for the NO_COLOR environment
variable and disable styling if this is set.
I propose that we combine these two checks, and perform them just once
during startup (as the current NO_COLOR check is currently done). As
with the NO_COLOR check, if the TERM variable is set to "dumb"
indicating that styling is not supported then we should just set
cli_styling to false.
This does mean that the user can then 'set style enabled on', even for
a dumb terminal, which was not possible previously. Before this
commit the "dumb" terminal check was separate and would prevent
styling even if 'set style enabled on' was in effect.
Of course, trying to turn on styling in a dumb terminal might not give
the results that a user hope for. And so, I have implemented a check
in `set_style_enabled`, so in a dumb terminal a user will see this:
(gdb) set style enabled on
warning: The current terminal doesn't support styling. Styled output might not appear as expected.
After which GDB will try to emit styling. We could, potentially,
prevent styling being enabled instead of emitting a warning, but I'm
inclined to let the user turn on styling if they really want to.
Approved-By: Kevin Buettner <kevinb@redhat.com>
Acked-By: Tom Tromey <tom@tromey.com>
|
|
Currently the TUI's asm window uses `source_styling` to control
styling. This setting is supposed to be for styling of source files
though, and the asm window displays disassembler output.
We have a different setting for this `disassemble_styling`, which is
controlled with 'set style disassembler enabled on|off'.
Switch to use the correct control variable.
I've written a new test for this, but this required some additions to
the tuiterm library in order to grab character attributes for a screen
region.
Approved-By: Tom Tromey <tom@tromey.com>
|
