| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit:
commit be382ece165eefa3e65f61bfb6b2aa2ee95dd6b4
Date: Wed Feb 12 09:35:26 2025 -0700
Check for compiler support in scalar_storage.exp
Introduced an undefined variable use in gdb.ada/scalar_storage.exp,
fixed by this commit.
|
|
On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:
$ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"
I think I stumble on this bug [1], preventing the test from doing
anything that requires expanding the compilation unit:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
Reading symbols from testsuite/outputs/gdb.base/style/style...
(gdb) p main
DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
(gdb)
The error is thrown here:
#0 0x00007ffff693f0a1 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x0000555569ce6852 in throw_it(return_reason, errors, const char *, typedef __va_list_tag __va_list_tag *) (reason=RETURN_ERROR, error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:203
#2 0x0000555569ce690f in throw_verror (error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:211
#3 0x000055556879c0cb in verror (string=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", args=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdb/utils.c:193
#4 0x0000555569cfa88d in error (fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:45
#5 0x000055556667dbff in dwarf2_section_info::read_string (this=0x61b000042a08, objfile=0x616000055e80, str_offset=262811, form_name=0x555562886b40 "DW_FORM_strp") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/section.c:211
#6 0x00005555662486b7 in dwarf_decode_macro_bytes (per_objfile=0x616000056180, builder=0x614000006040, abfd=0x6120000f4b40, mac_ptr=0x60300004f5be "", mac_end=0x60300004f5bb "\002\004", current_file=0x62100007ad70, lh=0x60f000028bd0, section=0x61700008ba78, section_is_gnu=1, section_is_dwz=0, offset_size=4, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional<unsigned long> = {...}, include_hash=..., cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:511
#7 0x000055556624af0e in dwarf_decode_macros (per_objfile=0x616000056180, builder=0x614000006040, section=0x61700008ba78, lh=0x60f000028bd0, offset_size=4, offset=0, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional<unsigned long> = {...}, section_is_gnu=1, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:934
#8 0x000055556642cb82 in dwarf_decode_macros (cu=0x61700008b600, offset=0, section_is_gnu=1) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:19435
#9 0x000055556639bd12 in read_file_scope (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6366
#10 0x0000555566392d99 in process_die (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5310
#11 0x0000555566390d72 in process_full_comp_unit (cu=0x61700008b600, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5075
The exception is then only caught at the event-loop level
(start_event_loop), causing the whole debug info reading process to be
aborted. I think it's a little harsh, considering that a lot of things
could work even if we failed to read macro information.
Catch the exception inside read_file_scope, print the exception, and
carry on. We could go even more fine-grained: if reading the string for
one macro definition fails, we could continue reading the macro
information. Perhaps it's just that one macro definition that is
broken. However, I don't need this level of granularity, so I haven't
attempted this. Also, my experience is that macro reading fails when
the compiler or linker has a bug, in which case pretty much everything
is messed up.
With this patch, it now looks like:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
Reading symbols from testsuite/outputs/gdb.base/style/style...
(gdb) p main
While reading section .debug_macro.dwo: DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
$1 = {int (int, char **)} 0x684 <main>
(gdb)
In the test I am investigating (gdb.base/style.exp with the fission
board), it allows more tests to run:
-# of expected passes 107
-# of unexpected failures 17
+# of expected passes 448
+# of unexpected failures 19
Of course, we still see the error about the macro information, and some
macro-related tests still fail (those would be kfailed ideally), but
many tests that are not macro-dependent now pass.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Change-Id: I0bdb01f153eff23c63c96ce3f41114bb027e5796
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On Debian 12, with gcc 12 and ld 2.40, I get some failures when running:
$ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission"
I think I stumble on this bug [1], preventing to do the
disassembling that the test needs:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style
Reading symbols from testsuite/outputs/gdb.base/style/style...
(gdb) x/1i *main
DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style]
(gdb)
The regexp in get_single_disassembled_insn fails to match, the insn
variable doesn't get set, and we get one of those unreadable TCL stack
traces:
ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/style.exp.
ERROR: tcl error code TCL READ VARNAME
ERROR: can't read "insn": no such variable
while executing
"return $insn"
(procedure "get_single_disassembled_insn" line 4)
invoked from within
"get_single_disassembled_insn"
("uplevel" body line 18)
invoked from within
"uplevel 1 $body"
invoked from within
...
Check the return value of the regexp call, return an empty string on
failure. Log a failure, so that we have a trace that something went
wrong, in case the tests done by the caller happen to pass by change.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Change-Id: I5123d4cc0034da85a093a8531a22e972c10d94ca
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The gcore man page says that the default prefix for a generated core
file will be 'gcore', i.e. we'll create files like 'gcore.pid'. In
reality the default is 'core'.
As far as I can tell, the default has been 'core' for years, and the
docs used to say that the default was 'core', but the docs were
changed by mistake in commit:
commit 129eb0f1f16dc7a49799a024a7bcb109d954a1e7
Date: Fri Jul 27 00:52:23 2018 -0400
Improve gcore manpage and clarify "-o" option
So, lets bring the docs back inline with the code.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Like the previous commit, this copies a lot from:
commit fb2ded33c1e519659743047ed7817166545b6d91
Date: Fri Dec 20 12:46:11 2024 -0800
Add gstack script
And adds -h | --help options to the gcore script, and smartens up the
help and usage output messages.
The usage text is now split over several lines (as it was getting a
bit long), and an input error suggests using `--help` instead of
printing the full usage string.
These changes bring gcore and gstack closer in behaviour.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Based on the work in this commit:
commit fb2ded33c1e519659743047ed7817166545b6d91
Date: Fri Dec 20 12:46:11 2024 -0800
Add gstack script
This commit adds a '-v' or '--version' option to the existing gcore
script. This new option causes the script to print its version
number, and then exit.
I needed to adjust the getopts handling a little in order to support
the long form '--version' argument, but as this makes gcore more
consistent with gstack, then this seems like a good thing.
The usage message is now getting a little long. Don't worry, I plan
to clean that up in the next commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
After compiling gdb with -fstack-protector-all, and running test-case
gdb.reverse/getrandom.exp on aarch64-linux, we run into
"Stack smashing detected" in function aarch64_record_asimd_load_store.
This is reported in PR record/32784.
This happens due to an out-of-bounds write to local array record_buf_mem:
...
uint64_t record_buf_mem[24];
...
when recording insn:
...
B+>0xfffff7ff4d10 st1 {v0.16b-v3.16b}, [x0]
...
We can fix this by increasing the array size to 128, but rather than again
hardcoding a size, reimplement record_buf_mem as std::vector.
Tested on aarch64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32784
|
|
While reviewing the enum gdb_syscall entries with values >= 500, I noticed
that gdb_sys_accept exists, but gdb_sys_accept4 doesn't, while recording
support is essentially the same, given that the difference in interface is
only an extra int parameter:
...
int accept (int sockfd, struct sockaddr *addr, socklen_t *addrlen);
int accept4 (int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
...
Fix this by:
- adding gdb_sys_accept4,
- supporting it in record_linux_system_call alongside gdb_sys_accept, and
- mapping to gdb_sys_accept4 in various syscall canonicalization functions.
The usual thing to do before the rewrite of i386_canonicalize_syscall would
have been to use the value from arch/x86/entry/syscalls/syscall_32.tbl:
...
gdb_sys_accept4 = 364,
...
but that's no longer necessary, so instead we use some >= 500 value:
...
gdb_sys_accept4 = 533,
...
to steer clear of the space where ppc_canonicalize_syscall and
s390_canonicalize_syscall do hard-coded number magic.
Tested on x86_64-linux, with and without target board unix/-m32, and
aarch64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
On openSUSE Tumbleweed x86_64, with target board unix/-m32 and test-case
gdb.reverse/recvmsg-reverse.exp, I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 360^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5575 in __kernel_vsyscall ()^M
(gdb) FAIL: $exp: continue to breakpoint: marker2
...
The syscall number 360 in i386 is for syscall socketpair, as we can see in
arch/x86/entry/syscalls/syscall_32.tbl:
...
<number> <abi> <name> <entry point>
360 i386 socketpair sys_socketpair
...
Function i386_canonicalize_syscall assumes that any syscall below 500 maps to
an identically valued enum in enum gdb_syscall:
...
static enum gdb_syscall
i386_canonicalize_syscall (int syscall)
{
enum { i386_syscall_max = 499 };
if (syscall <= i386_syscall_max)
return (enum gdb_syscall) syscall;
else
return gdb_sys_no_syscall;
}
...
However, that's not the case. The value of gdb_sys_socketpair is not 360,
but 512:
...
enum gdb_syscall {
...
gdb_sys_getrandom = 355,
gdb_sys_statx = 383,
...
gdb_sys_socketpair = 512,
...
Consequently, when record_linux_system_call is called with
syscall == i386_canonicalize_syscall (360), we hit the default case here:
....
switch (syscall)
{
...
default:
gdb_printf (gdb_stderr,
_("Process record and replay target doesn't "
"support syscall number %d\n"), syscall);
return -1;
break;
}
...
rather than hitting the case for gdb_sys_socketpair.
I initially wrote a trivial fix for this, changing the value of
gdb_sys_socketpair to 360. However, Andreas Schwab pointed out that there are
other functions (ppc_canonicalize_syscall and s390_canonicalize_syscall) that
make assumptions about specific values of enum gdb_syscall, and fixing this
for i386 may break things for ppc or s390.
So instead, I decided to rewrite i386_canonicalize_syscall to match the
approach taken in aarch64_canonicalize_syscall, which allows
gdb_sys_socketpair to keep the same value.
So, fix this by:
- adding a new table file gdb/i386-syscalls.def, using a SYSCALL entry for
each syscall, generated from arch/x86/entry/syscalls/syscall_32.tbl,
- using gdb/i386-syscalls.def to define enum i386_syscall, and
- using macros SYSCALL_MAP, SYSCALL_MAP_RENAME and UNSUPPORTED_SYSCALL_MAP to
define the mapping from enum i386_syscall to enum gdb_syscall in
i386_canonicalize_syscall.
I've created the mapping as follows:
- I used arch/x86/entry/syscalls/syscall_32.tbl to generate an initial mapping
using SYSCALL_MAP for each syscall,
- I attempted to compile this and used the compilation errors about
non-existing gdb_sys_ values to change those entries to
UNSUPPORTED_SYSCALL_MAP, which got me a compiling version,
- I reviewed the UNSUPPORTED_SYSCALL_MAP entries, changing to
SYSCALL_MAP_RENAME where necessary,
- I then reviewed syscalls below 500 that mapped to a gdb_syscall value below
500, but not the same, and fixed those using SYSCALL_MAP_RENAME, and
- reviewed the mapping for gdb_syscall entries >= 500.
On the resulting mapping, I was able to do the following sanity check:
...
for (int i = 0; i < 500; ++i)
{
int res = i386_canonicalize_syscall (i);
if (res == i)
continue;
if (res == -1)
continue;
if (res >= 500)
continue;
gdb_assert_not_reached ("");
}
}
...
to make sure that any syscall below 500 either:
- maps to the same number,
- is unsupported, or
- maps to a number >= 500.
Coming back to our original problem, the socket pair syscall is addressed by
an entry:
...
SYSCALL_MAP (socketpair);
...
which maps i386_sys_socketpair (360) to gdb_sys_socketpair (512).
Tested on x86_64-linux with target board unix/-m32.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR tdep/32770
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770
|
|
dwarf2_base_index_functions::expand_all_symtabs
Commit 292041562289 ("gdb/dwarf: use ranged for loop in some spots")
broke some tests notably gdb.base/maint.exp with the fission board.
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/maint/maint -ex start -ex "maint expand-sym" -batch
...
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/break.c:43
43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
/usr/include/c++/14.2.1/debug/safe_iterator.h:392:
In function:
gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>&
gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::operator++()
[with _Iterator = gnu_cxx::
normal_iterator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*,
std::vector<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>,
std::allocator<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > >
>; _Sequence = std::debug::vector<std::unique_ptr<dwarf2_per_cu,
dwarf2_per_cu_deleter> >; _Category = std::forward_iterator_tag]
Error: attempt to increment a singular iterator.
Note that this is caught because I build with -D_GLIBCXX_DEBUG=1.
Otherwise, it might crash more randomly, or just not crash at all (but
still be buggy).
While iterating on the all_units vector, some type units get added
there:
#0 add_type_unit (per_bfd=0x51b000044b80, section=0x50e0000c2280, sect_off=0, length=74, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2576
#1 0x00005555618a3a40 in lookup_dwo_signatured_type (cu=0x51700009b580, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2664
#2 0x00005555618ee176 in queue_and_load_dwo_tu (dwo_unit=0x521000120e00, cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8329
#3 0x00005555618eeafe in queue_and_load_all_dwo_tus (cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8366
#4 0x00005555618966a6 in dw2_do_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1695
#5 0x00005555618968d4 in dw2_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1719
#6 0x000055556189ac3f in dwarf2_base_index_functions::expand_all_symtabs (this=0x502000024390, objfile=0x516000065780) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1977
This invalidates the iterator in
dwarf2_base_index_functions::expand_all_symtabs, which is caught by the
libstdc++ debug mode.
I'm not entirely sure that it is correct to append type units from dwo
files to the all_units vector like this. The
dwarf2_find_containing_comp_unit function expects a precise ordering of
the elements of the all_units vector, to be able to do a binary search.
Appending a type unit at the end at this point certainly doesn't respect
that ordering.
For now I'd just like to undo the regression. Do that by using
all_units_range in the ranged for loop. I will keep in mind to
investigate whether this insertion of type units in all_units after the
fact really makes sense or not.
Change-Id: Iec131e59281cf2dbd12d3f3d163b59018fdc54da
|
|
Change-Id: I0c5b7591eab8e6616b653be7c04bc75159427ad6
|
|
Change-Id: I3cd6b932d0dfb4cc07b6d48a1dc9ec35e7bfa03e
|
|
I noticed that these loops could be written to avoid the iteration
variable `i`.
Change-Id: I8b58eb9913b6ac8505ee45eb8009ef7027236cb9
|
|
|
|
Needed after 90803ffdcc4d8c3d17566bf8dccadbad312f07a9.
gprofng/ChangeLog
* src/Makefile.in: Regenerate.
|
|
commit d25ba4596e85da6d8af78c88b5917e14763afbe1 create symbolic link
no care cross-compilation prefix.
gprofng/ChangeLog
2025-02-10 Zheng Junjie <zhengjunjie@iscas.ac.cn>
* src/Makefile.am: create symbolic link respect cross-compilation.
* src/Makefile.in: Rebuild.
|
|
My earlier patch to introduce string-set.h used the wrong type in the
hash functions. This patch fixes the error.
|
|
These are reported as unused by clangd.
Change-Id: I54b3fba4d7a73c955a9a26c0d340a384b2d37b32
|
|
Change-Id: Icc7b468b85c09a9721fc9580892c9ad424e0a29a
|
|
It is reported as unused by clangd.
Change-Id: I73c03577c521c1b71128409b5cf085a4d1785080
|
|
|
|
This changes mi-cmds.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes py-connection.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes dwarf2/aranges.c to use gdb::unordered_set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes all_non_exited_process_targets to return
gdb::unordered_set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes remote.c to use gdb::unordered_set and
gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes mi-main.c to use gdb::unordered_set and
gdb::unordered_map.
this may change the order of core ids that are emitted, but that seems
fine as MI generally doesn't guarantee ordering.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This C++-ifies iterate_over_threads, changing it to accept a
gdb::function_view and to return bool.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the TUI to use gdb::unordered_map and gdb::unordered_set
rather than the std:: variants.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes source_cache to use gdb::unordered_map and
gdb::unordered_set rather than the std:: variants.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
On openSUSE Tumbleweed, with glibc 2.41, when running test-case
gdb.base/step-over-syscall.exp I run into:
...
(gdb) stepi^M
0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M
1: x/i $pc^M
=> 0x7ffff7cfd09b <__abort_lock_rdlock+29>: syscall^M
(gdb) p $eax^M
$1 = 14^M
(gdb) FAIL: $exp: fork: displaced=off: syscall number matches
FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout)
...
We're stepi-ing through fork trying to find the fork syscall, but encounter
another syscall.
The test-case attempts to handle this:
...
gdb_test_multiple "stepi" "find syscall insn in $syscall" {
-re ".*$syscall_insn.*$gdb_prompt $" {
# Is the syscall number the correct one?
if {[syscall_number_matches $syscall]} {
pass $gdb_test_name
} else {
exp_continue
}
}
-re "x/i .*=>.*\r\n$gdb_prompt $" {
incr steps
if {$steps == $max_steps} {
fail $gdb_test_name
} else {
send_gdb "stepi\n"
exp_continue
}
}
}
...
but fails to do so because it issues an exp_continue without issuing a new
stepi command, and consequently the "find syscall insn in fork" test times
out.
Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping
one syscall would produce:
...
FAIL: $exp: fork: displaced=off: syscall number matches
PASS: $exp: fork: displaced=off: syscall number matches
DUPLICATE: $exp: fork: displaced=off: syscall number matches
...
Fix this by:
- not producing PASS or FAIL in syscall_number_matches, and
- issuing stepi when encountering another syscall.
While we're at it, fix indentation in syscall_number_matches.
Tested on x86_64-linux, specifically:
- openSUSE Tumbleweed (glibc 2.41), and
- openSUSE Leap 15.6 (glibc 2.38).
PR testsuite/32780
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32780
|
|
|
|
The new gcore-memory-usage.exp test puts a PID into a test case name,
causing spurious comparison failures. This patch changes the test
name to avoid this.
|
|
The cooked index needs to allocate names in some cases -- when
canonicalizing or when synthesizing Ada package names. This process
currently uses a vector of unique_ptrs to manage the memory.
Another series I'm writing adds another spot where this allocation
must be done, and examining the result showed that certain names were
allocated multiple times.
To clean this up, this patch introduces a string cache object and
changes the cooked indexer to use it. I considered using bcache here,
but bcache doesn't work as nicely with string_view -- because bcache
is fundamentally memory-based, a temporary copy of the contents must
be made to ensure that bcache can see the trailing \0. Furthermore,
writing a custom class lets us avoid another copy when canonicalizing
C++ names.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I accidentally pushed my work-in-progress branch... revert that. Sorry
for the noise :(.
The list of commits reverted are:
ae2a50a9ae15 attempt to revamp to the CU/TU list
e9386435c94f gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"
6cbd64aa3eb0 gdb/dwarf: add dwarf_source_language_name
32a187da7622 libiberty: move DW_LANG_* definitions to dwarf2.def
b3fa38aef59d gdb/dwarf: move index unit vectors to debug names reader and use them
30ba74418982 gdb/dwarf: track comp and type units count
bedb4e09f292 gdb/dwarf: remove unnecessary braces
b4f18de12c77 gdb/dwarf: use ranged for loop in some pots
Change-Id: I80aed2847025f5b15c16c997680783b39858a703
|
|
Change-Id: I1c8214413583d540c10c9a2322ef2a21f8bb54e7
|
|
This was useful to me, to debug some problems.
Before printing cooked index entries, print a list of CUs and TUs. The
information printed for each is a bit arbitrary, I took a look at the
types and printed what seemed relevant.
An example of output for a CU:
[0] ((dwarf2_per_cu_data *) 0x50f000007840)
type: DW_UT_compile
offset: 0x0
size: 0x1bff
artificial: false
GDB lang: c++
DWARF lang: DW_LANG_C_plus_plus
And for a TU:
[2] ((signatured_type *) 0x511000040000)
type: DW_UT_type
offset: 0x0
size: 0x94
signature: 0x2e966c0dc94b065b
I moved the call to cooked_index_functions::wait before printing the
CU/TU list, otherwise trying to call "maint print objfiles" quickly,
like this, would lead to an internal error:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig -ex "maint print objfiles"
This is because dwarf2_per_cu_data::m_unit_type was not yet set, when
trying to read it. Waiting for the index to be built ensures that it is
set, since setting the unit type is done as a side-effect somewhere.
Change-Id: Ic810ec3bb4d3f5abb481cf1cee9b2954ff4f0874
|
|
Add dwarf_source_language_name, to convert a DW_LANG_* constant to
string. This will be used in a following patch.
Change-Id: I552ebd318e2e770d590de5920edbd0b75075c1b7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In order to get a "DW_LANG_* to string" function:
- move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def
- add the necessary macros in dwarf2.h to generate the enumeration
- add the necessary macros in dwarfnames.c to generate the "to string"
function
include/ChangeLog:
* dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then
undefine.
(enum dwarf_source_language): Remove.
(get_DW_LANG_name): Declare.
* dwarf2.def: Define DW_LANG_* constants.
libiberty/ChangeLog:
* dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define
then undefine.
Change-Id: I440aa2b1f55c7585d7e44c8fa7c41310b0ef2b3a
Cc: binutils@sourceware.org
|
|
Since these vectors contain the CU and TU lists as found in the
.debug_names header, it seems like they are meant to be used by the
.debug_names reader when handling a DW_IDX_compile_unit or
DW_IDX_type_unit attribute. The value of the attribute would translate
directly into an index into one of these vectors.
However there's something fishy: it looks like these vectors aren't
actually used in practice. They are used in the
dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used
anywhere.
The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
dwarf2_per_bfd::get_cu method, assuming that all compile units are
placed before type units in the dwarf2_per_bfd::all_units vector. I see
several problems with that:
1. I found out [1] that the dwarf2_per_bfd::all_units didn't always
have the CUs before the TUs. So indexing dwarf2_per_bfd::all_units
with that assumption will not work.
2. The dwarf2_find_containing_comp_unit function assumes an ordering of
units by section offset (among other criteria) in order to do a
binary search. Even though it's probably commonly the case, nothing
guarantees that the order of CUs and TUs in the .debug_names header
(which defines the indices used to refer to them) will be sorted by
section offset. It's not possible to make
dwarf2_find_containing_comp_unit (assuming it wants to do a binary
search by section offset) and the DW_IDX_compile_unit /
DW_IDX_type_unit handlers use the same vector.
3. I have not tested this, but in the presence of a dwz supplementary
file, the .debug_names reader should probably not put the units from
the main and dwz files in the same vectors to look them up by index.
Presumably, if both the main and dwz files have a .debug_names
index, they have distinct CU / TU lists. So, an CU index of 1 in an
index entry in the main file would refer to a different CU than an
index of 1 in an index entry in the dwz file. The current code
doesn't seem to account for that, it just indexes
dwarf2_per_bfd::all_units.
Since those vectors are kind of specific to the .debug_names reader,
move them there, in the mapped_debug_names_reader struct. Then, update
the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to use them.
[1] https://inbox.sourceware.org/gdb-patches/87a5ab5i5m.fsf@tromey.com/T/#mbdcfe35f94db33e59500eb0d3d225661cab016a4
Change-Id: I3958d70bb3875268143471da745aa09336ab2500
|
|
A subsequent commit will remove the all_comp_units and all_type_units
array views, since the all_units vector will no longer be segmented
between comp and type units. Some callers still need to know the number
of each kind, so track that separately.
Change-Id: I6ef184767a96e5be095bbf9142aa850adbb083ac
|
|
Change-Id: If0b38b860e79771a16ea914af3e337fca0ee3a7d
|
|
I noticed that these loops could be written to avoid the iteration
variable `i`.
Change-Id: Ia3717acbbf732f0337870d35ac60fe6400383324
|
|
dwarf2_per_cu
When running:
$ make check TESTS="gdb.cp/cpexprs-debug-types.exp" RUNTESTFLAGS="--target_board=fission"
I get:
(gdb) break -qualified main
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.h:295: internal-error: version: Assertion `m_dwarf_version != 0' failed.
The problem is that dwarf2_per_cu objects created in the
read_cutu_die_from_dwo code path never have their DWARF version set. A
seemingly obvious solution would be to add a call to
dwarf2_per_cu::set_version in there (there's a patch in the referenced
PR that does that). However, this comment in
read_comp_units_from_section is a bit scary:
/* Init this asap, to avoid a data race in the set_version in
cutu_reader::cutu_reader (which may be run in parallel for the cooked
index case). */
this_cu->set_version (cu_header.version);
I don't know if a DWO file can be read while the cooked indexer runs, so
if it would be a problem here, but I prefer to be safe than sorry. This
patch side-steps the problem by deleting the DWARF version from
dwarf2_per_cu.
The only users of dwarf2_per_cu::version are the loclists callbacks in
`loc.c`. Add the DWARF version to dwarf2_loclist_baton and modify those
callbacks to get the version from there instead. Initialize that new
field in fill_in_loclist_baton.
I like this approach because there is no version field that is possibly
unset now.
I wasn't keen on doing this at first because I thought it would waste
space, but the dwarf2_loclist_baton has 7 bytes of padding at the end
anyway, so we might as well use that.
Cc: Ricky Zhou <ricky@rzhou.org>
Cc: Tom de Vries <tdevries@suse.de>
Cc: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32309
Change-Id: I30d4ede7d67da5d80ff65c6122f5868e1098ec52
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found a small bug coming from a couple of recent patches of mine for
cooked_index_entry::full_name.
First, commit aab26529b30 (Add "Ada linkage" mode to
cooked_index_entry::full_name) added a small hack to optionally
compute the Ada linkage name.
Then, commit aab2ac34d7f (Avoid excessive CU expansion on failed
matches) changed the relevant expand_symtabs_matching implementation
to use this feature.
However, the feature was used unconditionally, causing a bad side
effect: the non-canonical name is now used for all languages, not just
Ada. But, for C++ this is wrong.
Furthermore, consider the declaration of full_name:
const char *full_name (struct obstack *storage,
bool for_main = false,
bool for_ada_linkage = false,
const char *default_sep = nullptr) const;
... and then consider this call in cooked_index::dump:
gdb_printf (" qualified: %s\n",
entry->full_name (&temp_storage, false, "::"));
Oops! The "::" is silently converted to 'true' here.
To fix both of these problems, this patch changes full_name to accept
a flags enum rather than booleans. This avoids the type-safety
problem.
Then, full_name is changed to remove the "Ada" flag when the entry is
not in fact an Ada symbol.
Regression tested on x86-64 Fedora 40.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
eval_op_scope is very similar to
scope_operation::evaluate_for_address. This patch combines the two
into a single method of scope_operation.
Regression tested on x86-64 Fedora 40.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The name "comp_unit_die" is a bit misleading, because it can also
represent a type unit (DW_TAG_type_unit). I think that "top_level_die"
is clear.
Change-Id: Ibaac99897f0ac7499f0f82caeed3385e1e6ee870
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: Ifb80557187c12822bdea7ad400c32c3dce968a7f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that check-include-guards.py doesn't error in certain
situations -- but in situations where the --update flag would cause a
file to be changed.
This patch changes the script to issue an error for any discrepancy.
It also fixes the headers that weren't correct.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Append -l to tst-gmon-gprof-l.sh data files to avoid conflicts with
tst-gmon-gprof.sh data files.
* testsuite/tst-gmon-gprof-l.sh (actual): Append -l.
(expected): Likewise.
(expected_dot): Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
