Simon Marchi [Wed, 26 Feb 2025 16:52:32 +0000 (11:52 -0500)]
gdb/dwarf: fix failed assertion in dwarf2_find_containing_comp_unit selftest
Commit 2f0521c0d6f6 ("gdb/dwarf: fix signature_type created with nullptr
section") added some asserts in the dwarf2_per_cu_data constructor to
verify that the passed dwarf2_per_bfd and dwarf2_section_info are not
nullptr. However, the dummy dwarf2_per_cu_data objects created in the
dwarf2_find_containing_comp_unit selftests are passed nullptr for those
parameters.
I prefer to keep the asserts in place, as protection for the non-test
code and as self documentation, so fix this by passing some dummy
pointers in the test.
Change-Id: Ic7cdc1b976f7506041b651222234eefc998e473a Reviewed-By: Tom de Vries <tdevries@suse.de>
Simon Marchi [Wed, 26 Feb 2025 16:52:31 +0000 (11:52 -0500)]
gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor
Most of the time, the length of a unit is known when constructing a
dwarf2_per_cu_data or signatured_type. Add a construtor parameter for
it. In the few cases where it isn't, pass 0, which leaves it unset.
Change-Id: I0c8b9683164d3e3f3823ed995f71689a4d17fd96 Reviewed-By: Tom de Vries <tdevries@suse.de>
Indu Bhagat [Wed, 26 Feb 2025 21:50:49 +0000 (13:50 -0800)]
gas: sframe: partially process DWARF unwind info in CFI_escape
CFI_escape is most commonly used to include DWARF expressions in the
unwind information. One may also use CFI_escape to add OS-specific CFI
opcodes. Up until now, SFrame generation process would skip generating
SFrame FDE at the mere sight of a CFI_escape opcode.
Fine tune the handling of CFI_escape for SFrame generation by explicitly
checking for few "harmless" (in context of SFrame generation)
CFI_escape DWARF info:
- DW_CFA_expression affecting registers of no significance to SFrame
stack trace info
- DW_CFA_value_offset affecting registers of no significance to SFrame
stack trace info
Expose the current cfi_escape_data structure in dw2gencfi.c to the
relevant header file to allow SFrame generation APIs to use it too.
Valid unwind info may be split across multiple .cfi_escape directives.
Conversely, it is also allowed to simply put multiple DWARF expressions
and/or operations in a single .cfi_escape directive. Handling all of
these cases correctly will need parsing/processing that is not deemed
worth the effort in context of SFrame generation; We continue to skip
generating SFrame FDE for these cases and warn the user.
In future, SFrame stack trace format may support non-SP/FP as base
register (albeit in limited form). Add an explicit check in
sframe_xlate_do_escape_expr (to test against the current CFA register)
to ensure the functionality continues to work.
Use differentiated warning text in sframe_xlate_do_val_offset to avoid
confusion to the user as the same function is used for handling
.cfi_val_offset and .cfi_escape DW_CFA_val_offset,...
Also, add a common test with DWARF reg 12 which is non SP / FP on x86_64
and aarch64 (and s390x too).
gas/
* gas/dw2gencfi.c (struct cfi_escape_data): Move from ...
* gas/dw2gencfi.h (struct cfi_escape_data): ... to.
* gas/gen-sframe.c (sframe_xlate_do_val_offset): Include string
for .cfi_escape conditionally.
(sframe_xlate_do_escape_expr): New definition.
(sframe_xlate_do_escape_val_offset): Likewise.
(sframe_xlate_do_cfi_escape): Likewise.
(sframe_do_cfi_insn): Handle CFI_escape explicitly.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
* gas/cfi-sframe/cfi-sframe-common-9.d: New test.
* gas/cfi-sframe/cfi-sframe-common-9.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.s: New test.
Charlie Jenkins [Wed, 19 Feb 2025 21:20:18 +0000 (13:20 -0800)]
RISC-V: Fix abort when displaying data and partial instructions
If data is encountered that is not a power of two, dump all of the data with
a .<N>byte directive. The current largest support risc-v instruction length
is 22, so the data over 22 bytes will be displayed by,
.insn, 22, ... + .<N-22>byte.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Clément Chigot [Mon, 24 Feb 2025 14:00:24 +0000 (15:00 +0100)]
ld/testsuite: add -z separate-code to sframe x86_64 tests
Those tests were generated by a linker having "-z separate-code" on by
default. However, being controlled by a configure option, it can be off
by default. Forcing the option as part of the tests ensures clean
results in both cases.
Tom de Vries [Wed, 26 Feb 2025 06:46:40 +0000 (07:46 +0100)]
[gdb/build] Fix unused var in dwarf2/read.c
On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
...
gdb/dwarf2/read.c: In function ‘void read_comp_units_from_section()’:
gdb/dwarf2/read.c:4297:31: error: unused variable ‘sig_type_it’ \
[-Werror=unused-variable]
auto [sig_type_it, inserted] = sig_types.emplace (sig_ptr);
^
...
Simon Marchi [Tue, 25 Feb 2025 20:54:56 +0000 (15:54 -0500)]
gdb/dwarf: fix signature_type created with nullptr section
Commit c44ab627b02 ("gdb/dwarf: pass section to dwarf2_per_cu_data
constructor") introduced a regression when using dwp. It can be
reproduced with:
$ make check TESTS="gdb.base/ptype-offsets.exp" RUNTESTFLAGS="--target_board=fission-dwp"
Then, to investigate:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets -ex 'ptype int'
Reading symbols from testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3195:38: runtime error: member call on null pointer of type 'struct dwarf2_section_info'
Commit c44ab627b02 removed the assignment of signatured_type::section
(dwarf2_per_cu_data::section, really) in
fill_in_sig_entry_from_dwo_entry with the justification that the section
was already set when constructing the signatured_type. Well, that was
true except for one spot in lookup_dwp_signatured_type which passes a
nullptr section to add_type_unit.
Fix that by passing the section to add_type_unit in that one spot. This
is the same section that would have been set by
fill_in_sig_entry_from_dwo_entry before.
Add some asserts in the dwarf2_per_cu_data constructor to verity that
the passed dwarf2_per_bfd and dwarf2_section_info are non-nullptr.
Change-Id: If27dae6b4727957c96defc058c7e4be31472005b
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32739 Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom Tromey <tom@tromey.com>
This motivated me to convert the dwarf2_per_bfd::signatured_types hash
table to a gdb::unordered_set. This allows finding an entry by simply
passing the signature (an integer) and removes the need to create dummy
signatured_type objects.
There is one small unfortunate pessimization:
lookup_dwo_signatured_type, for instance, does a lookup by signature to
find an existing signatured_type. If not found, it adds a new one by
calling add_type_unit. The current code passes down the slot where to
put the new element, avoiding an extra hash when inserting the new
signatured_type. With the new code, I don't see a way to do that. This
is probably negligible, but it bugs me. If we used a map of signature
-> signatured_type, I would see a way, but then it would waste space.
I see one change in behavior, that is not really important IMO. In
read_comp_units_from_section, if duplicate signature type entries are
detected, the code prior to this patch overwrites the existing
signatured_type in the hash table with the new one. With this patch,
the existing signatured_type is kept: the call to emplace does not
insert the value if an existing equal value exists.
Other than that, no behavior change expected.
Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Tue, 25 Feb 2025 21:28:38 +0000 (16:28 -0500)]
gdb: move "gdb:function_view" into quick-symbol.h typedefs
All users of these typedefs use them inside a gdb::function_view. Move
the gdb::function_view in the typedefs themselves. This shortens the
types in function signatures and helps with readability, IMO.
Rename them to remove the `_ftype` suffix: this suffix is not as
relevant in C++ as it was in C. With function_view, the caller can pass
more than just a simple "function". Anyway, I think it's clearer to
name them after the role the callback has (listener, matcher, etc).
Adjust some related comments.
Change-Id: Iaf9f8ede68b51ea9e4d954792e8eb90def8659a6 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Tue, 14 Jan 2025 19:16:23 +0000 (14:16 -0500)]
gdb/amd-dbgapi: add displaced stepping support
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.
Simon Marchi [Tue, 14 Jan 2025 19:16:22 +0000 (14:16 -0500)]
gdb: add target displaced stepping support
The amd-dbgapi library, used in the AMD GPU port, has the capability to
prepare and cleanup displaced step operations. In order to use it, add
the following target_ops methods:
Prior to this patch, displaced stepping preparation and cleanup is done
solely by gdbarches. Update infrun to use these new target methods
instead of gdbarch hooks. To keep the behavior for other architectures
unchanged, make the default implementations of the new target_ops method
forward to the thread's gdbarch.
displaced_step_restore_all_in_ptid won't be needed for the AMD GPU port,
but was added for completeness. It would be weird for infrun displaced
stepping code to call target methods except for that one thing where it
calls a gdbarch method.
Since this patch only adds infrastructure, no behavior change is
expected.
Ciaran Woodward [Wed, 12 Feb 2025 17:57:32 +0000 (17:57 +0000)]
Fix mkdir_recursive on windows when CWD is root
On windows, when creating a directory with an absolute path,
mkdir_recursive would start by trying to make 'C:'.
On windows, this has a special meaning, which is "the current
directory on the C drive". So the first thing it tries to do
is create the current directory.
Most of the time, this fails with EEXIST, so the function
continues as expected. However if the current directory is
C:/, trying to create that causes EPERM, which causes the
function to prematurely terminate.
(The same applies for any drive letter.)
This patch resolves this issue, by skipping the drive letter
so that it is never sent to the mkdir call.
Jens Remus [Fri, 21 Feb 2025 10:28:23 +0000 (11:28 +0100)]
x86: SFrame FDE for PLT0 does not use repetition block size
The SFrame FDE for the PLT0 entry is of type PCINC, which does does not
make use of the type PCMASK repetition block size. Therefore generate
the FDE with a repetition block size of zero.
bfd/
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use FDE
repetition block size of zero for PLT0.
gdb/remote: Set the thread of the remote before sending qRcmd.
GDB allows remotes to implement extension commands which can
be accessed using the 'monitor' command.
This allows remotes to implement functionality which does not
exist in GDB for whatever reason (doesn't make sense, too
specific to one target, etc.)
However, before this change, the remote would not necessarily know
which thread/inferior was currently selected on the GDB client.
This prevents the implementation of any 'monitor' commands which are
specific to a single inferior/thread on the remote.
This is because GDB informs the remote of the current thread
lazily - only when it is relevant to the RSP command next being
sent.
qRcmd is the underlying RSP command used for monitor commands, so
this change ensures that GDB will update the remote with the
'current' thread if it has changed since the remote was last
informed.
I noticed that the disable_breakpoints_in_shlibs function disables
breakpoints without calling notify_breakpoint_modified. This commit
is one step towards fixing this issue.
There are currently only two uses of disable_breakpoints_in_shlibs,
one in clear_solib (in solib.c), and the other in
windows_nat_target::do_initial_windows_stuff (in windows-nat.c).
I believe that the call in windows-nat.c can be shown to be redundant,
and therefore can be removed.
windows_nat_target::do_initial_windows_stuff is called from two
places: windows_nat_target::attach and
windows_nat_target::create_inferior, these are the target_ops
functions used to attach to a running process, or for creating a new
process, and are only called from attach_command or run_command_1,
both in infcmd.c.
Both attach_command and run_command_1 call target_pre_inferior before
calling the relevant target_ops function.
In target_pre_inferior, so long as the target doesn't have a global
solist (and windows doesn't), we always call no_shared_libraries (from
solib.c), which calls clear_solib (also in solib.c), which in turn
calls disable_breakpoints_in_shlibs.
My claim then, is that, any time we reach the
disable_breakpoints_in_shlibs call in
windows_nat_target::do_initial_windows_stuff, we will have always have
called disable_breakpoints_in_shlibs already via clear_solib.
I think it should be safe to remove the disable_breakpoints_in_shlibs
call from windows_nat_target::do_initial_windows_stuff. There should
be no user visible changes.
My ultimate goal, which I'll address in follow on commits, is to
delete disable_breakpoints_in_shlibs completely. Removing this call
means that we only have one disable_breakpoints_in_shlibs call
remaining in GDB.
Testing for this change has been minimal. My only Windows build
machine is not great, and I've never managed to get DejaGNU running in
that environment. This commit builds, and a few basic, manual tests
seem fine, but beyond that, this change is untested.
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
Tom de Vries [Tue, 25 Feb 2025 07:29:19 +0000 (08:29 +0100)]
[libctf] Fix warning: @xref should not appear on @multitable line
When building gdb, I run into:
...
ctf-spec.texi:809: warning: @xref should not appear on @multitable line
...
The line in question is:
...
@multitable {Kind} {@code{CTF_K_VOLATILE}} {Indicates a type that cannot be represented in CTF, or that} {@xref{Pointers typedefs and cvr-quals}}
...
which defines a prototype row with 4 columns.
However, the table only has 3 colums:
...
@headitem Kind @tab Macro @tab Purpose
...
Fix the warning by removing the item in the prototype row representing a fourth column.
Kevin Buettner [Mon, 24 Feb 2025 20:04:00 +0000 (13:04 -0700)]
Use ui_out for "info checkpoints"
In his review of my recent checkpoint work (commit e5501dd4321),
Andrew Burgess suggested that I use GDB's structured table generation
mechanism for the "info checkpoints" command. This patch does
that.
Andrew also recommended using print_stack_frame() for the "Frame"
column. I tried this, but ran into some problems, which are described
in a comment in the code. I got it to mostly work, except for the
case when the current/active fork is running. Switching context away
from and then back to a running fork doesn't work. It could, perhaps,
be made to work, but I'm not convinced that the checkpoint facility is
important enough to expend the effort for this case. So, instead,
I simply adapted the existing checkpoint frame printing code to
use the ui_out machinery instead of gdb_printf.
Andrew Burgess [Mon, 17 Feb 2025 10:21:12 +0000 (10:21 +0000)]
gdb/styling: only check TERM environment once, during initialisation
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>
Andrew Burgess [Mon, 17 Feb 2025 10:51:30 +0000 (10:51 +0000)]
gdb/tui: use correct setting to control asm window styling
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.
Andrew Burgess [Mon, 17 Feb 2025 10:51:10 +0000 (10:51 +0000)]
gdb/doc: fix help text for 'set style disassembler enabled'
The help text for 'set/show style disassembler enable' was output of
date. It talks about GDB requiring the Python Pygments library, but
for many common architectures this is no longer the case, libopcode is
used for styling.
The Python Pygments library is still used as a fallback for those
architectures that libopcode doesn't currently style.
I've updated the help text to try and explain all this. The manual
was already updated.
Tom de Vries [Mon, 24 Feb 2025 15:51:10 +0000 (16:51 +0100)]
[gdb/doc] Fix documentation of handle SIGKILL
Here ( https://sourceware.org/gdb/current/onlinedocs/gdb.html/Signals.html ) I
read:
...
GDB has the ability to detect any occurrence of a signal in your program. You
can tell GDB in advance what to do for each kind of signal.
...
However, here ( https://man7.org/linux/man-pages/man2/ptrace.2.html ) I read:
...
While being traced, the tracee will stop each time a signal is
delivered, even if the signal is being ignored. (An exception is
SIGKILL, which has its usual effect.)
...
So, it seems to be that for SIGKILL we can't tell GDB in advance what to do.
Fix the documentation to reflect this.
Approved-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/32714
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32714
Rudnicki, Piotr [Wed, 12 Feb 2025 09:50:37 +0000 (10:50 +0100)]
gdb, testsuite, rust: fix for empty array
For the Rust language, to avoid segmentation fault in case of an empty
array, do not try to copy any elements, but allocate and return
the empty array immediately.
With the command before the change, gdb crashes with message:
(gdb) set lang rust
(gdb) p [1;0]
Fatal signal: Segmentation fault
After the fix in this commit, gdb shows following message:
(gdb) set lang rust
(gdb) p [1;0]
$1 = []
Update the existing test case gdb.rust/expr.exp to verify the change.
Andrew Burgess [Thu, 5 Dec 2024 17:18:13 +0000 (17:18 +0000)]
gdb: handle empty locspec when printing breakpoints
For background reading, please see the previous patch, and the patch
before that!
After the last two patches, internal breakpoints can now be marked as
shlib_disabled if the library in which they are placed is unloaded.
The patch before last discusses a situation related to the
gdb.base/nostdlib.exp test, when run on a GNU/Linux glibc based system
where executables are compiled as PIE by default.
In this case it is observed that the dynamic linker will actually
report itself as unloaded (i.e. remove itself from the list of
currently loaded shared libraries). This behaviour is likely a bug in
the dynamic linker, but this behaviour exists in released versions of
the dynamic linker, so GDB should (if the cost is not too great) be
changed to handle this situation.
This commit handles a problem with the 'maint info breakpoints'
command.
When the dynamic linker is unloaded the 'shlib event' breakpoint is
marked as shlib_disabled (i.e. placed into the pending state). When
displaying the breakpoint in the 'maint info breakpoints' output, GDB
will try to print the locspec (location_spec *) as a string
Unfortunately, the locspec will be nullptr as the internal breakpoints
are not created via a location_spec, this means that GDB ends up
trying to call location_sepc::to_string() on a nullptr, resulting in
undefined behaviour (and a crash).
For most internal breakpoint types this is not a problem. If we
consider bp_longjmp_master for example, if the shared library
containing a breakpoint of this type is unloaded then first GDB marks
the breakpoint as shlib_disabled, then after unloading the shared
library breakpoint_re_set is called, which will delete the internal
breakpoint, and then try to re-create it (if needed). As a result,
the user never gets a change to run 'maint info breakpoints' on a
bp_longjmp_master breakpoint in the shlib_disabled state.
But bp_shlib_event and bp_thread_event breakpoints are not deleted and
recreated like this (see internal_breakpoint::re_set), so it is
possible, in rare cases, that we could end up trying to view one of
these breakpoint in a shlib_disabled state, and it would be nice if
GDB didn't crash as a result.
I've updated the printing code to check for and handle this case, and
I've updated the docs to mention this (rare) case.
For testing, I've extended gdb.base/nostdlib.exp to compile as
pie and nopie, and then run 'maint info breakpoints'. If we're
running on a buggy glibc then this will trigger the crash. I don't
know how I can trigger this problem without a buggy glibc as this
would require forcing the dynamic linker to be unloaded.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 28 Aug 2024 16:00:37 +0000 (17:00 +0100)]
gdb: disable internal b/p when a solib is unloaded
Bug PR gdb/32079 highlights an issue where GDB will try to remove a
breakpoint for a shared library that has been unloaded. This will
trigger an error from GDB like:
(gdb) next
61 dlclose (handle[dl]);
(gdb) next
warning: error removing breakpoint 0 at 0x7ffff78169b9
warning: error removing breakpoint 0 at 0x7ffff7730b57
warning: error removing breakpoint 0 at 0x7ffff7730ad3
54 for (dl = 0; dl < 4; ++dl)
(gdb)
What happens is that as the inferior steps over the dlclose() call,
GDB notices that the library has been unloaded and calls
disable_breakpoints_in_unloaded_shlib. However, this function only
operates on user breakpoints and tracepoints.
In the example above what is happening is that the test loads multiple
copies of libc into different linker namespsaces. When we 'next' over
the dlclose call one of the copies of libc is unloaded. As GDB placed
longjmp master breakpoints within the copy of libc that was just
unloaded, the warnings we see are GDB trying (and failing) to remove
these breakpoints.
I think the solution is for disable_breakpoints_in_unloaded_shlib to
handle all breakpoints, even internal ones like the longjmp master
breakpoints.
If we do this then the breakpoint will be marked as shlib_disabled and
also will be marked as not inserted. Later when we call
breakpoint_re_set() and the longjmp breakpoints are deleted we will no
longer try to remove them.
This solution is inspired by a patch suggested in the bug report:
There are some differences with my approach compared to the patch
suggested in the bug. First I have no need to delete the breakpoint
inside disable_breakpoints_in_unloaded_shlib as an earlier patch in
this series arranged for breakpoint_re_set to be called when shared
libraries are removed. Calling breakpoint_re_set will take care of
deleting the breakpoint for us. For details see the earlier commit
titled:
gdb: fixes for code_breakpoint::disabled_by_cond logic
Next, rather than only handling bp_longjmp and bp_longjmp_master, I
allow all breakpoints to be handled. I also only give the warning
about disabling breakpoints for user breakpoints, I don't see the
point of warning the user about internal b/p changes.
With this done the issues in PR gdb/32079 are resolved.
Andrew Burgess [Thu, 5 Dec 2024 17:17:38 +0000 (17:17 +0000)]
gdb: don't clear inserted flag in disable_breakpoints_in_unloaded_shlib
This commit removes the clearing of bp_location::inserted from
disable_breakpoints_in_unloaded_shlib, my claim is that this call is
not needed (any more), and with the next commit, this line actually
causes some problems.
The disable_breakpoints_in_unloaded_shlib function was added back in
2004 with commit 84acb35a5a97c, and from this first version the
function cleared the bp_location::inserted flag. The motivation for
this is that the shared library might have already been unmapped, in
which case, a later attempt to remove the location could fail.
In 2013 a similar function disable_breakpoints_in_freed_objfile was
added. This function also cleared bp_location::inserted for similar
reasons. This code was added in commit:
The reason that clearing the ::inserted flag was removed in this
commit is that if the disable_breakpoints_in_freed_objfile function
was called when the b/p were actually inserted, and the memory for the
associated objfile wasn't actually unmapped, then we could end up
leaving breakpoints inserted into the inferior, which leads to
spurious SIGTRAPs.
In the next commit I'll change disable_breakpoints_in_unloaded_shlib
so that all breakpoints, not just user breakpoints, will be
disabled (via shlib_disabled) when a shared library is unloaded. This
addresses PR gdb/32079, see the next commit for a fuller justification
for this change.
The problem is that when I tested the next commit I ran into some
regressions from the gdb.base/nostdlib.exp test when run on an AArch64
GNU/Linux system where executables are compiled as PIE by default.
This test compiles a simple binary with the -nostdlib flag.
What happens is this:
- The executable is compiled as PIE, this means that we get a
dynamically linked executable, the dynamic linker is used to
perform the PIE relocation, but the executable uses no other
shared libraries.
- When GDB starts the inferior, initially the dynamic linker is
discovered as a shared library being used by the application, GDB
loads in the library and its debug symbols, placing the internal
"shlib event" breakpoints so that future shared library events can
be tracked.
- For the target I tested on systemtap probes were not used, instead
GDB fell back to the old style even breakpoint.
- As the inferior progresses, after the PIE relocation has been
performed, the dynamic linker performs some house keeping on the
list of shared libraries being used by the application. During
this process the dynamic linker is removed from the list of shared
libraries being used by the inferior, this causes GDB see a shared
library event, which GDB understands to mean that it should unload
the dynamic linker from the inferior.
I spoke with the glibc engineers at RH, and the feeling is that
this is likely a bug (it's still being investigated). But I don't
think it really matters if this is a bug or not. There are
versions of glibc in the wild that have this behaviour, so GDB
should (if the cost is not too great) be updated to handle this.
Obviously after removing the dynamic linker from the list of
shared libraries, the dynamic linker is not actually unmapped,
that would not be possible, it's the dynamic linker that does the
unmapping, so the dynamic linker is left mapped into the
inferior's address space.
- With the next patch in place all breakpoints (user and internal)
within the dynamic linker are disabled (shlib_disabled) and
currently marked as not inserted (bp_location::inserted flag is
cleared).
- Having processed the shared library event GDB then resumes the
inferior. As the shared library event is not a full stop of the
inferior (i.e. we don't remove all breakpoints before handling the
event), all of the breakpoints in the dynamic linker are still
inserted, but are now marked as not-inserted.
- GDB then resumes the inferior and immediately hits the breakpoint
that is still inserted. As GDB thinks this breakpoint is not
inserted, this is reported to the user as a SIGTRAP.
The fix I think is just to not clear the bp_location::inserted flag in
disable_breakpoints_in_unloaded_shlib. This will leave the breakpoint
as inserted in the case above. GDB will now be able to successfully
resume the inferior after the shared library event (knowing there is a
breakpoint inserted GDB will step over it and continue as expected).
The next time the inferior performs a full stop the now shlib_disabled
breakpoint will be removed from the inferior we would want.
For the usual case, where a shared library is being unloaded due to
say a dlclose, the breakpoints in the library will be marked as
disabled, but will be left inserted. The next time remove_breakpoints
is called GDB will try to remove those breakpoint locations. If the
removal fails, as the breakpoint is marked shlib_disabled, GDB will
hide the error message from the user and just assume that the shared
library has been unmapped. This functionality was first added in 2008
in commit 879d1e6b4674bc8.
There are two aspects to testing this change. First whether no
clearing the ::inserted flag causes general problems. That is tested
by running the full testsuite (I see no regressions).
Then there is the specific problem that caused me to make this
change. That issue only occurs on AArch64, with GNU/Linux using
glibc, when the executable is compiled as PIE, and doesn't use any
shared libraries other than the dynamic linker (which can be the
gdb.base/nostdlib.exp test if run on the right system). What I don't
know is how to recreate this setup in a more general form.
We can't use add-symbol-file/remove-symbol-file as that passes through
disable_breakpoints_in_freed_objfile instead, which the ::installed
flag is already not adjusted.
Also the bug doesn't trigger on x86 targets due to code in
handle_signal_stop which sees the inserted breakpoint, and decides
this must be a breakpoint that actually exists in the program, and
then because gdbarch_decr_pc_after_break returns non-zero for x86, GDB
steps the inferior past the breakpoint. This is the big difference
from AArch64 where gdbarch_decr_pc_after_break returns zero, and so
the inferior gets stuck hitting the unexpectedly inserted breakpoint.
Andrew Burgess [Thu, 29 Aug 2024 11:34:15 +0000 (12:34 +0100)]
gdb: handle dprintf breakpoints when unloading a shared library
While working on the previous commit I realised that GDB would not
handle dprintf breakpoints correctly when a shared library was
unloaded.
Consider this example using the test binary from shlib-unload.exp. In
the function 'foo' we create a dprintf is in a shared library:
(gdb) b 59
Breakpoint 1 at 0x401215: file /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload.c, line 59.
(gdb) r
Starting program: /tmp/projects/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/shlib-unload/shlib-unload
Breakpoint 1, main () at /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload.c:59
59 res = dlclose (handle); /* Break here. */
(gdb) dprintf foo,"In foo"
Dprintf 2 at 0x7ffff7fc50fd: file /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload-lib.c, line 23.
(gdb) n
Error in re-setting breakpoint 2: Function "foo" not defined.
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
warning: error removing breakpoint 2 at 0x7ffff7fc50fd
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
60 assert (res == 0);
(gdb)
What happens here is that as the inferior steps over the dlclose call
the shared library containing 'foo' is unloaded and
disable_breakpoints_in_unloaded_shlib is called. However in
disable_breakpoints_in_unloaded_shlib we have this check:
As the dprintf has type bp_dprintf then this check triggers and we
ignore the dprintf, meaning the dprintf is not disabled. When the
inferior stops after the 'next' GDB tries to remove all breakpoints
but the dprintf can no longer be removed, the memory in which it was
placed has been unmapped from the inferior.
The fix is to start using is_breakpoint() in
disable_breakpoints_in_unloaded_shlib instead of the bp_breakpoint and
bp_hardware_breakpoint checks. The is_breakpoint() function also
checks for bp_dprintf.
With this fix in place GDB now correctly disables the breakpoint and
we no longer see the warning about removing the breakpoint.
During review it was pointed out that PR gdb/23149 and PR gdb/20208
both describe something similar, though for these bugs, the inferior
is restarted (which unloads all currently loaded shlib) rather than
passing over the dlclose. But the consequences are pretty similar.
I've included a test which covers this case.
One additional thing that these two bugs did show though is that
disable_breakpoints_in_shlibs also needs to start using is_breakpoint
for the same reason. Without this change, when an inferior is
restarted we get a warning like this for dprintf breakpoints:
warning: Temporarily disabling breakpoints for unloaded shared library "..."
but we don't get a similar warning for "normal" breakpoints. This is
because disable_breakpoints_in_shlibs is called from clear_solib,
which is called when an inferior is restarted.
It is best not to think too hard about disable_breakpoints_in_shlibs,
as this function is pretty broken, e.g. it doesn't call
notify_breakpoint_modified, despite modifying the breakpoints. But
for now I'm ignoring that, but fixing this is definitely on my list
for my next set of breakpoint related fixes, it's just that a lot of
these breakpoint fixes end up being depending on one another, but I
want to avoid making this series too long. So for now, I'm ignoring
the existing bug (missing breakpoint modified events), and fixing
disable_breakpoints_in_shlibs to cover dprintf.
With these fixes in place, the two bugs mentioned above should be
fixed.
This commit rewrites disable_breakpoints_in_unloaded_shlib to be more
like disable_breakpoints_in_freed_objfile. Instead of looping over
all b/p locations, we instead loop over all b/p and then over all
locations for each b/p.
The advantage of doing this is that we can fix the small bug that was
documented in a comment in the code:
/* This may cause duplicate notifications for the same breakpoint. */
notify_breakpoint_modified (b);
By calling notify_breakpoint_modified() as we modify each location we
can potentially send multiple notifications for a single b/p.
Is this a bug? Maybe not. After all, at each notification one of the
locations will have changed, so its probably fine. But it's not
ideal, and we can easily do better, so lets do that.
There's a new test which checks that we only get a single notification
when the shared library is unloaded. Note that the test is written as
if there are multiple related but different tests within the same test
file ... but there aren't currently! The next commit will add another
test proc to this test script at which point the comments will make
sense. I've done this to avoid unnecessary churn in the next commit.
Tested-By: Hannes Domani <ssbssa@yahoo.de> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Thu, 15 Aug 2024 16:43:18 +0000 (17:43 +0100)]
gdb: fixes for code_breakpoint::disabled_by_cond logic
I spotted that the code_breakpoint::disabled_by_cond flag doesn't work
how I'd expect it too. The flag appears to be "sticky" in some
situations; once a code_breakpoint::disabled_by_cond flag is marked
true, then, in some cases the flag wont automatically become false
again, even when you'd think it should.
The problem is in update_breakpoint_locations. In this function,
which is called as a worker of code_breakpoint::re_set, GDB computes a
new set of locations for a breakpoint, the new locations are then
installed into the breakpoint.
However, before installing the new locations GDB attempts to copy the
bp_location::enabled and bp_location::disabled_by_cond flag from the
old locations into the new locations.
The reason for copying the ::enabled flag makes sense. This flag is
controlled by the user. When we create the new locations if GDB can
see that a new location is equivalent to one of the old locations, and
if the old location was disabled by the user, then the new location
should also be disabled.
However, I think the logic behind copying the ::disabled_by_cond flag
is wrong. The disabled_by_cond flag is controlled by GDB and should
toggle automatically. If the condition string can be parsed then the
flag should be false (b/p enabled), if the condition string can't be
parsed then the flag should be true (b/p disabled).
As we always parse the condition string in update_breakpoint_locations
before we try to copy the ::enabled flag value then the
::disabled_by_cond flag should already be correct, there's no need to
copy over the ::disabled_by_cond value from the old location.
As a concrete example, consider a b/p placed within the main
executable, but with a condition that depends on a variable within a
shared library.
When the b/p is initially created the b/p will be disabled as the
condition string will be invalid (the shared library variable isn't
available yet).
When the inferior starts the shared library is loaded and the
condition variable becomes available to GDB. When the shared library
is loaded breakpoint_re_set is called which (eventually) calls
update_breakpoint_locations.
A new location is computed for the breakpoint and the condition string
is parsed. As the shared library variable is now know the expression
parses correctly and ::disabled_by_cond is left false for the new
location.
But currently GDB spots that the new location is at the same address
as the old location and copies disabled_by_cond over from the old
location, which marks the b/p location as disabled. This is not what
I would expect.
The solution is simple, don't copy over disabled_by_cond.
While writing a test I found another problem though. The
disabled_by_cond flag doesn't get set true when it should! This is
the exact opposite of the above.
The problem here is in solib_add which is (despite the name) called
whenever the shared library set changes, including when a shared
library is unloaded.
Imagine an executable that uses dlopen/dlclose to load a shared
library. Given an example of a b/p in the main executable that has a
condition that uses a variable from our shared library, a library
which might be unloaded with dlclose.
My expectation is that, when the library is unloaded, GDB will
automatically mark the breakpoint as disabled_by_cond, however, this
was not happening.
The problem is that in solib_add we only call breakpoint_re_set when
shared libraries are added, not when shared libraries are removed.
The solution I think is to just call breakpoint_re_set in both cases,
now the disabled_by_cond flag is updated as I'd expect.
Unfortunately, making this change causes a regression when running:
make check-gdb \
TESTS="gdb.trace/change-loc.exp" \
RUNTESTFLAGS="--target_board=native-gdbserver"
This test unloads a shared library and expects breakpoints within the
shared library to enter the PENDING state (because the bp_location's
shlib_disabled flag will be set). However, the new call to
breakpoint_re_set means that this is no longer the case.
The breakpoint_re_set call means that update_breakpoint_locations is
called, which then checks if all locations for a breakpoint are
pending or not. In this test not all locations are pending, and so
GDB recalculates the locations of each breakpoint, this means that
pending locations are discarded.
There is a but report PR gdb/32404 which mentions the problems with
shlib_disabled pending breakpoints, and how they are prone to being
randomly deleted if the user can cause GDB to trigger a call to
breakpoint_re_set. This patch just adds another call to
breakpoint_re_set, which triggers this bug in this one test case.
For now I have marked this test as KFAIL. I do plan to try and
address the pending (shlib_disabled) breakpoint problem in the future,
but I'm not sure when that will be right now.
There are, of course, tests to cover all these cases.
During review I was pointed at bug PR gdb/32079 as something that this
commit might fix, or help in fixing.
And this commit is part of the fix for that bug, but is not the
complete solution. However, the remaining parts of the fix for that
bug are not really related to the content of this commit.
The problem in PR gdb/32079 is that the inferior maps multiple copies
of libc in different linker namespaces using dlmopen (actually libc is
loaded as a consequence of loading some other library into a different
namespace, but that's just a detail). The user then uses a 'next'
command to move the inferior forward.
GDB sets up internal breakpoints on the longjmp symbols, of which
there are multiple copies (there is a copy in every loaded libc).
However, the 'next' command is, in the problem case, stepping over a
dlclose call which unloads one of the loaded libc libraries.
In current HEAD GDB in solib_add we fail to call breakpoint_re_set()
when the library is unloaded; breakpoint_re_set() would delete and
then recreate the longjmp breakpoints. As breakpoint_re_set() is not
called GDB thinks that the the longjmp breakpoint in the now unloaded
libc still exists, and is still inserted.
When the inferior stops after the 'next' GDB tries to delete and
remove the longjmp breakpoint which fails as the libc in which the
breakpoint was inserted is no longer mapped in.
When the user tries to 'next' again GDB tries to re-insert the still
existing longjmp breakpoint which again fails as the memory in which
the b/p should be inserted is no longer part of the inferior memory
space.
This commit helps a little. Now when the libc library is unmapped GDB
does call breakpoint_re_set(). This deletes the longjmp breakpoints
including the one in the unmapped library, then, when we try to
recreate the longjmp breakpoints (at the end of breakpoint_re_set) we
don't create a b/p in the now unmapped copy of libc.
However GDB does still think that the deleted breakpoint is inserted.
The breakpoint location remains in GDB's data structures until the
next time the inferior stops, at which point GDB tries to remove the
breakpoint .... and fails.
However, as the b/p is now deleted, when the user tries to 'next' GDB
no longer tries to re-insert the b/p, and so one of the problems
reported in PR gdb/32079 is resolved.
I'll fix the remaining issues from PR gdb/32079 in a later commit in
this series.
Alan Modra [Sun, 23 Feb 2025 10:35:00 +0000 (21:05 +1030)]
gas: avoid dangling pointers into freed memory
The oss-fuzz gas fuzzer is quite broken in that it doesn't
reinitialise all gas and bfd static variables between runs. Since gas
naughtily modifies bfd_und_section and bfd_abs_section those bfd
statics can hold pointers into freed memory between runs.
This patch fixes oss-fuzz issue 398060144.
Maximilian Ciric [Sat, 22 Feb 2025 20:57:15 +0000 (20:57 +0000)]
MIPS objdump: Recognize o64 ABI names
Add gpr and fpr names for the o64 ABI to objdump.
With the recent addition of both EABIs, this completes support for the
standard ABI options (ABI-breaking options such as -modd-spreg or
-mabi=32 -mfp64 notwithstanding). The names have been verified against
GCC's usage of the registers. Notably, the only(?) documentation that
defines the o64 ABI at
https://gcc.gnu.org/projects/mipso64-abi.html
appears to contain a mistake w.r.t. floating-point arguments. In
particular:
> If the first and second arguments floating-point arguments to a
> function are 32-bit values, they are passed in $f12 and $f14.
As from 4.0.0 this does not happen in GCC's implementation of the ABI;
a pair of single-float arguments are still passed in $f12 and $f13, the
same as when one or both of the arguments are double-precision floats.
The registers $f12, $f13 and $f14 have been named $fa0, $fa1 and $ft10
to match the implementation.
Signed-off-by: Maximilian Ciric <max.ciric@gmail.com>
Shahab Vahedi [Wed, 12 Feb 2025 14:58:15 +0000 (15:58 +0100)]
gdb/testsuite/rocm.exp: Use system GPU(s) to detect features
gdb/testsuite/rocm.exp: Use system GPU(s) to detect features
Background
----------
This patch revisits the purpose of hcc_amdgpu_targets{} in
order to address the separation of concerns between:
- GPU targets passed to the compiler. This kind of target
is passed as an argument to flags like "--offload-arch=...",
"--targets=...", etc.
- GPU targets as in available GPU devices on the system. This
is crucial for finding which capabilities are available,
and therefore which tests should be executed or skipped.
Code change
-----------
- A new "find_amdgpu_devices{}" procedure is added. It is
responsible for listing the GPU devices that are available
on the system.
- "hcc_amdgpu_targets{}" is rewritten to use the newly added
"find_amdgpu_devices{}" when there's no environment variable
(HCC_AMDGPU_TARGET) set.
- The output of "hcc_amdgpu_targets{}" is now only used in
places that set the target for the building toolchains.
- The output of "find_amdgpu_devices{}" is used anywhere that
needs to evaluate the GPU features.
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: Ib11021dbe674aa40192737ede78284a1bc531513
Jan Beulich [Fri, 21 Feb 2025 09:28:46 +0000 (10:28 +0100)]
IQ2000: drop maintainer
After I found his email bouncing, Stan, via private communication which
Nick helped with, has indicated that - having retired - he won't any
longer fulfill the maintainer role here.
Jan Beulich [Fri, 21 Feb 2025 09:28:24 +0000 (10:28 +0100)]
x86: GOT is an ELF-only entity
Make md_undefined_symbol() conditional upon dealing with ELF, much like
other architectures (e.g. Arm32 and Arm64) have it. This avoids errors
in gas and even assertions in libbfd when "accidentally" e.g. a COFF-
targeting source file uses "_GLOBAL_OFFSET_TABLE_" for whatever reason.
While there also convert the final return statement to properly use
NULL.
NB: In principle 64-bit Mach-O knows GOT, too. Yet only an i?86-macho
assembler can be built right now, as per configure.tgt. Pretty clearly
adjustments to gotrel[] would also be necessary before these targets
could actually work reasonably cleanly.
Jan Beulich [Fri, 21 Feb 2025 09:26:59 +0000 (10:26 +0100)]
ix86: restrict use of GOT32X relocs
The ELF linker rejects use of this reloc type without a base register
for PIC code. Suppress its use by gas in such cases.
To keep things building for non-ELF, include the entire containing if()
in an #ifdef: All consumers of ->fx_tcbit* live in such conditionals as
well, hence there's no reason to keep the producer active.
Jan Beulich [Fri, 21 Feb 2025 09:24:50 +0000 (10:24 +0100)]
x86: widen @got{,pcrel} support to PUSH and APX IMUL
With us doing the transformation to an immediate operand for MOV and
various ALU insns, there's little reason to then not support the same
conversion for the other two insns which have respective immediate
operand forms. Unfortunately for IMUL (due to the 0F opcode prefix)
there's no suitable relocation, so the pre-APX forms cannot be marked
for relaxation in the assembler.
Jan Beulich [Fri, 21 Feb 2025 09:22:50 +0000 (10:22 +0100)]
ix86: tighten convert-load-reloc checking
Just like was done recently for x86-64 (commit 4998f9ea9d35): Even if
the assembler avoids using the relaxable relocation for inapplicable
insns, the relocation type can still appear for other reasons. Be more
thorough in the opcode checking we do, to avoid bogusly altering other
insns.
Furthermore correct an opcode mask (even if with the added condition
that's now fully benign).
Simon Marchi [Thu, 20 Feb 2025 16:38:04 +0000 (11:38 -0500)]
gdb/doc: fix sentence in save gdb-index` command doc
The part "... this command by default creates it produces a single ..."
sounds wrong. Replace with "... this command by default produces a
single ...".
Simon Marchi [Thu, 20 Feb 2025 15:13:38 +0000 (10:13 -0500)]
gdb/compile: add missing entry in bfd_link_callbacks array
clang 19 fails to build gdb with this error:
/home/simark/src/binutils-gdb/gdb/compile/compile-object-load.c:302:3: error: cannot initialize a member subobject of type 'void (*)(const char *, ...) __attribute__((noreturn))' with an lvalue of type 'void (const char *, ...)'
302 | link_callbacks_einfo, /* einfo */
| ^~~~~~~~~~~~~~~~~~~~
This illustrates that the bfd_link_callbacks array is missing an entry
for the "fatal" callback, add it.
The fatal field was added very recently, in d26161914 ("PR 32603, more
ld -w misbehaviour"). We're lucky that the new callback was marked with
the noreturn attribute and that clang checks that, otherwise this would
have gone unnoticed.
Tom Tromey [Thu, 5 Sep 2024 18:09:43 +0000 (12:09 -0600)]
Handle optional lines correctly in gdb.ada/complete.exp
While working on another series, I discovered that the existing code
in gdb.ada/complete.exp that conditionally accepts a completion does
not work correctly. The code assumes that wrapping a line in "(...)?"
will make the entire line optional, but really this will only match a
blank line.
Meanwhile, I needed this same patch for a second series I'm working
on, so I've pulled this out. As it only affects Ada, I am going to
check it in.
Tom Tromey [Wed, 19 Feb 2025 15:55:37 +0000 (08:55 -0700)]
Small get_tib_address cleanups
I noticed a non-bool-like use of target_get_tib_address in
windows-tdep.c. After fixing this I thought it would be good to
document the target method; and this also lead to some non-bool-like
commentary in remote.c. This patch fixes all of these nits.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Guinevere Larsen [Mon, 17 Feb 2025 19:43:04 +0000 (16:43 -0300)]
GDB: add stabs deprecation warning
Now that stabs is deprecated, we should probably warn our users of it
before removing support, so that they have time to react and either make
themselves heard, or fix things on their end so that they can still debug
their applications.
This commit adds a new function that emits a warning whenever GDB does
stabs reading. Since there are several places where stabs is
re-invented, this warning had to be added to many places, but I think I
managed to warn everywhere relevant without duplicating warnings.
Also, the test gdb.stabs/weird.exp explicitly checks for GDB warnings
when reading stabs, so it had to be updated to account for the
deprecation warning. It is done generically, since it will be removed in
the next release anyway.
Alan Modra [Thu, 20 Feb 2025 01:19:25 +0000 (11:49 +1030)]
PR 32721, internal error in tc-i386.c:parse_register
pr30117 showed one of the assertions added by 4d1bb7955a8b was too
strict. oss-fuzz also found the second assertion to be too strict,
with this testcase distilled from 7k of garbage source:
A=%eax%%!
Y=A
Z=A
or $6,Z
PR 32721
* config/tc-i386.c (parse_register): Move "know" into
condition. Simplify.
Tom Tromey [Sat, 8 Feb 2025 02:14:35 +0000 (19:14 -0700)]
Hoist language-finding in expand_symtabs_matching
Right now, cooked_index_functions::expand_symtabs_matching computes
the language for each component of a split name, using the language of
the corresponding entry.
Instead, I think that we want to do all the comparisons using the
final entry's language. I don't think there's a way to trigger bad
behavior here right now, but with another series I'm working on, we
end up with some entries whose language can't reliably be determined;
and in this case using the final entry's language avoids issues.
I suspect we could also dispense with the per-segment name-matcher
lookup as well.
Tom Tromey [Fri, 31 Jan 2025 18:25:45 +0000 (11:25 -0700)]
Move producer checks to dwarf2_cu
This changes the various producer-checking functions to be methods on
dwarf2_cu. It adds a few new caching members as well -- every one
that could reasonably be done this way has been converted, with the
only exception being a gdbarch hook.
Note the new asserts in the accessors. Without the earlier
prepare_one_comp_unit change, these could trigger in some modes.
Tom Tromey [Fri, 31 Jan 2025 19:25:05 +0000 (12:25 -0700)]
Clean up calls to prepare_one_comp_unit
Currently, prepare_one_comp_unit is called somewhat haphazardly: it is
mostly called when a CU is read, but some places manage to instantiate
a cutu_reader* without calling it, and some code (e.g.,
read_file_scope) calls it without really needing to.
Aside from contributing to the general confusion around CU reading,
this doesn't really cause problems in the current tree. However, it
is possible for the DWARF reader to check the CU's producer before it
is ever set -- which is certainly unintended.
Tom Tromey [Sat, 8 Feb 2025 19:43:21 +0000 (12:43 -0700)]
Clean up DW_TAG_namelist handling in new_symbol
In dwarf2/read.c:new_symbol, DW_TAG_namelist is listed in the same
part of the "switch" as other tags. However, it effectively shares no
code with these. This patch splits it into its own case.
Longer term I think new_symbol should be split up drastically.
Before this patch, current_token was a global implicitly 0-initialized. Since
it is now a class field, it is not 0-initialized by default anymore. This
patch changes this.
Change-Id: I3f00b080318a70405d881ff0abe02b2c5cb1f9d8 Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 17 Feb 2025 20:54:09 +0000 (15:54 -0500)]
gdb/dwarf: add logging for CU expansion
I was trying to get an understanding of which CUs were expanded when,
and how much time it was taking. I wrote this patch to add some logging
related to that, and I think it would be useful to have upstream, to
better understand performance problems related to over-eager CU
expansion, for example.
- add DWARF_READ_SCOPED_DEBUG_START_END
- use it in process_queue, to wrap the related expansion messages
together
- add a message in maybe_queue_comp_unit when enqueuing a comp unit
- add timing information to messages in process_queue, indicating how
much time it took to expand a given symtab
- count the number of expansions done in a single call to process_queue
[dwarf-read] process_queue: start: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xc
[dwarf-read] maybe_queue_comp_unit: Queuing CU for expansion: section offset = 0x38b, queue size = 2
[dwarf-read] process_queue: Done expanding CU at offset 0xc, took 0.001s
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x38b
[dwarf-read] process_queue: Done expanding CU at offset 0x38b, took 0.000s
[dwarf-read] process_queue: Done expanding 2 symtabs.
[dwarf-read] process_queue: end: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
Change-Id: I5237d50e0c1d06be33ea83a9120b5fe1cf7ab8c2 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 17 Feb 2025 19:59:35 +0000 (14:59 -0500)]
gdb/dwarf: set is_debug_types in signatured_type constructor
This makes it more obvious that all created signatured_type objects have
this flag set.
Also, remove an unnecessary assignment in create_cus_hash_table: when
constructing the dwarf2_per_cu_data object, is_debug_types is already
initialized to 0/false.
Change-Id: I6d28b17ac77edc040172254f6970d05ebc4a47f4 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 17 Feb 2025 19:59:32 +0000 (14:59 -0500)]
gdb/dwarf: pass dwarf2_per_bfd to dwarf2_per_cu_data constructor
Pass a dwarf2_per_bfd to the constructor of dwarf2_per_cu_data and set
the per_bfd field there. All "real" instantiations of
dwarf2_per_cu_data must have a valid, non-nullptr dwarf2_per_bfd
backlink, this makes it a bit more obvious. The instantiations of
dwarf2_per_cu_data that receive a nullptr dwarf2_per_bfd are the ones
used to do hash map lookups and the ones used in selftests.
Remove an unnecessary assignment of per_bfd in
fill_in_sig_entry_from_dwo_entry: the per_bfd field is already set when
the signatured_type object is constructor (before that, it was set in
allocate_signatured_type).
Change-Id: Ifeebe55fdb1bc2de4de9c852033fafe8abdfde8a Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 17 Feb 2025 19:59:31 +0000 (14:59 -0500)]
gdb/dwarf: change some functions from "per objfile" to "per bfd"
I noticed that the following functions accept a "dwarf2_per_objfile",
but they can actually accept a less specific "dwarf2_per_bfd". This
makes it more obvious that the work they do is per BFD and not per
objfile.
Qwinci [Tue, 18 Feb 2025 18:47:51 +0000 (20:47 +0200)]
gdb/remote: don't error if qGetTIBAddr is unsupported
This change makes it possible to debug PE executables run in e.g. Qemu
without needing to set osabi to none, it breaks backtrace
and commands like finish if frame pointers are not present but SEH unwind info is.
Hui Li [Tue, 11 Feb 2025 12:18:28 +0000 (20:18 +0800)]
gdb: LoongArch: Extend the maximum number of hardware watchpoints
The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of hardware watchpoints from 8 to 14.
A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time. Modify the struct loongarch_user_watch_state
in GDB which is same with the uapi struct user_watch_state_v2.
As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.
The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:
For example, there are four kind of combinations, all of them work well.
(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.
BTW, LLDB also made this change in the related commit ff79d83caeee
("[LLDB][LoongArch] Extend the maximum number of watchpoints") [3]
Alan Modra [Wed, 19 Feb 2025 12:15:29 +0000 (22:45 +1030)]
binutils/dwarf.c debug_information leak
It is possible with fuzzed files to have num_debug_info_entries zero
after allocating space for debug_information, leading to multiple
allocations.
* dwarf.c (process_debug_info): Don't test num_debug_info_entries
to determine whether debug_information has been allocated,
test alloc_num_debug_info_entries.
gdbserver, remote: introduce "id_str" in the "qXfer:threads:read" XML
GDB prints the target id of a thread in various places such as the
output of the "info threads" command in the "Target Id" column or when
switching to a thread. A target can define what to print for a given
ptid by overriding the `pid_to_str` method.
The remote target is a gateway behind which one of many various
targets could be running. The remote target converts a given ptid to
a string in a uniform way, without consulting the low target at the
server-side.
In this patch we introduce a new attribute in the XML that is sent in
response to the "qXfer:threads:read" RSP packet, so that a low target
at the server side, if it wishes, can specify what to print as the
target id of a thread.
Note that the existing "name" attribute or the "extra" text provided
in the XML are not sufficient for the server-side low target to
achieve the goal. Those attributes, when present, are simply appended
to the target id by GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
projects / thirdparty / binutils-gdb.git / log
