Alan Modra [Sun, 16 Feb 2025 13:04:55 +0000 (23:34 +1030)]
PR 32603, more ld -w misbehaviour
Commit 8d97c1a53f3d claimed to replace all einfo calls using %F with
a call to fatal. It did so only for the ld/ directory. This patch
adds a "fatal" to linker callbacks, and replaces those calls in bfd/
too.
Andrew Oates [Sun, 16 Feb 2025 15:16:25 +0000 (16:16 +0100)]
gdb: fix color_option_def compile error (clang)
color_option_def was added in commit 6447969d0 ("Add an option with a
color type."), but not used.
The color_option_def constructor passes the wrong number of arguments
to the option_def constructor. Since color_option_def is a template and
never actually instantiated, GCC does not fail to compile this. clang
generates an error (see below).
This passes nullptr to the extra_literals_ option_def ctor argument,
which matches what filename_option_def above it does.
clang's generated error:
../../gdb/cli/cli-option.h:343:7: error: no matching constructor for initialization of 'option_def'
: option_def (long_option_, var_color,
^ ~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/cli/cli-option.h:50:13: note: candidate constructor not viable: requires 8 arguments, but 7 were provided
constexpr option_def (const char *name_,
^
../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 7 were provided
struct option_def
^
../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 7 were provided
Alan Modra [Sat, 15 Feb 2025 06:36:58 +0000 (17:06 +1030)]
PR32698, potential null pointer dereference in tekhex.c
PR 32698
* tekhex.c (find_chunk): Remove unnecessary casts.
(insert_byte): Check and return status from find_chunk.
(move_section_contents): Likewise.
(tekhex_get_section_contents, tekhex_set_arch_mach): Return
status from move_section_contents.
(first_phase): Check and return status from first_phase.
Alan Modra [Fri, 14 Feb 2025 12:40:29 +0000 (23:10 +1030)]
riscv disassembler leak
Commit 3f61a38b5e81 moved the disassembler subset_list from a static
variable to disassembler private_data. It is now malloc'd in
riscv_init_disasm_info so should be freed when disassemble_free_target
runs.
Anghelo Carvajal [Sat, 15 Feb 2025 01:30:58 +0000 (01:30 +0000)]
MIPS objdump: Add `eabi32` and `eabi64` ABI options
Extend gpr and fpr register names with names suitable for both EABIs.
Heavily inspired by the EABI documenation written by Eric Christopher,
which can be read at
https://sourceware.org/legacy-ml/binutils/2003-06/msg00436.html
MIPS/GAS/testsuite: Reuse n64 GPR disassembly for n32
The MIPS ABI register names are the same between n64 and n32, so remove
duplication and use n64 GPR disassembly output for the n32 test as well.
The tests were developed long before we gained output reuse support.
MIPS/GAS: Set default CPU to MIPS64r6 for 64-bit "img" configurations
Fix broken commit 070961b377b3 ("MIPS: Set r6 as default arch if vendor
is img") that sets up GAS in an inconsistent way where "img" vendor has
been used with a 64-bit configuration, such as `mips64-img-linux-gnu'.
In that case GAS is set up to use a 64-bit ABI by default combined with
the MIPS32r6 CPU, which is 32-bit.
Consequently GAS always fails to assemble even trivial input, producing
a message such as:
Assembler messages:
Error: -march=mips32r6 is not compatible with the selected ABI
.../gas/testsuite/gas/all/nop.s:2: Error: `gp=32' used with a 64-bit ABI
unless the defaults have been suitably overridden either for the ABI or
the CPU.
Set the default CPU to MIPS64r6 for 64-bit "img" vendor configurations
then and adjust the GAS testsuite accordingly, removing 1048 FAIL and 3
ERROR regression test results for the `mips64-img-linux-gnu' and
`mips64el-img-linux-gnu' targets each.
MIPS/GAS/testsuite: Support negated targets for default architecture
Add support for giving negated targets in the list of targets passed to
`mips_arch_create' for the purpose of setting the default architecture.
This is so that a subset of targets can be excluded from matching within
a broader set of targets.
Ivan Kokshaysky [Sat, 15 Feb 2025 01:30:58 +0000 (01:30 +0000)]
alpha, ld: remove -taso option
The -taso switch was quite useful 25 years ago for porting 32-bit
code with broken integer-pointer casting. Not anymore. The EF_ALPHA_32BIT
Linux support is going to be dropped in kernel v6.14 [1], NetBSD and OpenBSD
never had it, so there is no point in keeping the -taso option around.
Also remove alpha special case that uses -taso from gdb.base/dump.exp
in gdb testsuite.
Andrew Burgess [Thu, 13 Feb 2025 16:43:39 +0000 (16:43 +0000)]
gdb/testsuite: clean ups in gdb.python/py-source-styling.exp
The top comment in gdb.python/py-source-styling.exp was completely
wrong, clearly a cut&paste job from elsewhere. Write a comment that
actually reflects what the test does.
I've also moved the allow_python_tests check earlier in the file.
And I changed some 'return -1' into just 'return'. I'm not aware that
the '-1' adds any value.
I also folded a 'pass $gdb_test_name' into the preceding gdb_assert,
which I think is neater.
There is no change in what is actually being tested after this commit.
Andrew Burgess [Thu, 6 Feb 2025 15:02:37 +0000 (15:02 +0000)]
gdb/tui: use maybe_update for source centring in an extra case
I noticed that, with recent versions of GDB, when the TUI is enabled
before the inferior is started, the source code display is not as
helpful as it used to be. Here's a simple test program being
displayed using GDB 15.2, at this point the inferior has not started,
all I've done is 'tui enable':
gdb: adjust the default place of 'list' to main's prologue
I don't think the new behaviour is really a problem with that commit,
rather, when using 'tui enable' before the inferior has started GDB
ends up calling tui_source_window_base::rerender(), and then passes
through the code path which calls update_source_window_with_addr().
When using 'tui enable' after the inferior has started, GDB again
calls tui_source_window_base::rerender(), but this time has a frame,
and so takes the second code path, which centres the selected source
line, and then calls update_source_window.
The point is that the update_source_window_with_addr() path doesn't
include the logic to centre the source line.
Before the above commit this was fine as GDB's default location would
be prior to main, and so we got the "good" TUI output. After the
above commit the default location is now main's prologue, and without
the centring logic, the first line shown is main's prologue.
I propose fixing this by having update_source_window_with_addr() call
maybe_update(). This will first check if the requested line is
already visible, and if not, show the requested line with centring
applied.
It's not identical to the old behaviour, but that was never the
objective, we do however, see the context around main's prologue,
which will usually be enough to see the function name and return type,
which I think is useful.
Andrew Burgess [Thu, 6 Feb 2025 12:16:48 +0000 (12:16 +0000)]
gdb/tui: update maybe_update to take gdbarch
This is a refactor to setup for the next commit.
The maybe_update function currently takes a frame_info_ptr&, however,
it only uses this to get the frame's gdbarch.
In the next commit I want to call maybe_update when I have a gdbarch,
but no frame_info_ptr& (the inferior hasn't even started).
So, update maybe_update to take the gdbarch, and update the callers to
pass that through. Most callers already have the gdbarch to hand, but
in one place I do need to extract this from the frame_info_ptr&.
There should be no user visible changes after this commit.
Tom Tromey [Fri, 14 Feb 2025 00:45:23 +0000 (17:45 -0700)]
Handle DW_FORM_data4 in read-debug-names.c
The recent .debug_names patches caused the writer to emit
DW_FORM_data4. Unfortunately the reader did not handle this form.
This patch updates the reader to handle a few DW_FORM_data* forms.
The complaint that is there went unnoticed -- I only found this when
debugging a failure in another series. More evidence, IMO, that
complaints should be removed.
I think the reason the failure itself went unnoticed is that the
symbol table code in gdb often works by accident, and in particular in
small programs like the ones in the test suite, it's often the case
that a CU will be expanded for some other reason, causing the test to
pass without really touching the index code. The aforementioned
series is aimed at fixing this.
It would probably be good to unify the abbrev/form code to some
degree, but it's mildly a pain as some forms don't make sense here and
because we recently discovered other issues with gdb's DW_FORM_data*
handling.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 26 Nov 2024 05:32:21 +0000 (00:32 -0500)]
gdbserver: use `gdb::unordered_map`
Replace the few uses of `std::unordered_map` in gdbserver with
`gdb::unordered_map`.
The only one of these that is likely to ever see a lot of elements is
probably `process_info::m_ptid_thread_map`. It was added precisely to
improve performance when there are a lot of threads, so I guess using
`gdb::unordered_map` here won't hurt. I changed the others too, since
it's easy.
Change-Id: Ibc4ede5245551fdd7717cb349a012d05726f4363 Reviewed-By: Stephan Rohr <stephan.rohr@intel.com>
Simon Marchi [Wed, 12 Feb 2025 15:52:51 +0000 (10:52 -0500)]
gdb/dwarf: use term "shard" instead of "index"
A bit more changes as in 8e745eac7db3 ("gdb/dwarf: rename
cooked_index::m_vector to m_shards"). I think it's clearer if the term
"index" is reserved for the whole thing, while "shard" or "index shard"
are used for the parts.
Change-Id: I457bb0016a70f3f9918f4a3c3977262a7801705b Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 13 Feb 2025 20:08:29 +0000 (15:08 -0500)]
gdb/python/dap: prefix internal attributes with underscore
I'm currently reading the DAP code, and I think this would help. This
is pretty much standard Python style, we do it as some places but not
others. I think it helps readability, by saying that this attribute
isn't mean to be accessed outside the class.
A similar pass could be done for internal methods, I haven't done that.
Change-Id: I8e8789b39adafe62d14404d19f7fc75e2a364e01 Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Sat, 25 Jan 2025 13:00:12 +0000 (13:00 +0000)]
gdb: only update m_last_subfile after writing a line table entry
While working on another patch which changes how we parse the line
DWARF line tables I noticed what I think is a minor bug in how we
process the line tables.
What I noticed is that my new line table parser was adding more END
markers into the parsed table than GDB's current approach. This
difference was observed when processing the debug information for
libstdc++.
Here is the line table from the new test, this is a reasonable
reproduction of the problem case that I observed in the actual debug
line table:
Contents of the .debug_line section:
dw2-skipped-line-entries-1.c:
File name Line number Starting address View Stmt
dw2-skipped-line-entries-1.c 101 0x40110a x
/tmp/dw2-skipped-line-entries-2.c:
dw2-skipped-line-entries-2.c 201 0x401114 x
/tmp/dw2-skipped-line-entries-3.c:
dw2-skipped-line-entries-3.c 301 0x40111e x
/tmp/dw2-skipped-line-entries-1.c:
dw2-skipped-line-entries-1.c 102 0x401128 x
dw2-skipped-line-entries-1.c 103 0x401128 x
dw2-skipped-line-entries-1.c 104 0x401128 x
The problem is caused by the entry for line 211. Notice that this
entry is at the same address as the previous entries. Further, the
entry for 211 is a non-statement entry, while the previous entries are
statement entries.
As the entry for line 211 is a non-statement entry, and the previous
entries at that address are statement entries in a different symtab,
it is thought that it is better to prefer the earlier entries (in
dw2-skipped-line-entries-1.c), and so the entry for line 211 will be
discarded.
As GDB parses the line table it switches between the 3 symtabs (based
on source filename) adding the relevant entries to each symtab.
Additionally, as GDB switches symtabs, it adds an END entry to the
previous symtab.
The problem then is that, for the line 211 entry, this is the only
entry in dw2-skipped-line-entries-2.c before we switch symtab again.
But the line 211 entry is discarded. This means that GDB switches
from dw2-skipped-line-entries-1.c to dw2-skipped-line-entries-2.c, and
then on to dw2-skipped-line-entries-3.c without ever adding an entry
to dw2-skipped-line-entries-2.c.
And here then is the bug. GDB updates its idea of the previous symtab
not when an entry is written into a symtab, but every time we change
symtab.
In this case, when we switch to dw2-skipped-line-entries-3.c we add
the END marker to dw2-skipped-line-entries-2.c, even though no entries
were written to dw2-skipped-line-entries-2.c. At the same time, no
END marker is ever written into dw2-skipped-line-entries-1.c as the
dw2-skipped-line-entries-2.c entry (for line 211) was discarded.
Here is the 'maint info line-table' for dw2-skipped-line-entries-1.c
before this patch:
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 101 0x000000000040110a 0x000000000040110a Y
1 END 0x0000000000401114 0x0000000000401114 Y
2 102 0x0000000000401128 0x0000000000401128 Y
3 103 0x0000000000401128 0x0000000000401128 Y
4 104 0x0000000000401128 0x0000000000401128 Y
5 104 0x000000000040113c 0x000000000040113c
6 105 0x0000000000401146 0x0000000000401146 Y
7 END 0x0000000000401150 0x0000000000401150 Y
And after this patch:
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 101 0x000000000040110a 0x000000000040110a Y
1 END 0x0000000000401114 0x0000000000401114 Y
2 102 0x0000000000401128 0x0000000000401128 Y
3 103 0x0000000000401128 0x0000000000401128 Y
4 104 0x0000000000401128 0x0000000000401128 Y
5 END 0x0000000000401132 0x0000000000401132 Y
6 104 0x000000000040113c 0x000000000040113c
7 105 0x0000000000401146 0x0000000000401146 Y
8 END 0x0000000000401150 0x0000000000401150 Y
Notice that we gained an extra entry, the END marker that was added at
position #5 in the table.
Now, does this matter? I cannot find any bugs that trigger because of
this behaviour.
So why fix it? First, the current behaviour is inconsistent, as we
switch symtabs, we usually get an END marker in the previous symtab.
But occasionally we don't. I don't like things that are inconsistent
for no good reason. And second, as I said, I want to change the line
table parsing. To do this I want to check that my new parser creates
an identical table to the current parser. But my new parser naturally
"fixes" this inconsistency, so I have two choices, do extra work to
make my new parser bug-compatible with the current one, or fix the
current one. I'd prefer to just fix the current line table parser.
There's a test that includes the above example and checks that the END
markers are put in the correct place. But as I said, I've not been
able to trigger any negative behaviour from the current solution, so
there's no test that exposes any broken behaviour.
Jan Beulich [Fri, 14 Feb 2025 09:47:50 +0000 (10:47 +0100)]
x86: drop redundant i.operands checks from output_disp()
The opcode space, major opcode, and - where applicable - opcode
extension checks fully qualify the insns we're after; operand matching
has been done far earlier, so wrong operand counts cannot occur here.
Jan Beulich [Fri, 14 Feb 2025 08:35:07 +0000 (09:35 +0100)]
x86: correct ISA-used version recording
Updating should be based solely on the current instruction. For example,
recording of VEX-encoded insns as v3 should be independent of there
being earlier AMX insns.
Further for BASELINE only a very limited set of the
GNU_PROPERTY_X86_FEATURE_2_* bits should actually be taken into account:
Most of the bits represent advanced (later) features (XSAVE, XSAVEOPT,
and XSAVEC for example being part of v3).
Jan Beulich [Fri, 14 Feb 2025 08:33:18 +0000 (09:33 +0100)]
gas: fix rs_fill_nop listing
In commit a0094f1a70e1 ("gas: make .nops output visible in listing") I
was wrongly assuming fr_fix would be zero for rs_fill_nop, when that's
only a side effect of listing_newline() inserting dummy frags, but only
when file/line did actually change from the previous invocation. This is
in particular not going to be true when the .nops directive isn't the
first statement on a line.
Jan Beulich [Fri, 14 Feb 2025 08:32:35 +0000 (09:32 +0100)]
x86/APX: make .insn extended-EVEX capable
So far tricks had to be played to use .insn to encode extended-EVEX
insns; the X4 bit couldn't be controlled at all. Extend the syntax just
enough to cover all features, taking care to reject invalid feature
combinations (albeit aiming at being as lax there as possible, to offer
users as much flexibility as we can - we don't, after all, know what
future will bring).
In a pre-existing testcase replace all but one .byte; the one that needs
to remain wants to have EVEX.U clear in a way that's neither
controllable via AVX10/256 embedded rounding (would otherwise also set
EVEX.ND), nor via the index register (EVEX.X4), as there's no memory
operand. For one of the converted instances ModR/M.mod needs correcting:
An 8-bit displacement requires that to be 1, not 2. Also adjust source
comments to better represent what the bad insns mimic.
Hau Hsu [Fri, 14 Feb 2025 02:40:53 +0000 (10:40 +0800)]
RISC-V: Make SSAMOSWAP.W available for rv64
Previously we limited SSAMOSWAP.W only available on RV32, but it should
be available on RV64 as well.
See
https://github.com/riscv/riscv-cfi/blob/main/src/cfi_backward.adoc
https://github.com/riscv/riscv-isa-manual/blob/702a3e6e843235a2a13b918ae6938b04f8974ffc/src/unpriv-cfi.adoc#L789
Alan Modra [Thu, 13 Feb 2025 01:46:26 +0000 (12:16 +1030)]
dlltool memory leaks
dlltool copies strings with strdup all over the place, seeming to take
the attitude that anything might be modified. That leads to lots of
memory leaks. Fixing the leaks by removing the strdup calls of course
means you need to take good care that strings *aren't* modified. This
isn't as easy as it sounds due to functions like xlate that have
const char* params but then manage to modify the strings. I've fixed
xlate, but if I've missed something somewhere then this patch likely
will break dlltool. Testsuite coverage of dlltool isn't good.
The leaks in defparse.y are small. It also is a little work to verify
that all the strings I'm freeing in defparse.y are in fact malloc'd,
which is no doubt why the leaks are there.
Using bfd_xalloc in make_one_lib_file and functions called from there
results in memory being freed automatically at the bfd_close in
make_one_lib_file, without any fuss.
The patch also makes use of xasprintf to replace xmalloc followed by
sprintf.
* defparse.y (opt_name2): Free incoming ID strings after
adding prefix/suffix.
* dlltool.c (struct ifunct): Constify char* fields.
(struct iheadt, struct dlist): Likewise.
(set_dll_name_from_def, def_heapsize, def_stacksize),
(def_section, assemble_file): Use xasprintf.
(def_name, def_library): Free dll_name and name.
(def_description, new_directove): Don't strdup incoming args.
(append_import): Likewise.
(def_import): Free module after appending dllext.
(run): Free temp_base.
(scan_filtered_symbols): Don't segfault on NULL strchr return.
Remove unnecessary strdup.
(scan_drectve_symbols): Likewise. Constify pointers.
Use bfd_malloc_and_get_section. Use xmemdup.
(add_excludes): Use xasprintf and xstrdup.
(gen_exp_file): Free xlate return. Constify pointer to suit
struct changes. Free copy.
(xlate): Always copy arg. Use xasprintf and xstrdup.
(make_imp_label): Add bfd arg. Use bfd_xalloc.
(gen_lib_file): Adjust to suit.
(make_one_lib_file): Likewise. Use bfd_xalloc for section data
and relocs. Simplify code calling xlate, and free xlate return.
(dll_name_list_free_contents): Flatten recursion.
(mangle_defs): Free d_export_vec.
(main): Formatting. Use xasprintf.
* resres.c (write_res_id): Free section data.
Alan Modra [Thu, 13 Feb 2025 00:29:51 +0000 (10:59 +1030)]
gas: replace bfd_alloc with notes_alloc
bfd_alloc can return NULL on out-of-memory so code needs to check the
return value and print an error. That check was missing in write.c.
notes_alloc won't return NULL, instead the underlying obstack_alloc
prints an OOM message and the process exits. This is more convenient,
and when the bfd_alloc memory is attached to the gas output bfd it is
released only slightly before the notes obstack.
* config/obj-macho.c (obj_mach_o_set_indirect_symbols): Use
notes_calloc rather than bfd_zalloc.
* write.c (set_symtab): Use notes_alloc.
Alan Modra [Wed, 12 Feb 2025 21:55:01 +0000 (08:25 +1030)]
gas obj-coff memory leaks
This patch addresses memory leaks in gas that show up when running the
testsuite on x86_64-w64-mingw32. The seh_ctx_cur, and weak sym naming
leaks can occur many times during assembly. The symbol hook and
section leaks are not so important since this memory needs to persist
until closing the output bfd.
* config/obj-coff-seh.c (do_seh_endproc): Free seh_ctx_cur and
its fields.
* config/obj-coff-seh.h (struct seh_context): Remove unused
"next" field.
* config/obj-coff.c (coff_obj_symbol_new_hook): Use notes_alloc
for aux entries.
(coff_obj_symbol_clone_hook): Likewise.
(obj_coff_def): Don't strdup name unless we need to do so
for tc_canonicalize_symbol_name. Free after making symbol.
(weak_name2altname, weak_altname2name): Return a char*.
(weak_uniquify): Use notes_concat.
(pecoff_obj_set_weak_hook, pecoff_obj_clear_weak_hook): Free name
returned by weak_name2altname.
(coff_frob_symbol): Similarly for weak_altname2name.
(obj_coff_section): Use notes_memdup0.
* symbols.h: Add include guard.
(notes_memdup0): New inline function.
Tom Tromey [Thu, 13 Feb 2025 03:43:38 +0000 (20:43 -0700)]
Remove assumption from py-symbol.exp
The current py-symbol.exp test makes an assumption about which symbol
will be returned first. I don't think gdb should really make promises
about the order in which the symbols are listed, though, and a series
I am working on changes this behavior. This patch changes the test to
merely ensure that both symbols are returned.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Kevin Buettner [Thu, 13 Feb 2025 17:53:17 +0000 (10:53 -0700)]
Update my maintenance areas in MAINTAINERS file
I've dropped maintenance of the mep target. Additionally, I'm removed
myself as an authorized committer for PowerPC, ia64, AIX, and
GNU/Linux PPC native.
gdb, testsuite: Rename set_sanitizer procedures to append_environment.
The procedures set_sanitizer_1, set_sanitizer and set_sanitizer_default
are used for the configuration of ASAN specific environment variables.
However, they are actually generic. Rename them to append_environment*
so that their purpose is more clear.
Tom Tromey [Wed, 12 Feb 2025 15:49:30 +0000 (08:49 -0700)]
Reorder gnatmake arguments in inline-section-gc.exp, again
Tom de Vries pointed out that commit 8cfa1fc4 ("Reorder gnatmake
arguments in inline-section-gc.exp") caused a regression with an older
version of dejagnu.
This patch works around that problem by further reordering the
arguments to gnatmake and also arranging to leave gnatmake in "-margs"
mode.
Rohr, Stephan [Thu, 1 Aug 2024 17:46:18 +0000 (19:46 +0200)]
gdb: remove check for minimal symbols in 'start_command'
GDB aborts the 'start' command if the minimal symbols cannot be
resolved. On Windows, GDB reads the minimal symbols from the COFF
header of the PE file. The symbol table is deprecated and the
number of symbols in the COFF header may be zero:
FILE HEADER VALUES
8664 machine (x64)
E number of sections 66E889EC time date stamp Mon Sep 16 21:41:32 2024
FB400 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
GDB is not able to read the minimal symbols; the `start' command fails
with an error:
(gdb) start
No symbol table loaded. Use the "file" command.
Manually inserting a breakpoint in main works fine:
(gdb) tbreak main
Temporary breakpoint 1 at 0x14000100c: file test.cpp, line 6.
(gdb) run
Starting program: C:\test-clang
Temporary breakpoint 1, main () at test.cpp:6
6 std::cout << "Hello World.\n";
Remove the check entirely; a 'NOT_FOUND_ERROR' is thrown if 'main'
cannot be resolved. The error is consumed in 'create_breakpoint ()'
and an error message is displayed to the user.
Approved-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Simon Marchi [Mon, 10 Feb 2025 16:54:58 +0000 (11:54 -0500)]
gdb/dwarf: rename cooked_index::m_vector to m_shards
I think that is clearer and helps readability.
Rename a few iteration variables from "index" or "idx" to "shard". In
my mental model, the "index" is the whole thing, so it's confusing to
use that word when referring to shards.
Change-Id: I208cb839e873c514d1f8eae250d4a16f31016148 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 10 Feb 2025 16:54:57 +0000 (11:54 -0500)]
gdb/dwarf: remove cooked_index::vec_type
I find this typedef to be confusing. The name is a bit too generic, so
it's not clear what it represents. When using the typedef for a
cooked_index_shard unique pointer, I think that spelling out the vector
type is not overly long.
Change-Id: I99fdab5cd925c37c3835b466ce40ec9c1ec7209d Approved-By: Tom Tromey <tom@tromey.com>
Kito Cheng [Mon, 20 Jan 2025 11:24:36 +0000 (19:24 +0800)]
RISC-V: Add .bfloat16 directive
RISC-V already support bfloat16 instruciton like Zfbfmin, Zvfbfmin and
Zvfbfwma, so I think it's reasonable to add .bfloat16 directive to
support bfloat16 data type.
And the code logic mostly support by common code already.
Nelson Chu [Thu, 6 Feb 2025 13:47:37 +0000 (21:47 +0800)]
RISC-V: Move all global static target stuff into private data for disassembler.
I got a request said that the JDK multi-thread compiler may be broken
if two or more threads are trying to print/disassemble stuff, and filling
the disassemble_info, setting callbacks, and grabbing the function pointer
to disasm at the same time. Since such as the target global static stuff,
including subset of extensions and mapping symbol stuff, seems to only be
one globally. Ideally, for dis-assembler, all global static target stuff
should/can be better to be defined into the target private data, since they
are target-dependency.
opcodes/
* riscv-dis.c: Moved all global static target-dependency stuff into
riscv_private_data, including architecture and mapping symbol stuff.
(set_default_riscv_dis_options): Updated since global static target-
dependency stuff are moved into riscv_private_data.
(parse_riscv_dis_option_without_args): Likewise.
(parse_riscv_dis_option): Likewise.
(parse_riscv_dis_options): Likewise.
(maybe_print_address): Likewise.
(print_reg_list): Likewise.
(riscv_get_spimm): Likewise.
(print_insn_args): Likewise.
(riscv_disassemble_insn): Likewise.
(riscv_update_map_state): Likewise.
(riscv_search_mapping_symbol): Likewise.
(riscv_data_length): Likewise.
(print_insn_riscv): Likewise. Call the riscv_init_disasm_info before
parsing any disassembler options, since the related stuff are moved
into riscv_private_data.
(riscv_init_disasm_info): Likewise. Parse and set the architecture
string and privileged spec version since riscv_get_disassembler is
no longer needed.
(riscv_get_disassembler): Removed.
(disassemble_free_riscv): Only free the subset_list if
riscv_private_data exsits.
* disassemble.c (disassembler): Since riscv_get_disassembler is
removed, call to print_insn_riscv.
* disassemble.h: Removed extern riscv_get_disassembler.
Flavio Cruz [Mon, 3 Feb 2025 04:15:22 +0000 (23:15 -0500)]
Port GDB to Hurd x86_64.
This port extends the existing i686 port to support x86_64 by reusing
existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the trampoline code
is adapted.
* gdb/config/i386/nm-i386gnu.h: renamed to gdb/config/i386/nm-x86-gnu.h
and adapt it for x86_64.
* gdb/config/i386/i386gnu.mn: renamed to gdb/config/i386/nm-x86-gnu.mn
and reuse it for x86_64.
* gdb/configure.host: recognize gnu64 as a host.
* gdb/configure.nat: recognize gnu64 host and update existing i386gnu to
reuse the new shared files.
* gdb/configure.tgt: recognize x86_64-*-gnu* triplet and use
amd64-gnu-tdep.c.
* gdb/i386-gnu-tdep.c: added i386_gnu_thread_state_reg_offset that is
copied from i386-gnu-nat.c. This makes it similar to amd64.
* gdb/i386-gnu-nat.c: rename it to x86-gnu-nat.c since we reuse this for
i386 and amd64. Updated REG_ADDR to use one of the structures. Added
VALID_REGISTER to make sure it's a register we can provide at this time
(not all of them are available in amd64). FLAGS_REGISTER is either rfl
or efl depending on the arch. Renamed functions and class from i386 to x86
whenever they can be reused.
Clean up after commit 112cf77b1855 ("MIPS: use is_whitespace()") and
untangle the code flow in the handling of forced size suffixes, noting
that owing to the loop right above the only data `c' can hold at this
point is '\0', '.', or a white-space character. No functional change.
MIPS16/GAS: Reject instructions that end with a dot
Fix a regression from commit 3fb49709438e ("MIPS16/GAS: Fix forced size
suffixes with argumentless instructions") and reject MIPS16 instructions
that end with a dot and no forced size suffix following, e.g.:
Clean up after commit 29c108c96106 ("MIPS: Support `-gnuabi64' target
triplet suffix for 64-bit Linux targets") and discard individual MIPS
"want64=true" settings, the use of which has been superseded by commit 42429eacb42f ("Require a 64-bit bfd_vma for MIPS ELF") back in 2013[1].
I spotted some places where tui_win_info::refresh_window() was being
called when suppress_output was false. This means that there is no
tui_batch_rendering in place on the call stack, and so, after that
commit, we might be performing more wrefresh() calls than necessary.
Before the above commit we would have been calling wnoutrefresh() and,
due to the missing tui_batch_rendering, there might have been a delay
before doupdate() was called.
To (hopefully) make screen updates smoother, this commit adds
tui_batch_rendering in a few places where it is possible that there
might be multiple window updates performed, this will mean the final
write to screen is deferred until the tui_batch_rendering goes out of
scope.
Other than possibly smother screen updates, there should be no user
visible changes after this commit.
Andrew Burgess [Sat, 8 Feb 2025 21:32:05 +0000 (21:32 +0000)]
gdb/tui: remove unnecessary wmove call from tui_status_window
I've been looking recently at when the TUI calls wnoutrefresh vs
wrefresh, and the ordering of other screen update actions relative to
these calls.
I noticed in tui_status_window::rerender() a call to wmove() that is
placed after the refresh_window() call. This surely means that the
cursor is moved, but, this update is not sent to the screen.
But we call wmove() at the start of tui_status_window::rerender()
before anything is sent to the screen, so the final wmove() call is
pointless as far as I can tell.
I propose removing it. This is trivial, but removing pointless work
like this slowly makes the TUI code easier to understand.
There should be no user visible changes after this commit.
Guinevere Larsen [Mon, 13 Jan 2025 17:04:04 +0000 (14:04 -0300)]
gdb: Deprecate stabs debug info
GCC has deprecated stabs generation in GCC 12 and entirely removed it in
GCC 13, which was released in April 2023. At the time it was proposed
that GDB deprecate stabs as well, but the decision was to support it a
bit longer. With this patch, it'll be deprecated on GDB 17, and removed
on GDB 18, which following the current cadence, will be released early
2026, meaning we will have supported stabs for nearly 3 years longer
than GCC, which I think is reasonable.
As pointed out in the previous discussion on this topic[1], there are
several existing issues on the code, and none of the current maintainers
knows how to fix it. Unless someone steps up to fix this before the
removal on GDB 18, I don't see why we should keep this old code that
breaks all conventions of modern debuginfo readers and doesn't even
work, instead of being able to further advance adjacent code.
Finally, deprecating and removing stabs will make a.out/dbx inferiors be
essentially unsupported, as the only debuginfo GDB supports for those
formats is stabs, meaning users would only have assembly-level debugging
for that format. With that in mind, this commit deprecates the a.out/dbx
format as well.
Simon Marchi [Sun, 9 Feb 2025 05:51:04 +0000 (00:51 -0500)]
gdb/dwarf: create multiple cooked index shards when reading .debug_names
New in v2:
- install address map in a single shard
- update test gdb.mi/mi-sym-info.exp to cope with the fact that
different symbols could be returned when using --max-results
When playing with the .debug_names reader, I noticed it was
significantly slower than the DWARF scanner. Using a "performance"
build of GDB (with optimization, no runtime sanitizer enabled, etc), I
measure with the following command on a rather large debug info file
(~4 GB):
$ time ./gdb -q -nx --data-directory=data-directory <binary> -iex 'maint set dwarf sync on' -batch
This measures the time it takes for GDB to build the cooked index (plus
some startup and exit overhead). I have a version of the binary without
.debug_names and a version with .debug_names added using gdb-add-index.
The results are:
- without .debug_names: 7.5 seconds
- with .debug_names: 24 seconds
This is a bit embarrassing, given that the purpose of .debug_names is to
accelerate things :). The reason is that the .debug_names processing is
not parallelized at all, while the DWARF scanner is heavily
parallelized.
The process of creating the cooked index from .debug_names is roughly in
two steps:
1. scanning of .debug_names and creation of cooked index entries (see
mapped_debug_names_reader::scan_all_names)
2. finalization of the index, name canonicalization and sorting of the
entries (see cooked_index::set_contents).
This patch grabs a low hanging fruit by creating multiple cooked index
shards instead of a single one during step one. Just doing this allows
the second step of the processing to be automatically parallelized, as
each shard is sent to a separate thread to be finalized.
With this patch, I get:
- without .debug_names: 7.5 seconds
- with .debug_names: 9.7 seconds
Not as fast as we'd like, but it's an improvement.
The process of scanning .debug_names could also be parallelized to shave
off a few seconds. My profiling shows that out of those ~10 seconds of
excecution, about 6 are inside scan_all_names. Assuming perfect
parallelization with 8 threads, it means that at best we could shave
about 5 seconds from that time, which sounds interesting. I gave it a
shot, but it's a much more intrusive change, I'm not sure if I will
finish it.
This patch caused some regressions in gdb.mi/mi-sym-info.exp with the
cc-with-debug-names board, in the test about the `--max-results` switch.
It appears at this test is relying on the specific symbols returned when
using `--max-results`. As far as I know, we don't guarantee which
specific symbols are returned, so any of the matching symbols could be
returned.
The round robin method used in this patch to assign index entries to
shards ends up somewhat randomizing which CU gets expanded first during
the symbol search, and therefore which order they appear in the
objfile's CU list, and therefore which one gets searched first.
I meditated on whether keeping compunits sorted within objfiles would
help make things more stable and predictable. It would somewhat, but it
wouldn't remove all sources of randomness. It would still possible for
a call to `expand_symtabs_matching` to stop on the first hit. Which
compunit gets expanded then would still be dependent on the specific
`quick_symbol_functions` internal details / implementation.
Commit 5b99c5718f1c ("[gdb/testsuite] Fix various issues in
gdb.mi/mi-sym-info.exp") had already started to make the test a bit more
flexible in terms of which symbols it accepts, but with this patch, I
think it's possible to get wildly varying results. I therefore modified
the test to count the number of returned symbols, but not expect any
specific symbol.
Change-Id: Ifd39deb437781f72d224ec66daf6118830042941 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sun, 9 Feb 2025 05:51:02 +0000 (00:51 -0500)]
gdb/dwarf: allow for cooked_index_shard::m_addrmap to be nullptr
The following patch makes the .debug_names reader create multiple cooked
index shards, only one of them having an address map. The others will
have a nullptr address map.
Change the code using cooked_index_shard::m_addrmap to account for the
fact that it can be nullptr.
Change-Id: Id05b974e661d901dd43bb5ecb3a8fcfc15abc7ed Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sun, 9 Feb 2025 05:51:01 +0000 (00:51 -0500)]
gdb/dwarf: write offset to parent entry for DW_IDX_parent
New in v2:
- add doc
- fix computation of offset in entry pool
Due to a mistake in the DWARF 5 spec, the way that GDB interprets
DW_IDX_parent when generating and reading .debug_names is not correct.
In Section 6.1.1.2, the parent index entry attribute is described as:
Parent debugging information entry, a reference to the index entry for
the parent. This is represented as the offset of the entry relative to
the start of the entry pool.
But in Table 6.1, DW_IDX_parent is described as:
Index of name table entry for parent
These two contradict each other. The former is the correct one and the
latter is an unfortunate leftover from an earlier version of the
proposal, according to [1]. It does make sense, because pointing to a
name table entry is ambiguous, while poiting to an index entry directly
is not. Unfortunately, GDB implemented pointing to a name table entry.
Changes on the writer side:
- For each written pool entry, remember the offset within the pool.
- Change the DW_IDX_parent form to DW_FORM_data4.
Using DW_FORM_udata isn't an option, because we don't know the actual
value when doing the first pass of writing the pool (see next point),
so we wouldn't know how many bytes to reserve, if we used a
variable-size encoding.
Using a fixed 4 bytes encoding would be an issue if the entry pool
was larger than 4 GiB, but that seems unlikely.
Note that clang uses DW_FORM_ref4 for this, but I'm not sure it is
appropriate, since forms of the reference class are specified as
referring "to one of the debugging information entries that describe
the program". Since we're not referring to a DIE, I decided to stay
with a form of the "constant" class. I think that readers will be
able to understand either way.
- Write a dummy 4 byte number when writing the pool, then patch those
values later. This is needed because parents can appear before their
children in the pool (there's no way to ensure that parents always
appear before their children), so we might now know at first what
value to put in.
- Add a `write_uint` method to `class data_buf` to support that use
case of patching a value in the middle of the data buffer.
- Simplify the type of `m_name_to_value_set`, we no longer need to
track the index at which a name will be written at.
- Produce a new augmentation string, "GDB3", to be able to distinguish
"old" and "new" indexes. It would be possible for a reader to
distinguish the two semantics of DW_IDX_parent using the form.
However, current versions of GDB don't do that, so they would be
confused trying to read a new index. I think it is preferable to use
a new augmentation string so that they will reject a new index
instead.
Changes on the reader side:
- Track the GDB augmentation version, in addition to whether the
augmentation string indicates the index was produced by GDB.
- When reading index entries, maintain a "pool offset" -> "cooked index
entry" mapping, to be able to find parents by pool offset.
- When resolving parents, keep the existing behavior of finding parents
by name table index if the augmentation string is "GDB2. Otherwise,
look up parents by pool offset. This assumes that .debug_names from
other producers (if/when we add support for reading them) use pool
offsets for DW_IDX_parent. This at least what clang does.
- Simplify augmentation string comparison a bit by using array views.
Update the "Extensions to ‘.debug_names’" section of the documentation
to reflect the new augmentation string version.
Tested by:
- manually producing executables with "GDB2" and "GDB3" .debug_names
sections and reading them.
- running the testsuite with the cc-with-debug-names board
Trying to pass an array to this function doesn't work, as template
argument deduction fails:
test.c:698:8: error: no matching function for call to ‘func(int [12])’
698 | func (array);
| ~~~~~^~~~~~~
test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’
686 | void func(gdb::array_view<T> view) {}
| ^~~~
test.c:686:6: note: template argument deduction/substitution failed:
test.c:698:8: note: mismatched types ‘gdb::array_view<U>’ and ‘int*’
698 | func (array);
| ~~~~~^~~~~~~
Similarly, trying to compare a view with an array doesn't work. This:
int array[12];
gdb::array_view<int> view;
if (view == array) {}
... fails with:
test.c:698:8: error: no matching function for call to ‘func(int [12])’
698 | func (array);
| ~~~~~^~~~~~~
test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’
686 | void func(gdb::array_view<T> view) {}
| ^~~~
test.c:686:6: note: template argument deduction/substitution failed:
test.c:698:8: note: mismatched types ‘gdb::array_view<U>’ and ‘int*’
698 | func (array);
| ~~~~~^~~~~~~
With this new overload, we can do:
func (gdb::make_array_view (array));
and
if (view == gdb::make_array_view (array)) {}
This is not ideal, I wish that omitting `gdb::make_array_view` would
just work, but at least it allows creating an array view and have the
element type automatically deduced from the array type.
If someone knows how to make these cases "just work", I would be happy
to know how.
Change-Id: I6a71919d2d5a385e6826801d53f5071b470fef5f Approved-By: Tom Tromey <tom@tromey.com>
Hui Li [Thu, 6 Feb 2025 12:29:56 +0000 (20:29 +0800)]
gdb: LoongArch: Improve the handling of atomic sequence
In the current code, when using software single-step to debug atomic
instruction sequence, the execution of the atomic instruction sequence
may not be completed normally.
Here is a test with setting a software watchpoint to execute in software
single-step mode:
$ cat test.c
int a = 0;
int main()
{
a = 1;
return 0;
}
$ gcc -g test.c -o test
$ gdb test
..
(gdb) start
..
Temporary breakpoint 1, main () at test.c:4
4 a = 1;
(gdb) set can-use-hw-watchpoints 0
(gdb) n
5 return 0;
(gdb) watch a
Watchpoint 2: a
(gdb) c
Continuing.
At this point, the program continues to execute and can not exit
normally because it incorrectly handled the following ll/sc atomic
sequence in __run_exit_handlers () from /lib64/libc.so.6 during
software single-step execution.
The root cause of this problem is that a breakpoint was inserted in the
middle of ll/sc atomic sequence during software single-step execution.
The execution result of the atomic instruction sequence is disrupted,
causing the program unable to complete the execution of the atomic
instruction sequence normally.
Further explanation, if the current pc is 0x00007ffff7df7a50, it is a
conditional branch instruction, breakpoint should only be set at the
jump destination address (0x00007ffff7df7a64, which is outside of the
ll/sc atomic instruction sequence) and should not set at the address
of pc + 4 (0x00007ffff7df7a54, which is in the middle of ll/sc atomic
sequence).
Modify a judgment condition in loongarch_deal_with_atomic_sequence()
to ensure that breakpoints can not be inserted in the middle of ll/sc
atomic sequence to address such issues.
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Andrew Burgess [Wed, 15 Jan 2025 15:09:30 +0000 (15:09 +0000)]
gdb: fix selecting tail-call frames by name
I noticed that attempting to select a tail-call frame using 'frame
function NAME' wouldn't work:
(gdb) bt
#0 func_that_never_returns () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:49
#1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
#2 0x00000000004011a5 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:70
(gdb) frame function func_that_tail_calls
No frame for function "func_that_tail_calls".
(gdb) up
#1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
59 func_that_never_returns ();
(gdb) disassemble
Dump of assembler code for function func_that_tail_calls:
0x000000000040117a <+0>: push %rbp
0x000000000040117b <+1>: mov %rsp,%rbp
0x000000000040117e <+4>: call 0x40116c <func_that_never_returns>
End of assembler dump.
(gdb)
The problem is that the 'function' mechanism uses get_frame_pc() and
then compares the address returned with the bounds of the function
we're looking for.
So in this case, the bounds of func_that_tail_calls are 0x40117a to
0x401183, with 0x401183 being the first address _after_ the function.
However, because func_that_tail_calls ends in a tail call, then the
get_frame_pc() is 0x401183, the first address after the function. As
a result, GDB fails to realise that frame #1 is inside the function
we're looking for, and the lookup fails.
The fix is to use get_frame_address_in_block, which will return an
adjusted address, in this case, 0x401182, which is within the function
bounds. Now the lookup works:
(gdb) frame function func_that_tail_calls
#1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59
59 func_that_never_returns ();
(gdb)
I've extended the gdb.base/frame-selection.exp test to cover this
case.
Alan Modra [Mon, 10 Feb 2025 02:44:16 +0000 (13:14 +1030)]
tc-i386.c fix for oss-fuzz gas fuzzing
oss-fuzz fuzz_as is seriously broken with respect to gas static
variables, so much so that most fuzz_as reports should simply be
ignored. This patch is a fix for
https://oss-fuzz.com/testcase-detail/6268463220654080
H.J. Lu [Mon, 10 Feb 2025 00:38:57 +0000 (08:38 +0800)]
x86-64: Use x86_64_elf_howto_table for standard relocations
For standard relocations, use x86_64_elf_howto_table, instead of calling
elf_x86_64_rtype_to_howto.
* elf64-x86-64.c (elf_x86_64_tls_transition): Use
x86_64_elf_howto_table, instead of elf_x86_64_rtype_to_howto.
(elf_x86_64_convert_load_reloc): Use x86_64_elf_howto_table,
instead of elf_x86_64_rtype_to_howto, for R_X86_64_PC32.
Tom Tromey [Thu, 6 Feb 2025 21:07:59 +0000 (14:07 -0700)]
Add dwarf2_per_bfd::start_reading
The cooked index "start_reading" method can only be called after the
dwarf2_per_bfd "index_table" member is set. This patch refactors this
code a little to centralize this constraint, adding a new
dwarf2_per_bfd::start_reading method and another (virtual) method to
dwarf_scanner_base.
This removes some casts, but also is also useful to support another
series I'm working on where the .gdb_index is rewritten.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
But when I did this I ran into a regression in the test script
gdb.base/condbreak-multi-context.cc which I think is actually an issue
with this test.
The test relies on creating a multi-location breakpoint with a
condition and having GDB disable some of the locations as the
condition is only valid in some of the locations.
Here's an example of the test creating one such breakpoint:
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context...
(gdb) break func if a == 10
warning: failed to validate condition at location 1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 3, disabling:
No symbol "a" in current context.
Breakpoint 1 at 0x401142: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23
1.2 y 0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31
1.3 N* 0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
(gdb)
Notice that only location 1.2 is actually enabled, 1.1 and 1.3 are
disabled due to the condition 'a == 10' not being valid.
However, notice that this b/p is created before GDB has started the
inferior. What I noticed is that if I first start the inferior then I
get a different behaviour:
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context...
(gdb) start
Temporary breakpoint 1 at 0x40110e: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc, line 49.
Starting program: /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context
Temporary breakpoint 1, main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:49
49 aobj.func ();
(gdb) break func if a == 10
Breakpoint 2 at 0x401142: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
stop only if a == 10
2.1 y 0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23
2.2 y 0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31
2.3 y 0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39
(gdb)
Notice that now all three locations are valid.
What's actually happening is that, on my machine libm.so contains a
global symbol 'a' which for 2.1 and 2.3 is being used to satisfy the
condition.
I don't believe this is actually the intention of the test, this is
just an unfortunate consequence of name collision.
The test actually relies on the local variables 'a' and 'c', and my
libm.so contains a global version of both.
So I propose that we just update the test, I've gone for the super
inventive 'aaa' and 'ccc'. With this change, after starting the
inferior I now see the expected behaviour where only one of the three
locations is enabled.
However, while I'm fixing this I figure that it would be nice if the
test checked both cases, creating the breakpoints before starting the
inferior, and after starting the inferior.
So I've updated the test to check both cases. This has meant
converting the mostly linear test script into a set of parameterised
functions which I then call with a flag to indicate if the inferior
should be started before of after creating the breakpoints.
Approved-By: Tom Tromey <tom@tromey.com> Tested-By: Hannes Domani <ssbssa@yahoo.de>
Richard Allen [Sun, 9 Feb 2025 16:49:01 +0000 (10:49 -0600)]
gprof: fix odd inst len hist scale calculation
With even instruction sizes, this rounding never truncated.
Xtensa CPUs mostly use 2-3 byte instructions, and this can lead
to a histogram being captured with an odd length address range.
This small truncation prevented gprof from parsing gmon.out files
containing multiple histograms when at least one of them has an
odd address range length and another has any other address range.
The pr326664 fuzzer testcase has two .debug_info sections, one
SHF_ALLOC, one not. SEC_DEBUGGING is never set for SHF_ALLOC sections
that happen to be named .debug_info, nor are they compressed. However
in this case we get an output section that is both SEC_ALLOC and
SEC_DEBUGGING which confuses code setting up the output section names
(.zdebug_* for compressed debug sections), resulting in a -1u index
into a string table.
PR 32664
* elf.c (elf_fake_sections): Do not delay naming of SEC_ALLOC
sections.
Andrew Burgess [Mon, 23 Dec 2024 15:59:29 +0000 (15:59 +0000)]
gdb/mi: include ranges in =library-unloaded event
Having looked at the dlmopen support in GDB, it occurred to me that
the current MI =library-unloaded event doesn't incude enough
information to be useful.
Consider the gdb.mi/mi-dlmopen.exp test, this test loads libraries
into multiple linker namespaces, and then unloads these libraries.
We should probably figure out a way to include the linker namepsace ID
in GDB's output, e.g. in the =library-loaded and =library-unloaded MI
events, and in the output of 'info sharedlibrary'. But this commit is
not about doing that.
This commit includes the 'ranges' information in the =library-unloaded
event output. This is the same ranges information as is included in
the =library-loaded output. Even without the linker namespace ID,
this should allow MI consumers to figure out which library instance is
being unloaded.
Here is the 'info sharedlibrary' output for mi-dlmopen.exp at the
point where all the shared libraries are loaded:
Notice that dlmopen-lib.1.so is loaded multiple times. Here is the
=library-unloaded event when one copy of this library is unloaded
before this patch:
It is not possible, given this information, to know which copy of
dlmopen-lib.1.so has actually been unloaded. An MI consumer would
need to query the full shared library list and update from that
information.
The new 'ranges' field allows an MI consumer to uniquely identify
which library instance was just unmapped. A frontent could,
e.g. update a library list with no need to query the full shared
library list.
To include the 'ranges' field I updated mi_interp::on_solib_unloaded
to call a new helper function. The new helper function is split out
from the existing mi_output_solib_attribs. I was tempted to just call
mi_output_solib_attribs, but doing so would mean that the
'symbols-loaded' field was also added to the =library-unloaded event,
however, the docs for 'symbols-unloaded' on =library-loaded says:
The @var{symbols-loaded} field is emitted only for backward
compatibility and should not be relied on to convey any useful
information.
And it seemed silly to add a fields to =library-unloaded, which I
would then document as something that should be ignored. The new
helper function means I can avoid emitting the 'symbols-loaded'
field.
I have also added a 'still-in-use' field. When true this indicates
that the library was removed from the inferior's library list, but the
mapping was not removed from the inferior's address space as there is
another copy of the library that is still using the library. In the
above list, notice that ld-linux-x86-64.so.2 appears 3 times, but each
instance is mapped as 0x00007ffff7fca000. When one copy of
ld-linux-x86-64.so.2 is unloaded, here's the event:
Andrew Burgess [Thu, 19 Dec 2024 11:56:16 +0000 (11:56 +0000)]
gdb: include a still-mapped flag in solib unload notification
Consider the gdb.base/dlmopen.exp test case. The executable in this
test uses dlmopen to load libraries into multiple linker namespaces.
When a library is loaded into a separate namespace, its dependencies
are also loaded into that namespace.
This means that an inferior can have multiple copies of some
libraries, including the dynamic linker, loaded at once.
However, glibc optimises at least the dynamic linker case. Though the
library appears to be mapped multiple times (it is in the inferior's
solib list multiple times), there is really only one copy mapped into
the inferior's address space. Here is the 'info sharedlibrary' output
on an x86-64/Linux machine once all the libraries are loaded:
Notice that every copy of /lib64/ld-linux-x86-64.so.2 is mapped at the
same address.
As the inferior closes the libraries that it loaded, the various
copies of the dynamic linker will also be unloaded.
Currently, when this happens GDB calls notify_solib_unloaded, which
triggers the gdb::observers::solib_unloaded observer. This observer
will call disable_breakpoints_in_unloaded_shlib (in breakpoint.c),
which disables any breakpoints in the unloaded solib.
The problem with this, is that, when the dynamic linker (or any solib)
is only really mapped once as is the case here, we only want to
disable breakpoints in the library when the last instance of the
library is unloaded.
The first idea that comes to mind is that GDB should not emit the
solib_unloaded notification if a shared library is still in use,
however, this could break MI consumers.
Currently, every time a copy of ld-linux-x86-64.so.2 is unloaded,
GDB's MI interpreter will emit a =library-unloaded event. An MI
consumer might use this to update the library list that it displays to
the user, and fewer notify_solib_unloaded calls will mean fewer MI
events, which will mean the MI consumer's library list could get out
of sync with GDB.
Instead I propose that we extend GDB's solib_unloaded event to add a
new flag. The new flag indicates if the library mapping is still in
use within the inferior. Now the MI will continue to emit the
expected =library-unloaded events, but
disable_breakpoints_in_unloaded_shlib can check the new flag, when it
is true (indicating that the library is still mapped into the
inferior), no breakpoints should be disabled.
The other user of the solib_unloaded observer, in bsd-uthread.c,
should, I think, do nothing if the mapping is still in use. This
observer is also disabling breakpoints when a library is unloaded.
Most of the changes in this commit relate to passing the new flag
around for the event. The interesting changes are mostly in solib.c,
where the flag value is determined, and in breakpoint.c and
bsd-uthread.c, where the flag value is read.
There's a new MI test, the source of which is mostly copied from the
gdb.base/dlmopen.exp test. This new test is checking we see all the
expected =library-unloaded events.
Andrew Burgess [Thu, 19 Dec 2024 10:41:40 +0000 (10:41 +0000)]
gdb/testsuite: restructure gdb.base/dlmopen.exp
In the next commit I want to add more tests to the dlmopen.exp script.
Doing this will be easier if the dlmopen.exp script was structured so
that the current tests were contained inside separatate procs. So
this commit moves all of the current tests within dlmopen into two
procs, and then calls these.
There should be no changes to what is actually being tested in this
commit.
I started off reviewing that series, but wanted to explore some
alternative strategies for solving the problems this series addresses.
However, this patch I think is super useful, so I've taken it mostly
as it was in the original series.
I have made a few minor cleanups, and I've also added some more tests.
Any bugs should be considered mine (Andrew's), but I've left the
original author (Michael Weghorn) in place as the GDB side changes are
mostly their work.
The function execv_argv::init_for_no_shell (gdb/nat/fork-inferior.c),
is passed a single string ALLARGS containing all of the inferior
arguments, and contains some custom code for splitting this argument
string into a vector of separate arguments. This function is used
when startup-with-shell is off (which is not the default).
The algorithm in this function was just splitting on whitespace
characters, and ignoring any quoting, so for example:
(gdb) set startup-with-shell off
(gdb) set args "first arg" second_arg
would result in three arguments ("first), (arg"), and (second_arg)
being passed to the inferior (the parenthesis are not part of the
parsed arguments).
This commit replaces this custom argument splitting with a use of the
existing gdb_argv class (which uses the libiberty buildargv function).
This does a better job of supporting quoting and escaping, so for the
example given above we now pass two arguments (first arg)
and (second_arg), which is certainly what I would have expected as a
GDB user.
This commit changes the 'execv_argv' class accordingly and drops the
optimization to have all the 'char *' in 'm_argv' point to a single
string rather than allocating a separate string for each arg. This is
needed because we are now going to be stripping some escaping from the
arguments, for example:
(gdb) set startup-with-shell off
(gdb) set args "literal \$"
In this case we will pass the single argument (literal $) to the
inferior, the escaping backslash will be removed. This might seem
strange as usually the backslash would be stripped by the shell, and
now we have no shell. However, I think the consistent behaviour is a
good thing; whether we start with a shell or not the escaping will be
removed.
Using gdb_argv will mean that quote characters are also stripped. If
we consider the first example again:
(gdb) set startup-with-shell off
(gdb) set args "first arg" second_arg
This is now going to pass (first arg) and (second_arg), the quotes
have been removed. If the user did want the original behaviour then
they are going to have to now do this:
(gdb) set startup-with-shell off
(gdb) set args \"first arg\" second_arg
or they could do this:
(gdb) set startup-with-shell off
(gdb) set args '"first' 'arg"' second_arg
This commit also extends the three tests that cover inferior argument
passing to cover the case where 'startup-with-shell' is off. All of
these new tests pass for native targets, but there are still problems
when using remote targets.
The remote target problems arise because of how escaping is handled
while passing arguments to remote targets. I have a larger series
that aims to address this issue:
This patch was originally part of that series, but getting a 14 patch
series reviewed is not easy, so I've pulled this patch out on its own
for now, and the new tests are (rather crudely) disabled for remote
targets.
My hope is to work through my 14 patch series posting all of the
patches in smaller groups, which will hopefully make reviewing
easier. As more of that series gets merged, the remote argument
handling will improve, before, eventually, no tests will need to be
disabled.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392
Tested-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Keith Seitz <keiths@redhat.com>
Alan Modra [Sun, 9 Feb 2025 09:45:02 +0000 (20:15 +1030)]
PR32663, ld buffer overflow reading .debug_info
When reading debug info to print an error message, we'll be reading
the debug info off disk, not using edited debug info. sec->rawsize
if non-zero is the correct size.
PR 32663
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Use
bfd_get_section_limit_octets to properly size debug sections.
Alan Modra [Sun, 9 Feb 2025 02:22:23 +0000 (12:52 +1030)]
PR32662, segv in _bfd_generic_link_output_symbols
asymbol flags zero can result from certain combinations of ELF st_info
binding and type. asymbol section is set to bfd_abs_section for
genuine absolute symbols and also ones with a bogus st_shndx. A
fuzzed ELF object with such a symbol can tickle a bug in generic
linker code added by commit d3a65d4dea to avoid an abort, resulting
in a segfault. This patch fixes the segfault by removing the
sym->section->owner->flags test. I think it should be OK to exclude
all symbols without any BSF flags set, not just IR symbols.
PR 32662
* linker.c (_bfd_generic_link_output_symbols): Exclude all
symbols with zero flags. Replace abort with assertion.
Tidy logic.
Andrew Burgess [Wed, 5 Feb 2025 20:12:03 +0000 (20:12 +0000)]
gdb/tui: use wrefresh if output is not surpressed
Recent work in the TUI has improved GDB's use of the curses
wnoutrefresh and doupdate mechanism, which improves performance by
batching together updates and then doing a single set of writes to the
screen when doupdate is finally called.
The tui_batch_rendering type is a RAII class which, in its destructor,
calls doupdate to send the batched updates to the screen.
However, if there is no tui_batch_rendering active on the call stack
then any wnoutrefresh calls will remain batched but undisplayed until
the next time doupdate happens to be called.
This problem can be seen in PR gdb/32623. When an inferior is started
the 'Starting program' message is not immediately displayed to the
user.
The 'Starting program' message originates from run_command_1 in
infcmd.c, the message is sent to the current_uiout, which will be the
TUI ui_out. After the message is sent, ui_out::flush() is called,
here's the backtrace when that happens:
#0 tui_file::flush (this=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42
#1 0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at ../../src/gdb/utils.c:1531
#2 0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at ../../src/gdb/utils.c:1539
#3 0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at ../../src/gdb/cli-out.c:250
#4 0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at ../../src/gdb/ui-out.h:263
#5 0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449
#6 0x00000000009f599a in run_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:511
And if we check out tui_file::flush (tui-file.c) we can see that this
just calls tui_win_info::refresh_window(), which in turn, just uses
wnoutrefresh to batch any pending output.
The problem is that, in the above backtrace, there is no
tui_batch_rendering active, and so there will be no doupdate call to
flush the output to the screen.
We could add a tui_batch_rendering into tui_file::flush. And
tui_file::write. And tui_file::puts .....
... but that all seems a bit unnecessary. Instead, I propose that
tui_win_info::refresh_window() should be changed. If suppress_output
is true (i.e. a tui_batch_rendering is active) then we should continue
to call wnoutrefresh(). But if suppress_output is false, meaning that
no tui_batch_rendering is in place, then we should call wrefresh(),
which immediately writes the output to the screen.
Testing but PR gdb/32623 was a little involved. We need to 'run' the
inferior and check for the 'Starting program' message. But DejaGNUU
can only check for the message once it knows the message should have
appeared. But, as the bug is that output is not displayed, we don't
have any output hints that the inferior is started yet...
In the end, I have the inferior create a file in the test's output
directory. Now DejaGNU can send the 'run' command, and wait for the
file to appear. Once that happens, we know that the 'Starting
program' message should have appeared.
Alexandre Oliva [Sat, 8 Feb 2025 06:12:24 +0000 (03:12 -0300)]
sparc: define _GLOBAL_OFFSET_TABLE_ when referenced
GCC testsuite gcc.dg/20050321-2.c hit link errors on undefined
_GLOBAL_OFFSET_TABLE_. The compiler output referenced only
_GLOBAL_OFFSET_TABLE_-offsets to set it up, and to compute the
GOT-relative address of local symbols, none of which triggered the
machinery that enabled the creation of the dynamic section, so
_GLOBAL_OFFSET_TABLE_ ended up undefined.
Enable the dynamic section if we find a relocation involving
_GLOBAL_OFFSET_TABLE_. While at that, optimize checks for references
to it.
for bfd/ChangeLog
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Check for
_GLOBAL_OFFSET_TABLE_ references early, then compare hashed
symbols instead of strings.
(_bfd_sparc_elf_relocate_section): Compare hashed symbols.
for ld/ChangeLog
* testsuite/ld-sparc/got-def.s: New test.
* testsuite/ld-sparc/sparc.exp: Add it.
Alan Modra [Fri, 7 Feb 2025 08:13:00 +0000 (18:43 +1030)]
Re: x86-64: Estimate output section layout before sizing dynamic sections
Commit 73ab3b9825 results in a warning compiling eelf_x86_64_sol2.c,
breaking --enable-targets=all builds.
warning: ‘elf_x86_64_before_allocation’ defined but not used
Fix this by hooking up the chain of before_allocation functions, so
x86_64-solaris2 calls elf_x86_64_before_allocation, while
sparc64-solaris2 calls gldelf64_sparc_sol2_before_allocation.
Lancelot SIX [Fri, 7 Feb 2025 11:09:09 +0000 (11:09 +0000)]
gdb/testsuite: fix "up to main" in gdb.base/corefile-exec-context.exp
On ubuntu systems with libc debug info available (libc6-dbg), I see the
following failures for the gdb.base/corefile-exec-context.exp testcase:
show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb) PASS: gdb.base/corefile-exec-context.exp: show args
up
#1 __pthread_kill_internal (signo=6, threadid=133859295332160) at ./nptl/pthread_kill.c:78
78 in ./nptl/pthread_kill.c
(gdb) FAIL: gdb.base/corefile-exec-context.exp: move up to main
This failures is because the pattern used to parse the output of `up`
is not expecting what is seen when debugging information is present for
those frames.
This patch adjusts the pattern to allow both possible outputs.
Tested on ubuntu-22.04 and ubuntu24.04 with libc6-dbg installed for gdb
build with --with-separate-debug-dir=/usr/lib/debug.
Change-Id: I217d4b20006d0ecdb4b7a71eeb8d01597ec5ac63 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Fri, 7 Feb 2025 15:17:52 +0000 (16:17 +0100)]
[gdb/corefiles] Fix segfault in core_target_open
On x86_64-freebsd, with test-case gdb.arch/i386-biarch-core.exp I run into a
segfault here in corelow.c:core_target_open:
...
{
gdb::unique_xmalloc_ptr<char> failing_command = make_unique_xstrdup
(bfd_core_file_failing_command (current_program_space->core_bfd ()));
if (failing_command != nullptr)
gdb_printf (_("Core was generated by `%s'.\n"),
failing_command.get ());
}
...
where bfd_core_file_failing_command returns nullptr, so the segfault happens
somewhere during "strdup (nullptr)".
There doesn't seem to be a need to make a copy of the string, so fix this by
dropping the make_unique_xstrdup.
Tested on x86_64-linux.
Tested the test-case on x86_64-freebsd.
Approved-By: Tom Tromey <tom@tromey.com>
PR corefiles/32634
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32634
Tom de Vries [Fri, 7 Feb 2025 14:57:24 +0000 (15:57 +0100)]
[gdb/build] Fix x86_64-w64-mingw32 build by avoiding SCNx8
With an x86_64-w64-mingw32 targeted cross-build on x86_64-linux, I run into:
...
gdb/cli/cli-decode.c: \
In function 'ui_file_style::color parse_cli_var_color(const char**)':
gdb/cli/cli-decode.c:2917:41: error: expected ')' before 'SCNx8'
int parsed_args = sscanf (*args, "#%2" SCNx8 "%2" SCNx8 "%2" SCNx8 "%n",
...
Apparantly, the definition of SCNx8 is missing in inttypes.h.
Rewrite the sscanf call to use SCNx32, which is available.
Tested by:
- completing aforementioned cross-build, and
- build & test on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
MayShao-oc [Fri, 7 Feb 2025 09:31:42 +0000 (10:31 +0100)]
x86: Support x86 Zhaoxin PadLock XMODX instructions
The CPUID EDX bit[28] indicates its enablement, and it includes REP
XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates
the support of modular exponentiation feature, both REP XMODEXP and
REP MONTMUL2 use it.
H.J. Lu [Thu, 30 Jan 2025 00:48:45 +0000 (08:48 +0800)]
x86-64: Estimate output section layout before sizing dynamic sections
When sizing dynamic sections, elf_x86_64_scan_relocs converts GOTPCREL
relocations to R_X86_64_PC32, R_X86_64_32S or R_X86_64_32 for local
symbols. But at that time, since the output section layout is unknown,
the local symbol values can't be determined. Later linker issues an
error if the converted relocation overflows when resolving relocations
against these local symbols. Update the x86-64 ELF linker to estimate
output section layout before sizing dynamic sections and use the
preliminary output section layout info to skip the GOTPCREL relocation
conversion if the converted relocation overflows.
bfd/
PR ld/32591
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Add an input
section argument. Use the lowest-addressed section to estimate
the __ehdr_start symbol value. Don't convert relocation if the
converted relocation will overflow.
projects / thirdparty / binutils-gdb.git / log
