| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add a test-case using DW_FORM_strx.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Gdbsupport functions phex and phex_nz have a parameter sizeof_l:
...
extern const char *phex (ULONGEST l, int sizeof_l);
extern const char *phex_nz (ULONGEST l, int sizeof_l);
...
and a lot of calls use:
...
phex (l, sizeof (l))
...
Make this easier by reimplementing the functions as a template, allowing us to
simply write:
...
phex (l)
...
Simplify existing code using:
...
$ find gdb* -type f \
| xargs sed -i 's/phex (\([^,]*\), sizeof (\1))/phex (\1)/'
$ find gdb* -type f \
| xargs sed -i 's/phex_nz (\([^,]*\), sizeof (\1))/phex_nz (\1)/'
...
and manually review:
...
$ find gdb* -type f | xargs grep "phex (.*, sizeof.*)"
$ find gdb* -type f | xargs grep "phex_nz (.*, sizeof.*)"
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch adds, at long last, some emoji output to gdb. In
particular, warnings are indicated with the U+26A0 (WARNING SIGN), and
errors with U+274C (CROSS MARK).
There is a new setting to control whether emoji output can be used.
It defaults to "auto", which means emoji will be used if the host
charset is UTF-8. Note that disabling styling will also disable
emoji, handy for traditionalists.
I've refactored mingw console output a little, so that emoji will not
be printed to the console. Note the previous code here was a bit
strange in that it assumed that the first use of gdb_console_fputs
would be to stdout.
This version lets the user control the prefixes directly, so different
emoji can be chosen if desired.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
C23 changes how function definitions like int `int tputs ()` are
interpreted. In older standards this meant that the function arguments
are unknown. In C23 this is interpreted as `int tputs (void)` so now
when we compile with GCC15 (which defaults to -std=gnu23) we get an
error such as
readline/display.c:2839:17: error: too many arguments to function 'tputs'; expected 0, have 3
Add the function arguments for tgetent(), tgetflag(), tgetnum(),
tgetstr(), tputs() and tgoto().
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
After building gdb with "-O0 -g -fsanitize=thread" on aarch64-linux, with
test-case gdb.reverse/time-reverse.exp I run into:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: mode=c: continue to breakpoint: marker2 (timeout)
...
The problem is that instruction stepping gets stuck in a loop with this call
stack: time -> __GI___clock_gettime -> __kernel_clock_gettime ->
__cvdso_clock_gettime.
This is not specific to fsanitize=thread, it just makes gdb slow, which makes
instruction stepping slow, which results in the application getting stuck.
I ran into this as well with a regular gdb build on a 32-bit i686 laptop with
1GB of memory, an inherently slow setup. In that instance, I was able to
observe that the loop we're stuck in is the outer loop in do_coarse in linux
kernel source lib/vdso/gettimeofday.c.
Fix this by setting "record full insn-number-max" to 2000, and handling
running into the limit.
Initially I tried the approach of using "stepi 2000" instead of continue, but
that made the issue more likely to show up (for instance, I observed it after
building gdb with -O0 on aarch64-linux).
Tested on aarch64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR testsuite/32678
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32678
|
|
I noticed that test-case gdb.reverse/time-reverse.exp contains:
...
if [supports_process_record] {
# Activate process record/replay
gdb_test_no_output "record" "turn on process record"
...
So I tried out forcing supports_process_record to 0, and got:
...
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: info record
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: reverse to marker1
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: check time record
FAIL: gdb.reverse/time-reverse.exp: mode=c: info record
FAIL: gdb.reverse/time-reverse.exp: mode=c: reverse to marker1
FAIL: gdb.reverse/time-reverse.exp: mode=c: check time record
...
Fix this by requiring supports_process_record alongside supports_reverse.
I also noticed when running make-check-all.sh that there were a lot of failures
with target board dwarf5-fission-debug-types.
Fix this by not ignoring the result of "runto marker1".
Then I noticed that $srcfile is used as a regexp. Fix this by applying
string_to_regexp.
Tested on x86_64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
I found a few more spots where a minor modification to a test lets it
pass with gnat-llvm:
* For array_subcript_addr, gnat-llvm was not putting the array into
memory. Making the array larger works around this.
* For bp_inlined_func, it is normal for gnat-llvm to sometimes emit a
call to an out-of-line copy of the function, so accept this.
* For null_overload and type-tick-size, I've applied the usual fix for
keeping an unused local variable alive.
|
|
While investigating a timeout in gdb.threads/inf-thr-count.exp I noticed that
it uses quite some escaping, resulting in hard-to-parse regexps like
"\\\$$::decimal".
Fix this by reducing the escaping using:
- quoting strings using {} instead of "", and
- string_to_regexp.
Also use multi_line to split up long multi-line regexps.
Tested on x86_64-linux.
|
|
With test-case gdb.threads/inf-thr-count.exp, check-readmore and
READMORE_SLEEP=1000 I run into:
...
(gdb) set variable spin = 0^M
(gdb) ^M
Thread 1 "inf-thr-count" hit Breakpoint 2, breakpt () at /data/vries/gdb/src/gdb/testsuite/gdb.threads/inf-thr-count.c:49^M
49 }^M
FAIL: gdb.threads/inf-thr-count.exp: set 'spin' flag to allow main thread to exit (timeout)
PASS: gdb.threads/inf-thr-count.exp: wait for main thread to stop
...
Fix this by using -no-prompt-anchor.
Tested on x86_64-linux.
|
|
as_bad() already emits a newline; having extra ones leads to somewhat
distorted diagnostics.
|
|
Both as_bad() and as_warn() already emit a newline; having extra ones
leads to somewhat distorted diagnostics.
|
|
It's unclear why the array part of the union was used there, when we're
dealing with a function. Originally, when 32-bit hosts and targets were
prevailing, the memset() in question ended up clearing the entire x_fcn,
while for 64-bit hosts/targets only x_lnnoptr would have been cleared.
Then a2c7ca15a560 ("Use stdint types in coff internal_auxent") made
things consistent, but imo in the wrong direction (and likely
unintentionally). Go back to what apparently was meant originally, using
the correct part of the union now.
|
|
For one at least x86 gcc emits .def/.endef for functions, but no 2nd
pair to designate their ends (sizes). While we can't recover the sizes,
we can at least properly establish the chain of function symbols, which
of course requires to emit auxiliary symbols for every function symbol
even when there's no C_EFCN: We simply shouldn't be making their
insertion conditional upon there not being a function processing of
which is "in progress".
In fact it was wrong to assign dual purpose to {,next_}set_end:
Functions don't have "ends" set, but links to the next one. The same
symbol table entry can serve both as an end marker and be a part of the
chain of (defined) functions; this can't be expressed by a single static
variable. Use what (again) becomes last_functionP for this purpose,
along with tracking what symbol C_EFCN should apply to.
This then allows to undo exposing of the respective (supposedly static)
tracking variable, which PPC's XCOFF handling had introduced. Also
rename it back to what it was before its exposure.
For now the new testcases are XFAIL for Arm64 since there, unlike for
Arm32, mapping symbols are emitted for COFF, too.
|
|
... and move the cofftag testcase there (from all/). Just like we have
one for ELF.
|
|
There's no reason to reject this common COFF directive when it doesn't
have any other meaning.
|
|
|
|
Replace xmalloc+memcpy+free with xrealloc, avoiding the asan warning
on the initial allocation where we had memcpy(p,0,0).
* cg_arcs.c (arc_add): Use xrealloc.
|
|
Don't warn if the offset of the first entry in .debug_rnglists starts
right after the header. Warn holes in .debug_ranges and debug_rnglists
sections only if the last end pointer isn't the same as the current
start pointer.
PR binutils/32927
* dwarf.c (display_debug_ranges_list): Return the pointer to the
end.
(display_debug_ranges): Don't warn if the offset of the first
entry in .debug_rnglists starts right after the header. Warn a
hole only if the last end pointer is the same as the next pointer.
* testsuite/binutils-all/x86-64/dwarf4.s: New file.
* testsuite/binutils-all/x86-64/dwarf5.s: Likewise.
* testsuite/binutils-all/x86-64/pr32927-1.d: Likewise.
* testsuite/binutils-all/x86-64/pr32927-2.d: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Co-Authored-By: Alan Modra <amodra@gmail.com>
|
|
|
|
The previous commit had a small styling issue that I forgot to fix
before pushing. This commit fixes the styling issue.
|
|
A recent static analyzer run flagged that program_space::exec_close
could be using a pointer after it has been freed. This is not true, as
the pointer is never dereferenced, the address is used for comparisons.
However, to avoid false positives from static analyzers (or bogus
security bugs), this commit makes the code stop looking like a UAF by
moving the unique_ptr into a local unique_ptr, so that there is no way
someone would think memory could be used after being freed.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
After building gdb with:
...
CFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread -fno-exceptions
CXXFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread
...
when doing:
...
$ cd build/gdb
$ make check-read1 RUNTESTFLAGS=gdb.threads/clone-attach-detach.exp
...
I run into:
...
Running /data/vries/gdb/src/gdb/testsuite/gdb.threads/clone-attach-detach.exp ...
ThreadSanitizer:DEADLYSIGNAL
==4799==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 \
(pc 0x7f636029a947 bp 0x7f635dfbf090 sp 0x7f635dfbf028 T4824)
==4799==The signal is caused by a READ memory access.
==4799==Hint: address points to the zero page.
ThreadSanitizer:DEADLYSIGNAL
ThreadSanitizer: nested bug in the same thread, aborting.
...
This doesn't happen when doing the same from build/gdb/testsuite, because
CFLAGS doesn't get propagated from build/gdb.
I'm not sure what is the root cause here, but when building with
-fsanitize, I'm interested in running the sanitizer on gdb, not on testsuite
utility libraries that are used with expect.
Fix this by skipping -fsanitize when compiling read1.so and readmore.so.
Tested on x86_64-linux, by rebuilding read1.so and running the test-case.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On arm-linux, with test-case gdb.python/py-missing-objfile.exp I get:
...
(gdb) whatis global_exec_var^M
type = volatile exec_type^M
(gdb) FAIL: $exp: initial sanity check: whatis global_exec_var
...
instead of the expected "type = volatile struct exec_type".
The problem is that the current language is ASM instead of C, because the
inner frame at the point of the core dump has language ASM:
...
#0 __libc_do_syscall () at libc-do-syscall.S:47
#1 0xf7882920 in __pthread_kill_implementation () at pthread_kill.c:43
#2 0xf784df22 in __GI_raise (sig=sig@entry=6) at raise.c:26
#3 0xf783f03e in __GI_abort () at abort.c:73
#4 0x009b0538 in dump_core () at py-missing-objfile.c:34
#5 0x009b0598 in main () at py-missing-objfile.c:46
...
Fix this by manually setting the language to C.
Tested on arm-linux and x86_64-linux.
PR testsuite/32445
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32445
|
|
When building gdb with --enable-targets=all on arm-linux, I run into:
...
gdb/riscv-tdep.c: In function ‘bool try_read(regcache*, int, ULONGEST&)’:
gdb/riscv-tdep.c:4887:18: error: format ‘%lx’ expects argument of type \
‘long unsigned int’, but argument 2 has type ‘ULONGEST’ \
{aka ‘long long unsigned int’} [-Werror=format=]
4887 | warning (_("Can not read at address %lx"), addr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
and a few more Wformat errors, due to commit b9c7eed0c24 ("This commit adds
record full support for rv64gc instruction set").
Fix these by using hex_string.
Tested by completing a build on arm-linux.
|
|
They are instruction alias, but not mark correctly, and seems like we
don't have a good way to verify that since the disassembler doesn't
disassemble instruction into alias.
[1] https://github.com/riscv-non-isa/riscv-asm-manual/pull/124
|
|
Modify it a little to run on more targets.
|
|
gettext calls were missing. Fix that, and change a couple of einfo
calls to fatal.
|
|
cooked_index_worker_debug_info
Move a few functions exclusively used to process units to become methods
of cooked_index_worker_debug_info. Rename them to a more consistent
name scheme, which gets rid of outdated naming. The comments were also
quite outdated.
Change-Id: I2e7dcc2e4ff372007dcb4f6c3d34187c9cc2da05
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The next patch moves some functions to be methods of
cooked_index_worker_debug_info. Move cooked_index_worker_debug_info
above those functions, to make that easier (methods can't be defined
before the class declaration).
Change-Id: I7723cb42efadb2cc86f2227b3c2fb275e2d620f9
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch tries to standardize the places where we check if units are
dummy. When checking if a unit is dummy, it is not necessary to check
for some other conditions.
- cutu_reader::is_dummy() is a superset of cutu_reader::cu() returning
nullptr, so it's not necessary to check if the cu method return
nullptr if also checking if the unit is dummy.
- cutu_reader::is_dummy() is a superset of cutu_reader::top_level_die()
returning nullptr, so same deal.
Remove some spots that check for these conditions in addition to
cutu_reader::is_dummy().
In addition, also remove the checks for:
!new_reader->top_level_die ()->has_children
in cooked_indexer::ensure_cu_exists. IMO, it is not useful to special
case the units having a single DIE. Especially in this function, which
deals with importing things from another unit, a unit with a single DIE
would be an edge case that should not happen with good debug info. I
think it's preferable to have simpler code.
Change-Id: I4529d7b3a0bd2891a60f41671de8cfd3114adb4a
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In process_psymtab_comp_unit and ensure_cu_exists, we create a temporary
cutu_reader on the stack, then move it to a heap allocated cutu_reader
once we confirmed the unit is not dummy. I think it's unnecessary to
create a temporary cutu_reader. The only downside of not doing so is that if it
ends up that the CU is dummy, we made an allocation/deallocation for
nothing. Dummy CUs are a rare thing, it shouldn't change anything.
This allows removing the cutu_reader move constructor.
Change-Id: I44742d471c495055ee46db41c0e7bdfbd2d5c0b7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When building with gcc, with flags -gdwarf-5, -gsplit-dwarf and
-fdebug-types-section, the resulting .dwo files contain multiple
.debug_info.dwo sections. One for each type unit and one for the
compile unit. This is correct, as per DWARF 5, section F.2.3 ("Contents
of the Split DWARF Object Files"):
The split DWARF object files each contain the following sections:
...
.debug_info.dwo (for the compilation unit)
.debug_info.dwo (one COMDAT section for each type unit)
...
GDB currently assumes that there is a single .debug_info.dwo section,
causing unpredictable behavior. For example, sometimes this crash:
==81781==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x508000007a71 at pc 0x58704d32a59c bp 0x7ffc0acc0bb0 sp 0x7ffc0acc0ba0
READ of size 1 at 0x508000007a71 thread T0
#0 0x58704d32a59b in bfd_getl32 /home/smarchi/src/binutils-gdb/bfd/libbfd.c:846
#1 0x58704ae62dce in read_initial_length(bfd*, unsigned char const*, unsigned int*, bool) /home/smarchi/src/binutils-gdb/gdb/dwarf2/leb.c:92
#2 0x58704aaf76bf in read_comp_unit_head(comp_unit_head*, unsigned char const*, dwarf2_section_info*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:47
#3 0x58704aaf8f97 in read_and_check_comp_unit_head(dwarf2_per_objfile*, comp_unit_head*, dwarf2_section_info*, dwarf2_section_info*, unsigned char const*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:193
#4 0x58704b022908 in create_dwo_unit_hash_tables /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6233
#5 0x58704b0334a5 in open_and_init_dwo_file /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7588
#6 0x58704b03965a in lookup_dwo_cutu /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7935
#7 0x58704b03a5b1 in lookup_dwo_comp_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8009
#8 0x58704aff5b70 in lookup_dwo_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2802
The first time that locate_dwo_sections gets called for a
.debug_info.dwo section, dwo_sections::info gets initialized properly.
The second time it gets called for a .debug_info.dwo section, the size
field in dwo_sections::info gets overwritten with the size of the second
section. But the buffer remains pointing to the contents of the first
section, because the section is already "read in". So the size does not
match the buffer. And even if it did, we would only keep the
information about one .debug_info.dwo, out of the many.
First, add an assert in locate_dwo_sections to make sure we don't
try to fill in a dwo section info twice. Add the assert to other
functions with the same pattern, while at it.
Then, change dwo_sections::info to be a vector of sections (just like we
do for type sections). Update locate_dwo_sections to append to that
vector when seeing a new .debug_info.dwo section. Update
open_and_init_dwo_file to read the units from each section.
The problem can be observed by running some tests with the
dwarf5-fission-debug-types target board. For example,
gdb.base/condbreak.exp crashes (with the ASan failure shown above)
before the patch and passes after).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119766
Change-Id: Iedf275768b6057dee4b1542396714f3d89903cf3
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
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>
|
|
This fixes a typo in gdb/README.
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>
|
|
Using the trigger patch described in the previous commit, I get:
...
$ gdb
(gdb) <q>error detected on stdin
Fatal signal: Segmentation fault
----- Backtrace -----
0x64c7b3 gdb_internal_backtrace_1
/data/vries/gdb/src/gdb/bt-utils.c:127
0x64c937 _Z22gdb_internal_backtracev
/data/vries/gdb/src/gdb/bt-utils.c:196
0x94db83 handle_fatal_signal
/data/vries/gdb/src/gdb/event-top.c:1021
0x94dd48 handle_sigsegv
/data/vries/gdb/src/gdb/event-top.c:1098
0x7f372be578ff ???
0x10b7c0a _Z9gdb_flushP7ui_file
/data/vries/gdb/src/gdb/utils.c:1527
0xd4b938 gdbpy_flush
/data/vries/gdb/src/gdb/python/python.c:1624
0x7f372d73b276 _PyCFunction_FastCallDict
Objects/methodobject.c:231
0x7f372d73b276 _PyCFunction_FastCallKeywords
Objects/methodobject.c:294
0x7f372d794a09 call_function
Python/ceval.c:4851
0x7f372d78e838 _PyEval_EvalFrameDefault
Python/ceval.c:3351
0x7f372d796e6e PyEval_EvalFrameEx
Python/ceval.c:754
0x7f372d796e6e _PyFunction_FastCall
Python/ceval.c:4933
0x7f372d796e6e _PyFunction_FastCallDict
Python/ceval.c:5035
0x7f372d6fefc8 _PyObject_FastCallDict
Objects/abstract.c:2310
0x7f372d6fefc8 _PyObject_Call_Prepend
Objects/abstract.c:2373
0x7f372d6fe162 _PyObject_FastCallDict
Objects/abstract.c:2331
0x7f372d700705 callmethod
Objects/abstract.c:2583
0x7f372d700705 _PyObject_CallMethodId
Objects/abstract.c:2640
0x7f372d812a41 flush_std_files
Python/pylifecycle.c:699
0x7f372d81281d Py_FinalizeEx
Python/pylifecycle.c:768
0xd4d49b finalize_python
/data/vries/gdb/src/gdb/python/python.c:2308
0x9587eb _Z17ext_lang_shutdownv
/data/vries/gdb/src/gdb/extension.c:330
0xfd98df _Z10quit_forcePii
/data/vries/gdb/src/gdb/top.c:1817
0x6b3080 _Z12quit_commandPKci
/data/vries/gdb/src/gdb/cli/cli-cmds.c:483
0x1056577 stdin_event_handler
/data/vries/gdb/src/gdb/ui.c:131
0x1986970 handle_file_event
/data/vries/gdb/src/gdbsupport/event-loop.cc:551
0x1986f4b gdb_wait_for_event
/data/vries/gdb/src/gdbsupport/event-loop.cc:672
0x1985e0c _Z16gdb_do_one_eventi
/data/vries/gdb/src/gdbsupport/event-loop.cc:263
0xb66f2e start_event_loop
/data/vries/gdb/src/gdb/main.c:402
0xb670ba captured_command_loop
/data/vries/gdb/src/gdb/main.c:466
0xb68b9b captured_main
/data/vries/gdb/src/gdb/main.c:1344
0xb68c44 _Z8gdb_mainP18captured_main_args
/data/vries/gdb/src/gdb/main.c:1363
0x41a3b1 main
/data/vries/gdb/src/gdb/gdb.c:38
---------------------
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
...
Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and
likewise in ioscm_flush) such that we get instead:
...
$ gdb
(gdb) <q>error detected on stdin
$ q
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.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>
|
