| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently, gdbserver has the following command line options related to
debugging output:
--debug
--remote-debug
--event-loop-debug
This doesn't scale well. If I want an extra debug component I need to
add another command line flag.
This commit changes --debug to take a list of components.
The currently supported components are: all, threads, remote, and
event-loop. The 'threads' component represents the debug we currently
get from the --debug option. And if --debug is used without a
component list then the threads component is assumed as the default.
Currently the threads component actually includes a lot of output that
is not really threads related. In the future I'd like to split this
up into some new, separate components. But that is not part of this
commit, or even this series.
The special component 'all' does what you'd expect: enables debug
output from all supported components.
The component list is parsed left to write, and you can prefix a
component with '-' to disable that component, so I can write:
target> gdbserver --debug=all,-event-loop
to get debug for all components except the event-loop component.
I've removed the existing --remote-debug and --event-loop-debug
command line options, these are equivalent to --debug=remote and
--debug=event-loop respectively, or --debug=remote,event-loop to
enable both components.
In this commit I've only update the command line options, in the next
commit I'll update the monitor commands to support a similar
interface.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
flags, which can be passed to make in order to enable debugging within
GDB or gdbserver respectively.
However, when I do:
make check-gdb GDB_DEBUG=infrun
I don't see the corresponding debug feature within GDB being enabled.
Nor does:
make check-gdb GDBSERVER_DEBUG=debug \
RUNTESTFLAGS="--target_board=native-extended-gdbserver"
Appear to enable gdbserver debugging.
I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This
variable already contains lots of testing related flags, like
RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
GDBSERVER_DEBUG here too.
With this done, this debug feature is now working as expected.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR29079 shows that pretty printers can be used for an incomplete
type (stub), but only when printing it directly, not if it's
part of another struct:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = <incomplete type>, m_l = 20}
```
The reason is simply that in common_val_print the check for stubs
is before any pretty printer is tried.
It works if the pretty printer is tried before the stub check:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = {pp m_i = 10}, m_l = 20}
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A TUI src window is displaying either:
- the source for the current frame,
- the source for main, or
- the string "[ No Source Available ]".
Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
we're able to resize the TUI to 1 line without crashing.
I noticed that if TUI is displaying main, and we resize to 1 line (destroying
the src window) and then back to a larger terminal (reconstructing the src
window), the TUI displays "[ No Source Available ]" instead of main.
Fix this by moving the responsibility for showing main from tui_enable to
tui_source_window_base::rerender.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR rust/31082 points out that casting a 128-bit integer to a pointer
will fail. This happens because a case in value_cast was not
converted to use GMP.
This patch fixes the problem. I am not really sure that testing
against the negative value here makes sense, but I opted to just
preserve the existing behavior rather than change it.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31082
|
|
PR rust/31005 points out that dynamic type resolution of a LOC_CONST
or LOC_CONST_BYTES symbol will fail, leading to output like:
from_index=<error reading variable: Cannot access memory at address 0x0>
This patch fixes the problem by using the constant value or bytes when
performing type resolution.
Thanks to tpzker@thepuzzlemaker.info for a first version of this
patch.
I also tested this on a big-endian PPC system (cfarm203).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005
|
|
When examining a failure that happens when testing
gdb.python/py-symtab.c with clang, I noticed that it was going wrong
because the test assumed that whenever we get an SAL, its end would
always be right before statement in the line table. This is true for GCC
compiled binaries, since gcc only adds statements to the line table, but
not true for clang compiled binaries.
This is the second time I run into a problem where GDB doesn't handle
non-statement line table entries correctly. The other was eventually
committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until
behavior with trailing !is_stmt lines", but that commit only changes the
behavior for the 'until' command. In this patch I propose a more general
solution, making it so every time we generate the SAL for a given pc, we
set the end of the SAL to before the next statement or the first
instruciton in the next line, instead of naively assuming that to be the
case.
With this new change, the edge case is removed from the processing of
the 'until' command without regressing the accompanying test case, and
no other regressions were observed in the testsuite.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We suppress the warning in the generated switch file because the cris
cpu file has a hack to workaround a cgen bug, but that generates a set
but unused variable which makes the compiler upset.
|
|
|
|
Rework the code to use static inline functions when it's disabled
rather than macros so the compiler knows the various function args
are always used. The ifdef macros are a bit ugly, but get the job
done without duplicating the function prototypes.
|
|
|
|
The function returns void, not int. We only pass one argument to
syslog (the format), so use %s as the static format instead since
the emulation layer doesn't handle passing additional arguments.
|
|
Not exactly portable, but doesn't make the situation worse here, and
fixes a lot of implicit function warnings.
Bug: https://sourceware.org/PR29752
|
|
The traps file uses a bunch of functions directly without prototypes,
and we can't safely include the relevant cpu*.h files for them.
|
|
|
|
|
|
The cgen code mixes virtual insn enums with insn enums, and there isn't
an obvious (to me) way to unravel this atm, so disable the warning.
sim/lm32/decode.c:45:5: error:
implicit conversion from enumeration type 'CGEN_INSN_VIRTUAL_TYPE'
to different enumeration type 'CGEN_INSN_TYPE' (aka 'enum cgen_insn_type')
[-Werror,-Wenum-conversion]
45 | { VIRTUAL_INSN_X_INVALID, LM32BF_INSN_X_INVALID, LM32BF_SFMT_EMPTY },
| ~ ^~~~~~~~~~~~~~~~~~~~~~
Bug: https://sourceware.org/PR29752
|
|
This patch adds support for process recording of the instruction rdtscp in
x86 architecture.
Debugging applications with "record full" fail to record with the error
message "Process record does not support instruction 0xf01f9".
Approved-by: Guinevere Larsen <blarsen@redhat.com>
|
|
Stop assuming that dlopen is only available via -ldl. Newer versions
of glibc have merged it into -lc which broke this configure test.
|
|
Not sure why this ended up in the topdir, but it belongs under cris/.
|
|
Sync with the list of flags from gdbsupport, and add a few more of
our own to catch recent issues. Comment out the C++-specific flags
as we don't build with C++.
|
|
The test gdb.base/watchpoint.exp has a proc named 'test_stepping'
which claims to "Test stepping and other mundane operations with
watchpoints enabled". It sets a watchpoint on ival2, performs an
inferior function call (which is not at all mundane), and uses 'next',
'until', and, finally, does a 'step'.
However, that final 'step' command steps to (but not over/through) the
line at which the assignment to ival2 takes place. At no time while
performing these operations is a watchpoint hit.
This commit adds a test to see what happens when stepping over/through
the assignment to ival2. The watchpoint on ival2 should be triggered
during this step. I've added another 'step' to make sure that the
correct statement is reached after performing the watchpoint-hitting
step.
After running the 'test_stepping' proc, gdb.base/watchpoint.exp does
a clean_restart before doing further tests, so nothing depends upon
'test_stepping' to stop at the particular statement at which it had
been stopping.
I've examined all tests which set watchpoints and step. I haven't
been able to identify a(nother) test case which tests what happens
when stepping over/through a statement which triggers a watchpoint.
Therefore, adding these new 'step' tests is testing something which
hasn't being tested elsewhere.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
This was split over multiple lines and ended up missing a space.
Reported-by: David Abdurachmanov <davidlt@rivosinc.com>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
|
|
I noticed it when I was trying to set a breakpoint at ExitProcess:
```
(gdb) b ExitProcess
Breakpoint 1 at 0x14001fdd0
(gdb) r
Starting program: C:\qiewer\heob\heob64.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x3dbf4120
Cannot insert breakpoint 1.
Cannot access memory at address 0x77644120
```
The problem doesn't exist in gdb 13.2, and the difference can easily be
seen when printing ExitProcess.
gdb 14.1:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
```
gdb 13.2:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
```
The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
relative to DLL_NAME before.
Fixed by calculating VMA relative to DLL_NAME again.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This fixes a small grammar issue in gdb.texinfo -- "additional" was
written where "additionally" is correct.
|
|
The only caller of quick_symbol_functions::expand_matching_symbols was
removed, so now this method and all implementations of it can be
removed.
|
|
The recent changes to the way Ada names are matched means that
split_style::UNDERSCORE is no longer used. This patch removes it.
|
|
The previous patch fixed the immediate performance problem with Ada
name matching, by having a subset of matches call
expand_symtabs_matching rather than expand_matching_symbols. However,
it seemed to me that expand_matching_symbols should not be needed at
all.
To achieve this, this patch changes ada_lookup_name_info::split_name
to use the decoded name, rather than the encoded name. In order to
make this work correctly, a new decoded form is used: one that does
not decode operators (this is already done) and also does not decode
wide characters. The latter change is done so that changes to the Ada
source charset don't affect the DWARF index.
With this in place, we can change ada-lang.c to always use
expand_symtabs_matching rather than expand_matching_symbols.
|
|
A user reported that certain operations -- like printing a large
structure -- could be slow. I tracked this down to
ada-lang.c:map_matching_symbols taking an inordinate amount of time.
Specifically, calls like the one to look for a parallel "__XVZ"
variable, in ada_to_fixed_type_1, could result in gdb walking over all
the entries in the cooked index over and over.
Looking into this reveals that
cooked_index_functions::expand_matching_symbols is not written
efficiently -- it ignores its "ordered_compare" parameter. While
fixing this would be good, it turns out that this entire method isn't
needed; so this series removes it.
However, the deletion is not done in this patch. This one, instead,
fixes the immediate cause of the slowdown, by using
objfile::expand_symtabs_matching when possible. This approach is
faster because it is more selective about which index entries to
examine.
|
|
I noticed that the DWARF assembler starts abbrevs at 2.
I think 1 should be preferred.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
|
|
Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597
caused a regression that meant hardware watchpoint stops would not
trigger in reverse execution or replay mode. This was documented in
PR breakpoints/21969.
The problem is that record_check_stopped_by_breakpoint always overwrites
record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT
value which would be checked afterwards.
This commit fixes that by not overwriting the stop-reason in
record_full_stop_reason if we're not stopped at a breakpoint.
And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually
tested sw watchpoints again, since "set can-use-hw-watchpoints 1"
doesn't convert enabled watchpoints to use hardware.
This is fixed by disabling said watchpoint while enabling hw watchpoints.
The same is not done for gdb.reverse/watch-precsave.exp, since it's not
possible to use hw watchpoints in restored recordings anyways.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21969
Approved-by: Guinevere Larsen <blarsen@redhat.com>
|
|
After this commit:
commit 33ae45434d0ab1f7de365b9140ad4e4ffc34b8a2
Date: Mon Dec 4 14:23:17 2023 +0000
gdb: Enable early init of thread pool size
I am now seeing this assert from libstdc++:
/usr/include/c++/9/bits/stl_algo.h:3715: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]: Assertion '!(__hi < __lo)' failed.
This may only be visible because I compile with:
-D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1
but I haven't checked. The issue the assert is highlighting is real,
and is caused by this block of code:
if (n_threads < 0)
{
const int hardware_threads = std::thread::hardware_concurrency ();
/* Testing in #29959 indicates that parallel efficiency drops between
n_threads=5 to 8. Therefore, clamp the default value to 8 to avoid an
excessive number of threads in the pool on many-core systems. */
const int throttle = 8;
n_threads = std::clamp (hardware_threads, hardware_threads, throttle);
}
The arguments to std::clamp are VALUE, LOW, HIGH, but in the above, if
we have more than 8 hardware threads available the LOW will be greater
than the HIGH, which is triggering the assert I see above.
I believe std::clamp is the wrong tool to use here. Instead std::min
would be a better choice; we want the smaller value of
HARDWARE_THREADS or THROTTLE. If h/w threads is 2, then we want 2,
but if h/w threads is 16 we want 8, this is what std::min gives us.
After this commit, I no longer see the assert.
|
|
This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due
to a regression reported in PR29572, and implements a different fix for PR29453.
The fix is to not use the CU table in a .debug_names section to construct
all_units, but instead use create_all_units, and then verify the CU
table from .debug_names. This also fixes PR25969, so remove the KFAIL.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969
|
|
This fixes testing of -Wno flags, and adds some more portable ones.
|
|
Prior to commit 0e3c1eebb2 nm output depended on the host unsigned
long when printing "negative" symbol values for 32-bit targets.
Commit 0e3c1eebb22 made the output match that seen with a 64-bit host
unsigned long. The fact that nm output changed depending on host is
of course a bug, but it is reasonable to expect 32-bit target output
is only 32 bits. So this patch makes 32-bit target output the same as
it was on 32-bit hosts prior to 0e3c1eebb2.
PR 31096
* nm.c (print_format_string): Make it a static buffer.
(get_print_format): Merge into..
(set_print_format): ..this, renamed from set_print_width. When
print_width is 32, set up print_format_string for an int32_t
value. Don't malloc print_format_string. Adjust calls.
(print_value): Correct printing of 32-bit values.
|
