When building -gsplit-dwarf and -fdebug-types-section in DWARF 5, the
resulting .dwo files will typically have a .debug_info.dwo section with
multiple type units followed by one compile unit:
$ llvm-dwarfdump -F -color a-test.dwo | grep ' Unit'
0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector<int, std::allocator<int> >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4)
0x000008a4: Type Unit: length = 0x00000099, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'allocator<int>', type_signature = 0x496a8791a842701b, type_offset = 0x0023 (next unit at 0x00000941)
...
0x000015c1: Compile Unit: length = 0x00000f58, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0xe8e359820d1c5803 (next unit at 0x0000251d)
In open_and_init_dwo_file, we call create_dwo_cus_hash_table, which
scans the section, looking for compile units, then call
create_dwo_debug_types_hash_table, which scans the section again,
looking for type units. It would make more sense to scan the section
just once and handle both compile and type units at the same time.
To achieve this, add create_dwo_unit_hash_tables, which knows how to
handle both unit kinds in a single scan. It replaces
create_dwo_cus_hash_table and create_dwo_debug_type_hash_table. Change
open_and_init_dwo_file to call it.
Note that I removed the DWARF version check in open_and_init_dwo_file
when processing .debug_type.dwo sections: in DWARF 5, the
.debug_type.dwo sections will just not exist, so the
`dwo_file->sections.types` vector will be empty.
Change-Id: I6e51d0ca06c258e0bf0e59927d62ae2df314a162
Approved-By: Tom Tromey <tom@tromey.com>
create_dwo_cus_hash_table is implemented by creating a cutu_reader
(which is somewhat heavy) for all units in a .dwo file. The purpose of
this cutu_reader is to be able to get the DWO ID, if it is specified by
a DW_AT_GNU_dwo_id attribute.
In DWARF 5, however, the DWO ID is available in the CU header. We can
access it without accessing the DIEs, by just reading the header, which
is more lightweight. Add a new code path to create_dwo_cus_hash_table
that does that. The logic is copied from
create_dwo_debug_type_hash_table, which does this already.
This change helps circumvent a performance problem I want to fix (the
same I was trying to fix in this patch [1]) when loading a file built
with -gdwarf-5, -gsplit-dwarf and -fdebug-types-section. In this
configuration, the produced .dwo files contain one compile unit and many
type units each. All units in a given .dwo share the same abbrev table.
Creating a cutu_reader for each unit meant re-reading the same abbrev
table over and over. What's particularly bad is that this is done with
the dwo_lock held, preventing other indexing threads from making
progress.
To give a rough idea, here's the time take by each worker to index units
before this patch (on a rather large program):
Time for "DWARF indexing worker": wall 18.627, user 0.885, sys 0.042, user+sys 0.927, 5.0 % CPU
Time for "DWARF indexing worker": wall 18.888, user 0.862, sys 0.042, user+sys 0.904, 4.8 % CPU
Time for "DWARF indexing worker": wall 19.172, user 1.848, sys 0.069, user+sys 1.917, 10.0 % CPU
Time for "DWARF indexing worker": wall 19.297, user 1.544, sys 0.051, user+sys 1.595, 8.3 % CPU
Time for "DWARF indexing worker": wall 19.545, user 3.408, sys 0.084, user+sys 3.492, 17.9 % CPU
Time for "DWARF indexing worker": wall 19.759, user 4.221, sys 0.117, user+sys 4.338, 22.0 % CPU
Time for "DWARF indexing worker": wall 19.789, user 4.187, sys 0.105, user+sys 4.292, 21.7 % CPU
Time for "DWARF indexing worker": wall 19.825, user 4.933, sys 0.135, user+sys 5.068, 25.6 % CPU
And the times with this patch:
Time for "DWARF indexing worker": wall 0.163, user 0.089, sys 0.029, user+sys 0.118, 72.4 % CPU
Time for "DWARF indexing worker": wall 0.176, user 0.096, sys 0.041, user+sys 0.137, 77.8 % CPU
Time for "DWARF indexing worker": wall 0.265, user 0.167, sys 0.054, user+sys 0.221, 83.4 % CPU
Time for "DWARF indexing worker": wall 0.353, user 0.257, sys 0.060, user+sys 0.317, 89.8 % CPU
Time for "DWARF indexing worker": wall 0.524, user 0.399, sys 0.088, user+sys 0.487, 92.9 % CPU
Time for "DWARF indexing worker": wall 0.648, user 0.517, sys 0.107, user+sys 0.624, 96.3 % CPU
Time for "DWARF indexing worker": wall 0.657, user 0.523, sys 0.107, user+sys 0.630, 95.9 % CPU
Time for "DWARF indexing worker": wall 0.753, user 0.612, sys 0.120, user+sys 0.732, 97.2 % CPU
[1] https://inbox.sourceware.org/gdb-patches/20250326200002.136200-8-simon.marchi@efficios.com/
Change-Id: I34a422577e4c3ad7d478ec6df12a0e44d284c249
Approved-By: Tom Tromey <tom@tromey.com>
In DWARF 5 (and even previous versions, with type units), compile units
are just one type of units. In many places, we still use "compile
units" when in reality it would be better to talk about "units" (unless
we specifically want to talk about compile units).
Rename comp-unit-head.{c.h} to unit-head.{c,h}, and do a big pass of
renames in it to remove the specific mentions of compile units, where in
fact we want to talk about units in general.
Change-Id: Ia06c90ccb25756c366f269a12620f2f7c8378adb
Approved-By: Tom Tromey <tom@tromey.com>
I'm investigating some issues where GDB takes a lot of time to start
up (read: for the DWARF index to be ready to do anything useful).
Adding those scoped_time_it instances helped me gain some insights about
where GDB spends time. I think they would be useful to have upstream,
to make investigating future problems easier. It would also be useful
to be able to give some numbers in the commit messages.
Here's an example of what GDB outputs:
Time for "minsyms install worker": wall 0.045, user 0.040, sys 0.004, user+sys 0.044, 97.8 % CPU
Time for "minsyms install worker": wall 0.511, user 0.457, sys 0.048, user+sys 0.505, 98.8 % CPU
Time for "minsyms install worker": wall 1.513, user 1.389, sys 0.111, user+sys 1.500, 99.1 % CPU
Time for "minsyms install worker": wall 1.688, user 1.451, sys 0.102, user+sys 1.553, 92.0 % CPU
Time for "minsyms install worker": wall 1.897, user 1.518, sys 0.089, user+sys 1.607, 84.7 % CPU
Time for "minsyms install worker": wall 2.811, user 2.558, sys 0.231, user+sys 2.789, 99.2 % CPU
Time for "minsyms install worker": wall 3.257, user 3.049, sys 0.188, user+sys 3.237, 99.4 % CPU
Time for "minsyms install worker": wall 3.617, user 3.089, sys 0.211, user+sys 3.300, 91.2 % CPU
Time for "DWARF indexing worker": wall 19.517, user 0.894, sys 0.075, user+sys 0.969, 5.0 % CPU
Time for "DWARF indexing worker": wall 19.807, user 0.891, sys 0.086, user+sys 0.977, 4.9 % CPU
Time for "DWARF indexing worker": wall 20.270, user 1.559, sys 0.119, user+sys 1.678, 8.3 % CPU
Time for "DWARF indexing worker": wall 20.329, user 1.878, sys 0.147, user+sys 2.025, 10.0 % CPU
Time for "DWARF indexing worker": wall 20.848, user 3.483, sys 0.224, user+sys 3.707, 17.8 % CPU
Time for "DWARF indexing worker": wall 21.088, user 4.285, sys 0.295, user+sys 4.580, 21.7 % CPU
Time for "DWARF indexing worker": wall 21.109, user 4.501, sys 0.274, user+sys 4.775, 22.6 % CPU
Time for "DWARF indexing worker": wall 21.198, user 5.087, sys 0.319, user+sys 5.406, 25.5 % CPU
Time for "DWARF skeletonless type units": wall 4.024, user 3.858, sys 0.115, user+sys 3.973, 98.7 % CPU
Time for "DWARF add parent map": wall 0.092, user 0.086, sys 0.004, user+sys 0.090, 97.8 % CPU
Time for "DWARF finalize worker": wall 0.278, user 0.241, sys 0.009, user+sys 0.250, 89.9 % CPU
Time for "DWARF finalize worker": wall 0.307, user 0.304, sys 0.000, user+sys 0.304, 99.0 % CPU
Time for "DWARF finalize worker": wall 0.727, user 0.719, sys 0.000, user+sys 0.719, 98.9 % CPU
Time for "DWARF finalize worker": wall 0.913, user 0.901, sys 0.003, user+sys 0.904, 99.0 % CPU
Time for "DWARF finalize worker": wall 0.776, user 0.767, sys 0.004, user+sys 0.771, 99.4 % CPU
Time for "DWARF finalize worker": wall 1.897, user 1.869, sys 0.006, user+sys 1.875, 98.8 % CPU
Time for "DWARF finalize worker": wall 2.534, user 2.512, sys 0.005, user+sys 2.517, 99.3 % CPU
Time for "DWARF finalize worker": wall 2.607, user 2.583, sys 0.006, user+sys 2.589, 99.3 % CPU
Time for "DWARF finalize worker": wall 3.142, user 3.094, sys 0.022, user+sys 3.116, 99.2 % CPU
Change-Id: I9453589b9005c3226499428ae9cab9f4a8c22904
Approved-By: Tom Tromey <tom@tromey.com>
New in v2:
- actually use m_enabled in the constructor and destructor
- output using gdb_stdlog->write_async_safe instead of gdb_printf
scoped_time_it is a small utility that measures and prints how much time
a given thread spent in a given scope. Similar to the time(1) command,
it prints the time spent in user mode, system mode, and the wall clock
time. It also prints the CPU utilization percentage, which is:
(user + sys) / wall
This can help spot cases where the workload is not well balanced between
workers, or the CPU utilization is not optimal (perhaps due to
contention around a lock for example).
To use it, just add it in some scope. For instance, a subsequent patch
adds it here:
workers.add_task ([this, task_count, iter, last] ()
{
scoped_time_it time_it ("DWARF indexing worker");
process_cus (task_count, iter, last);
});
On destruction, if enabled, it prints a line showing the time spent by
that thread, similar to what time(1) prints.
The example above prints this (one line for each worker thread):
Time for "DWARF indexing worker": wall 0.173, user 0.120, sys 0.034, user+sys 0.154, 89.0 % CPU
Time for "DWARF indexing worker": wall 0.211, user 0.144, sys 0.047, user+sys 0.191, 90.5 % CPU
Time for "DWARF indexing worker": wall 0.368, user 0.295, sys 0.057, user+sys 0.352, 95.7 % CPU
Time for "DWARF indexing worker": wall 0.445, user 0.361, sys 0.072, user+sys 0.433, 97.3 % CPU
Time for "DWARF indexing worker": wall 0.592, user 0.459, sys 0.113, user+sys 0.572, 96.6 % CPU
Time for "DWARF indexing worker": wall 0.739, user 0.608, sys 0.115, user+sys 0.723, 97.8 % CPU
Time for "DWARF indexing worker": wall 0.831, user 0.677, sys 0.140, user+sys 0.817, 98.3 % CPU
Time for "DWARF indexing worker": wall 0.949, user 0.789, sys 0.144, user+sys 0.933, 98.3 % CPU
The object is only enabled if per_command_time (controlled by "maint set
per-command time") is true at construction time. I wanted to avoid
adding a new command for now, but eventually if there are too many
scoped_time_it around the code base and we want to be able to enabled
them selectively (e.g. just the ones in the DWARF reader, or in the
symbol searching functions, etc), we could have a dedicated command for
that.
I added this functionality to GDB because it relies on gdb_printf and
per_command_time, but if we ever need it in gdbsupport, I'm sure we
could find a way to put it there.
Change-Id: I5416ac1448f960f44d85f8449943d994198a271e
Approved-By: Tom Tromey <tom@tromey.com>
It is completely unrelated to run_time_clock, so I don't think it makes
sense to have it as a static function there.
Move it to be a free function named "get_run_time".
Change-Id: I0c3e4d3cc44ca37e523c94d72f7cd66add95645e
Approved-By: Tom Tromey <tom@tromey.com>
DWARF says that a base type can have DW_AT_bit_size, without
DW_AT_byte_size. However, gdb does not correctly handle this; in
fact, it crashes, as pointed out in this LLVM merge request:
https://github.com/llvm/llvm-project/pull/137123
This patch reworks the base type size logic a bit to handle this
situation.
Tested-by: Kevin Buettner <kevinb@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>
While reading through gdb-patches backlog after a return
from PTO, I noticed that a newly added file was licensed
with "MIT", and that license was not listed in Fedora's
gdb.spec file. [Fedora no longer supports "effective"
licenses.]
That lead me to this simple script which generates a list
of all the newly added files between two given commits and
scans these files for licenses.
Example usage:
bash$ cd /path/to/binutils-gdb/gdb
bash$ ./contrib/license-check-new-files.sh -s gdb-15-branchpoint gdb-16-branchpoint
Scanning directories gdb*/...
gdb/contrib/common-misspellings.txt: no longer in repo?
gdb/contrib/spellcheck.sh: no longer in repo?
gdbsupport/unordered_dense.h: MIT
I don't think anything in here is Fedora- or RPM-specific,
so I'd like to submit this for consideration for inclusion
in contrib/. I believe other distros may find it useful.
Approved-By: Tom Tromey <tom@tromey.com>
With test-case gdb.base/ptype.exp and gcc 15 I run into:
...
(gdb) ptype old_fptr^M
type = double (*)(void)^M
(gdb) FAIL: $exp: ptype old_fptr (compiler doesn't emit unprototyped types)
...
Since C23, non-prototype function declarations are no longer supported, so
"double (*old_fptr) ()" is interpreted as "double (*old_fptr) (void)".
We could try to fix this by detecting the language dialect used, and accepting
the output in that case, but that feels fragile.
We could try to fix this by hard-coding the language dialect, but that doesn't
work for all compilers.
So instead, we opt for the simplest solution: just accept this output, and
produce a pass.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
When running test-case gdb.python/py-objfile.exp with gcc 15, we get:
...
(gdb) p main^M
$2 = {int (void)} 0x40066c <main>^M
(gdb) FAIL: $exp: print main with debug info
...
The source file declares main as "int main ()"
...
and until C23 this meant a non-prototype function declaration and we'd have:
...
(gdb) p main^M
$2 = {int ()} 0x40066c <main>^M
...
However, starting C23 "int main ()" is simply equivalent to "int main (void)".
Fix this by:
- declaring main as "int main (void)" in the test-case, and
- updating the regexp to expect an "int (void)" prototype.
Likewise in gdb.base/jit-bfd-name.exp.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
In test-case gdb.base/options.exp, in proc test_completer_recognizes we have:
...
set expected_re [string_to_regexp $input_line]
test_gdb_complete_unique $input_line $expected_re
...
However, the first thing we do in proc test_gdb_complete_unique is to apply
string_to_regexp to the second argument:
...
proc test_gdb_complete_unique {
input_line
complete_line
{append_char " "}
{max_completions false}
{testname ""}
} {
set complete_line_re [string_to_regexp $complete_line]
test_gdb_complete_unique_re \
$input_line \
$complete_line_re \
$append_char \
$max_completions\
$testname
}
...
This happens to not cause any FAILs at the moment, but this should be done
only once.
Fix this not using string_to_regexp in proc test_completer_recognizes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.tui/tui-layout-asm.exp with target board
dwarf5-fission-debug-types, the test-case fails and I get a core dump:
...
# of unexpected core files 1
...
Looking at the backtrace of the core file, what seems to be happening is that:
- gdbpy_flush attempts to flush gdb_stdout, which is nullptr
- that causes a segfault
- gdb intercepts this and starts to handle it using handle_fatal_signal
- handle_fatal_signal calls sig_write, which attempts to write to gdb_stderr,
which is nullptr,
- that causes another segfault
- gdb exits
I managed to reproduce the problem by the following trigger patch in
stdin_event_handler:
...
- if (error)
+ if (1 || error)
{
current_ui = main_ui;
ui->unregister_file_handler ();
- if (main_ui == ui)
+ if (1 || main_ui == ui)
{
gdb_printf (gdb_stderr, _("error detected on stdin\n"));
+ gdb_stderr = nullptr;
+ gdb_stdout = nullptr;
+ gdb_stdlog = nullptr;
quit_command ((char *) 0, 0);
}
...
which gives us:
...
$ gdb
(gdb) <q>error detected on stdin
Segmentation fault (core dumped)
$ q
...
Fix sig_write to handle the case that gdb_stderr == nullptr, such that we get
instead:
...
$ gdb
(gdb) <q>error detected on stdin
Fatal signal: Segmentation fault
----- Backtrace -----
...
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
$ q
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Lambda function sig_write:
...
const auto sig_write = [] (const char *msg) -> void
{
gdb_stderr->write_async_safe (msg, strlen (msg));
}
...
is defined a few times.
Factor this out into a regular function.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Set sh_offset for .tbss sections to their nominal offset after aligning.
They are not loaded from disk so the value doesn't really matter, except
when the .tbss section is the first one in a PT_TLS segment. In that
case, it sets the p_offset for the PT_TLS segment, which according to
the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align.
bfd/
PR ld/32896
* elf.c (assign_file_positions_for_load_sections): Properly set
sh_offset for .tbss sections.
ld/
PR ld/32896
* testsuite/ld-elf/tbss4.d: New file.
* testsuite/ld-elf/tbss4.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Fixed as specified in the DWARF standard:
The first type of reference can identify any debugging information entry
within the containing unit. This type of reference is an offset from the first
byte of the compilation header for the compilation unit containing
the reference. There are five forms for this type of reference.
There are fixed length forms for one, two, four and eight byte offsets
(respectively, DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, and DW_FORM_ref8).
There is also an unsigned variable length offset encoded form that uses
unsigned LEB128 numbers (DW_FORM_ref_udata).
gprofng/ChangeLog
2025-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/DwarfLib.cc (set_die): Handling DWARF references (DW_FORM_ref1,
DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata).
* src/Dwarf.cc: Likewise.
.debug_loclists section is loaded into debug_information as DWARF-5 debug
info and .debug_loc section is loaded into debug_information as pre-DWARF-5
debug info. When dumping .debug_loc section, we should only process
pre-DWARF-5 debug info in debug_information. When dumping .debug_loclists
section, we should only process DWARF-5 info in debug_information.
binutils/
PR binutils/32809
* dwarf.c (display_debug_loc): Dump .debug_loclists only for
DWARF-5.
ld/
PR binutils/32809
* testsuite/ld-x86-64/dwarf4.s: New file.
* testsuite/ld-x86-64/dwarf5a.s: Likewise.
* testsuite/ld-x86-64/dwarf5b.s: Likewise.
* testsuite/ld-x86-64/pr32809.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr32809.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
While debugging my longer series, I discovered that I broken "set
debug parser" a couple years ago. This patch fixes it and adds a
minimal test case so that it, hopefully, will not break again.
This patch also adds parser debugging to the C++ name canonicalizer.
Thanks to Tom de Vries for fixing the test case.
We have a discrepancy with 64-bit BFD handling across our component
subdirectories leading to link failures such as:
ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
[...]
with some configurations having a 32-bit host and 64-bit BFD, such as:
`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
other subdirectorses and has been a regression from commit 1d5269c994
("unify 64-bit bfd checks").
For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
combined with this logic in bfd/configure.ac:
case ${host64}-${target64}-${want64} in
*true*)
wordsize=64
bfd64_libs='$(BFD64_LIBS)'
all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
[...]
;;
false-false-false)
wordsize=32
all_backends='$(BFD32_BACKENDS)'
;;
esac
where the value of ${wordsize} switches between 32-bit and 64-bit BFD
via these pieces:
#define BFD_ARCH_SIZE @wordsize@
and:
#if BFD_ARCH_SIZE >= 64
#define BFD64
#endif
in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".
Then ${host64} is determined in bfd/configure.ac from the host's word
size, via the host's pointer size:
if test "x${ac_cv_sizeof_void_p}" = "x8"; then
host64=true
fi
And ${target64} is determined in bfd/configure.ac from the target's word
size:
if test ${target_size} = 64; then
target64=true
fi
Where multiple targets have been requested with `--enable-targets=all'
the presence of any 64-bit target will set "true" here.
Finally ${want64} is set according to `--enable-64-bit-bfd' user option
with an arrangement involving BFD_64_BIT:
BFD_64_BIT
if test $enable_64_bit_bfd = yes ; then
want64=true
else
want64=false
fi
which also, redundantly, checks and sets its result upon the host's word
size. Lastly ${want64} is also selectively set by target fragments in
bfd/config.bfd, which mostly if not completely overlaps with ${target64}
setting as described above.
Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
notice that BFD is 64-bit and do not enable their 64-bit handling where
the host requested is 32-bit and 64-bit BFD has been enabled other than
with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c
enables calls to its numerous own 64-bit backends by checking the BFD64
macro from "bfd.h", however does not actually enable said backends in
its Makefile. Hence the link errors quoted above.
Address the problem then by moving the `--enable-64-bit-bfd' option back
to bfd/configure.ac and remove the call to BFD_64_BIT from there and
then rewrite the macro in terms of checking for the presence of BFD64
macro in "bfd.h", which is the canonical way of determining whether BFD
is 64-bit or not.
Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
fragment used to before the problematic commit:
if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then
run the preprocessor on "bfd.h", which allows to invoke the macro from
configure.ac files placed in subdirectories located at deeper levels, by
relying on the preprocessor's search path.
This requires however that the invokers rely on `all-bfd' rather than
`configure-bfd' for their `configure' invocation stage, because "bfd.h"
is made by `make all' rather than `configure' in bfd/.
Do not cache the result of this check however, as reconfiguring a tree
such as to flip `--enable-64-bit-bfd' on or to change a secondary target
may affect BFD64 and we have no access to information about secondary
targets in BFD_64_BIT.
Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
anywhere.
Last but not least remove the hack from gdb/configure.ac to fail builds
for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds
complete successfully now, having enabled 64-bit BFD implicitly.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Alan Modra <amodra@gmail.com>
Approved-By: Luis Machado <luis.machado@arm.com>
After running test-case gdb.python/py-color-leak.exp in a container where I
don't have PYTHONDONTWRITEBYTECODE set, I get:
...
$ ls src/gdb/testsuite/gdb.python/__pycache__/
gdb_leak_detector.cpython-313.pyc
...
Fix this by setting sys.dont_write_bytecode to True in the python scripts
importing the module.
Tested on x86_64-linux.
This adds a new "maint canonicalize" command that can be used to see
the canonical form of a C++ name. I've needed this a few times when
debugging gdb.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom de Vries <tdevries@suse.de>
It would be useful to tell codespell to ignore blocks of code.
A feature ignore-multiline-regex exists, which can be used to implement this:
...
$ codespell --ignore-multiline-regex \
'codespell:ignore-begin.*codespell:ignore-end'
...
Unfortunately there's a bug in codespell where using -w in
combination with --ignore-multiline-regex drops all newlines in the updated
file.
In absence of a fix, commit this solution disabled, to locally document the
current state of this feature.
The d10v sim fails when built with GCC 15. From the bug:
d10v/table.c:171:17: error: initialization of ‘void (*)(struct sim_state *, SIM_CPU *)’ {aka ‘void (*)(struct sim_state *, struct _sim_cpu *)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
171 | { 0,0,0,0,0,0,0,(void (*)())0,0,{0,0,0}},
| ^
d10v/table.c:171:17: note: (near initialization for ‘Simops[165].func’)
The bug here is that this is the wrong function pointer type. Since
'0' is perfectly fine here, this patch simply removes the cast.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32900
Approved-By: Tom de Vries <tdevries@suse.de>
Now that we're using codespell to check spelling in gdb files, can we use
codespell to bring this spelling warning:
...
$ echo usuable | codespell -
1: usuable
usuable ==> usable
...
to:
...
$ git commit -a -m "Usuable stuff"
...
?
First, let's look at a straightforward commit-msg hook implementation:
...
- id: codespell
name: codespell-commit-msg
verbose: true
always_run: true
stages: [commit-msg]
...
installed using:
...
$ pre-commit install -t commit-msg
...
When trying the commit, we get:
...
$ echo "/* bla */" >> gdb/gdb.c
$ git commit -a -m "Usuable stuff"
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
check-include-guards.................................(no files to check)Skipped
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
codespell-commit-msg.....................................................Failed
- hook id: codespell
- duration: 0.06s
- exit code: 65
.git/COMMIT_EDITMSG:1: Usuable ==> Usable
check-include-guards.................................(no files to check)Skipped
$
...
The commit was aborted, but the commit message is still there:
...
$ cat .git/COMMIT_EDITMSG
Usuable stuff
...
We can retry and edit the commit message to clean up the typo:
...
$ git commit -e -F .git/COMMIT_EDITMSG -a
...
but it's a bit cumbersome.
Furthermore, say we fix a typo and want to document this in the commit log, and
do:
...
$ git commit -m "Fixed typo: useable -> usable" -a
...
This commit cannot succeed, unless we add a codespell ignore tag, which feels
like taking it too far.
Both these problems can be addressed by setting things up in such a way that
the commit always succeeds, and codespell output is shown as a hint.
Ideally, we'd tell to pre-commit to implement this using some setting, but
there doesn't seem to be one.
So we use some indirection. Instead of using native codespell, use a local
hook that calls a script gdb/contrib/codespell-log.sh, which calls pre-commit,
which calls codespell.
Using this approach, we get:
...
$ echo "/* bla */" >> gdb/gdb.c
$ git commit -a -m "Usuable stuff"
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
check-include-guards.................................(no files to check)Skipped
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
check-include-guards.................................(no files to check)Skipped
codespell-log............................................................Passed
- hook id: codespell-log
- duration: 0.18s
codespell-log-internal...................................................Failed
- hook id: codespell
- exit code: 65
.git/COMMIT_EDITMSG:1: Usuable ==> Usable
[codespell/codespell-log-2 d081bd25a40] Usuable stuff
1 file changed, 1 insertion(+)
$
...
This is obviously convoluted, but it works. Perhaps we can propose a
pre-commit improvement (always_pass) and simplify this eventually.
Checked new script codespell-log.sh with shell-check.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The recent commit dbbb9cfd37 added a
message using %ld to print an std::vector::size, which is of size_t
type. on 64 bit machines, size_t will be an unsigned long int, making
%ld work just fine, but on 32 bit ones, size_t will be unsigned int,
which causes the build to fail.
This commit fixes that by using %zu instead.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32901
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
I added this small helper method in the series I'm writing, to make
finding a DIE by section offset a bit nicer than using the unordered_set
methods. It doesn't have any dependencies, so I thought I would submit
it on its own.
Change-Id: If7313194ab09d9bd6d6a52c24eb6fd9a9c1b76e0
Approved-by: Kevin Buettner <kevinb@redhat.com>
Run `pre-commit autoupdate`. This brings in new versions of isort and
flake8.
Change-Id: I55f8b51b100e090e9a210338f46e10cf131a4aa7
Approved-By: Tom Tromey <tom@tromey.com>
flake8 7.2.0 appears to have this new warning:
F824: global name / nonlocal name is unused: name is never assigned in scope
It points out a few places in our code base where "global" is not
necessary, fix them.
Change-Id: Ia6fb08686977559726fefe2a5bb95d8dcb298bb0
Approved-By: Tom Tromey <tom@tromey.com>
This changes update_enumeration_type_from_children to use the correct
sign-extension method on the attribute. The logic here is a bit
complicated: if the enum has an underlying type, then we use that
type's signed-ness to interpret attributes; otherwise we must assume
attributes are encoded as signed values.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
dwarf2_const_value_data checks the size of the data like so:
if (bits < sizeof (*value) * 8)
...
else if (bits == sizeof (*value) * 8)
...
else
...
However, 'bits' can only be 8, 16, 32, or 64. And, because 'value' is
a LONGEST, which is alwasy 64-bit, the final 'else' can never be
taken.
This patch removes the dead code. And, because this was the only
reason for a non-void return value, the return type is changed as
well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
The discriminant value for a variant part may be signed or unsigned,
depending on the type of the variant. This patch changes the DWARF
reader to delay interpretation of the relevant attribute until the
signed-ness is known.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
This changes dwarf2/read.c:get_mpz to use the correct sign-extension
function. Normally a rational constant uses signed values, but a
purely unsigned form also seems fine here. This adds a new
attribute::form_is_strictly_unsigned, which is more precise than
form_is_unsigned (which accepts a lot of forms that aren't really for
ordinary constants).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
DW_AT_GNU_bias may be signed or unsigned, depending on the underlying
type. This patch changes the DWARF reader to examine the type before
decoding the attribute.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
