| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
call_site_target::iterate_over_addresses may look up a minimal symbol.
On platforms like PPC64 that use function descriptors, this may find
an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr
to convert from a function descriptor to the address recorded at the
call site.
I've added a new test case that is based on the internal AdaCore test
that provoked this bug. However, I'm unable to test it as-is on
PPC64.
|
|
PowerPC supports two 128-bit floating point formats, the IBM long double
and IEEE 128-bit float. The issue is the DWARF information does not
distinguish between the two. There have been proposals of how to extend
the DWARF information as discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
but has not been fully implemented.
GCC introduced the _Float128 internal type as a work around for the issue.
The workaround is not transparent to GDB. The internal _Float128 type
name is printed rather then the user specified long double type. This
patch adds a new gdbarch method to allow PowerPC to detect the GCC
workaround. The workaround checks for "_Float128" name when reading the
base typedef from the die_info. If the workaround is detected, the type
and format fields from the _Float128 typedef are copied to the long
double typedef. The same is done for the complex long double typedef.
This patch fixes 74 regression test failures in
gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
default on GCC. It fixes one regression test failure in
gdb.base/complex-parts.exp.
The patch has been tested on Power 10 where GCC defaults to IEEE Float
128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The
patch as also been tested on X86-64 with no new regression failures.
|
|
With DWARF 5, it's possible to produce an empty file name in the File Name
Table of the .debug_line section:
...
The File Name Table (offset 0x112, lines 1, columns 2):
Entry Dir Name
0 1 (indirect line string, offset: 0x2d):
...
Currently, when gdb reads an exec containing such debug info, it segfaults:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
gdb/dwarf2/read.c:18716
18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
...
because read_direct_string transforms "" into a nullptr, and we end up
dereferencing the nullptr.
Note that the behaviour of read_direct_string has been present since repo
creation.
Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
filenames.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
PR symtab/30357
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357
|
|
Unfortunately MinGW doesn't support std::future yet, so this causes the
build to fail. Use GDB's version which provides a fallback for this case.
Tested for regressions on native aarch64-linux.
Approved-By: Tom Tromey <tromey@adacore.com>
|
|
Tom de Vries pointed out a bug in the index-cache background writer --
sometimes it will fail. He also noted that it fails when the number
of worker threads is set to zero. These turn out to be the same
problem -- the cache can't be written to until the per-BFD's
"index_table" member is set.
This patch avoids the race by rearranging the code slightly, to ensure
the cache cannot possibly be written before the member is set.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261
|
|
Fix a functional regression and restore the handling of DW_CC_program
code of DW_AT_calling_convention attribute for determining the name of
the starting function of the program where the DW_AT_main_subprogram
attribute has not been provided, such as with Fortran code compiled with
GCC versions 4.5.4 and below, or where DWARF version 3 or below has been
requested. Without it "main" is considered the starting function. Cf.
GCC PR fortran/43414.
Original code was removed with commit 6209cde4ddb8 ("Delete DWARF
psymtab code"), and then an update to complement commit 81873cc81eff
("[gdb/symtab] Support DW_AT_main_subprogram with -readnow.") has also
been included here.
|
|
The test case in this patch shows an unusual situation: an Ada array
has a dynamic bound, but the bound comes from a frame that's referred
to by the static link. This frame is correctly found when evaluating
the array variable itself, but is lost when evaluating the array's
bounds.
This patch fixes the problem by passing this frame through to
value_at_lazy in the DWARF expression evaluator.
|
|
Hannes pointed out that cooked_index_shard::do_finalize never
populates the seen_names hash table. This patch adds the necessary
store. This reduces memory use a little for "gdb gdb":
(before) Space used: 28909568 (+0 for this command)
(after) Space used: 28884992 (+0 for this command)
What this means, btw, is that in gdb there are not many symbols that
are both mentioned in many CUs and that also require name
canonicalization. It's possible this would differ in other programs.
|
|
Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there
was a silent regression on openSUSE Leap 15.4 for test-case
gdb.cp/m-static.exp, from:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /home/vries/tmp.local-remote-host-native/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
(gdb)
...
to:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8: const int gnu_obj_4::everywhere;^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
8: const int gnu_obj_4::everywhere;^M
(gdb)
...
Another regression was found due to that commit, and it was fixed in commit
99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by
limiting the scope of the fix in the original commit.
Fix this regression by yet further limiting the scope of that fix, making sure
that this bit in dwarf_decode_lines is executed again for m-static1.cc:
...
/* Make sure a symtab is created for every file, even files
which contain only variables (i.e. no code with associated
line numbers). */
...
Tested on x86_64-linux.
PR symtab/30265
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265
|
|
I found an upcast from template_symbol to symbol. This was necessary
long ago, but since symbols use inheritance now, it is not. This
patch removes it. Tested by rebuilding.
|
|
This renames objfile_type to be an overload of builtin_type, in
preparation for their unification.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the set type creation function to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the set, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the array type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
placement of the index type of the array, which is what this patch
implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the range type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the range, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_pointer_type and init_pointer_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_decfloat_type and init_decfloat_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_float_type and init_float_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_boolean_type and init_boolean_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_character_type and init_character_type by using a
type allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_integer_type and init_integer_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This removes init_type, replacing all uses with the new type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This removes alloc_type, replacing all uses with the new type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Simon pointed out a line table regression, and after a couple of false
starts, I was able to reproduce it by hand using his instructions.
The bug is that most of the code in do_mixed_source_and_assembly uses
unrelocated addresses, but one spot does:
pc = low;
... after the text offset has been removed.
This patch fixes the problem by introducing a new type to represent
unrelocated addresses in the line table. This prevents this sort of
bug to some degree (it's still possible to manipulate a CORE_ADDR in a
bad way, this is unavoidable).
However, this did let the compiler flag a few spots in that function,
and now it's not possible to compare an unrelocated address from a
line table with an ordinary CORE_ADDR.
Regression tested on x86-64 Fedora 36, though note this setup never
reproduced the bug in the first place. I also tested it by hand on
the disasm-optim test program.
|
|
This adds various methods and operators to gdb_mpz, as a step toward
hiding the implementation.
This only adds the operators that were needed. Many more could be
added as required.
|
|
This changes linetables to not add the text offset to the addresses
they contain. I did this in a few steps, necessarily combined
together in one patch: I renamed the 'pc' member to 'm_pc', added the
appropriate accessors, and then recompiled. Then I fixed all the
errors. Where possible I generally chose to use the raw_pc accessor,
as it is less expensive.
Note that this patch discounts the possibility that the text section
offset might cause wraparound in the addresses in the line table.
However, this was already discounted -- in particular,
objfile_relocate1 did not re-sort the table in this scenario. (There
was a bug open about this, but as far as I can tell this has never
happened, it's not even clear what inspired that bug.)
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Replace spaces with tabs in a bunch of places.
Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
|
|
I ran across the attribute reprocessing code recently and noticed that
it unconditionally sets members of the CU when reading a DIE. Also,
each spot reading attributes needs to be careful to "reprocess" them
as a separate step.
This seemed excessive to me, because while reprocessing applies to any
DIE, setting the CU members is only necessary for the toplevel DIE in
any given CU.
This patch introduces a new read_toplevel_die function and changes a
few spots to call it. This is easily done because reading the
toplevel DIE is already special.
I left the reprocessing flag and associated checks in attribute. It
could be stripped out, but I am not sure it would provide much value
(maybe some iota of performance).
Regression tested on x86-64 Fedora 36.
|
|
Simon points out that the new maint command, intended to fix a
regression, also introduces a new regression in "maint selftest".
This patch fixes the error. I did a full regression test on x86-64
Fedora 36.
|
|
Now that index cache files are written in the background, one test in
index-cache.exp is racy -- it assumes that the cache file will have
been written during startup.
This patch fixes the problem by introducing a new maintenance command
to wait for all pending writes to the index cache.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong,
they end in 2022 instead of 2023. I suppose because I posted (or at
least prepared) the patches in 2022 but merged them in 2023, and forgot
to update the year. I found a bunch of other files that are in the same
situation. Fix them all up.
Change-Id: Ia55f5b563606c2ba6a89046f22bc0bf1c0ff2e10
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Once a baton is stored in a struct type, it doesn't make sense to
modify it. This patch constifies the API.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
gdbtypes treats dynamic property batons as 'void *', but in actuality
the only users all use dwarf2_property_baton. This patch changes this
code to be type-safe. If a new type is needed here, it seems like
that too could be done in a type-safe way.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In C++ it is possible to use an empty enum as a strong typedef. For
example, a user could write:
enum class my_type : unsigned char {};
Now my_type can be used like 'unsigned char' except the compiler will
not allow implicit conversion too and from the native 'unsigned char'
type.
This is used in the standard library for things like std::byte.
Currently, when GDB prints a value of type my_type, it looks like
this:
(gdb) print my_var
$1 = (unknown: 0x4)
Which isn't great. This gets worse when we consider something like:
std::vector<my_type> vec;
When using a pretty-printer, this could look like this:
std::vector of length 2, capacity 2 = {(unknown: 0x2), (unknown: 0x4)}
Clearly not great. This is described in PR gdb/30148.
The problem here is in dwarf2/read.c, we assume all enums are flag
enums unless we find an enumerator with a non-flag like value.
Clearly an empty enum contains no non-flag values, so we assume the
enum is a flag enum.
I propose adding an extra check here; that is, an empty enum should
never be a flag enum.
With this the above cases look more like:
(gdb) print my_var
$1 = 4
and:
std::vector of length 2, capacity 2 = {2, 4}
Which look much better.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30148
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The new DWARF cooked indexer interacts poorly with the DWARF index
cache. In particular, the cache will require gdb to wait for the
cooked index to be finalized. As this happens in the foreground, it
means that users with this setting enabled will see a slowdown.
This patch changes gdb to write the cache entry a worker thread. (As
usual, in the absence of threads, this work is simply done immediately
in the main thread.)
Some care is taken to ensure that this can't crash, and that gdb will
not exit before the task is complete.
To avoid use-after-free problems, the DWARF per-BFD object explicitly
waits for the index cache task to complete.
To avoid gdb exiting early, an exit observer is used to wait for all
such pending tasks.
In normal use, neither of these waits will be very visible. For users
using "-batch" to pre-generate the index, though, it would be.
However I don't think there is much to be done about this, as it was
the status quo ante.
|
|
The DWARF index does not need access to the objfile or per-objfile
objects when writing -- it's entirely based on the objfile-independent
per-BFD data.
This patch implements this idea by changing the entire API to only be
passed the per-BFD object. This simplifies some lifetime reasoning
for the next patch.
This patch removes some code that ensures that the BFD came from a
file. It seems to me that checking for the existence of a build-id is
good enough for the index cache.
|
|
Currently we only trust epilogue unwind info only for gcc >= 4.5.0.
This has the effect that we don't trust epilogue unwind info for:
- unknown producers (CU without DW_AT_producer attribute)
- non-gcc producers (say, clang).
Instead, only distrust epilogue unwind info only for gcc < 4.5.0.
|
|
This converts block_linkage_function to be a method. This was mostly
written by script.
|
|
This converts block_scope, block_set_scope, block_using, and
block_set_using to be methods. These are all done at once to make it
easier to also convert block_initialize_namespace at the same time.
This was mostly written by script.
|
|
The new DWARF indexer broke "start" for some languages.
For D, it is broken because, while the code in cooked_index_shard::add
specifically excludes Ada, it fails to exclude D. This means that the
C "main" will be detected as "main" here -- whereas what is intended
is for the code in find_main_name to use d_main_name to find the name.
The Rust compiler, on the other hand, uses DW_AT_main_subprogram.
However, the code in dwarf2_build_psymtabs_hard fails to create a
fully-qualified name, so the name always ends up as plain "main".
For D and Ada, a very simple approach suffices: remove the check
against "main" from cooked_index_shard::add. This also has the
benefit of slightly speeding up DWARF indexing. I assume this
approach will work for Pascal and Modula-2 as well, but I don't have a
way to test those at present.
For Rust, though, this is not sufficient. And, computing the
fully-qualified name in dwarf2_build_psymtabs_hard will crash, because
cooked_index_entry::full_name uses the canonical name -- and that is
not computed until after canonicalization.
However, we don't want to wait for canonicalization to be done before
computing the main name. That would remove any benefit from doing
canonicalization is the background.
This patch solves this dilemma by noticing that languages using
DW_AT_main_subprogram are, currently, disjoint from languages
requiring canonicalization. Because of this, we can add a parameter
to full_name to let us avoid crashes, slowdowns, and races here.
This is kind of tricky and ugly, so I've tried to comment it
sufficiently.
While doing this, I had to change gdb.dwarf2/main-subprogram.exp. A
different possibility here would be to ignore the canonicalization
needs of C in this situation, because those only affect certain types.
However, I chose this approach because the test case is artificial
anyhow.
A long time ago, in an earlier threading attempt, I changed the global
current_language to be a function (hidden behind a macro) to let us
attempt lazily computing the current language. Perhaps this approach
could still be made to work. However, that also seemed rather tricky,
more so than this patch.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30116
|
|
I noticed a couple of spots in go-lang.c that could be improved by
using unique_ptr.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
This changes value::bits_synthetic_pointer to return bool and fixes up
some fallout from this.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_stack to be a bool and updates the various uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_initialized to be a bool and updates the various
uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
This changes value::m_lazy to be a bool and updates the various uses.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
Move everything related to reading .debug_names from read.c to
read-debug-names.c. The only entry point exposed by
read-debug-names.{c,h} is dwarf2_read_debug_names.
Change-Id: I18b23f3c7a61b14abc3a46e4bf559bc2d078e8bc
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Move everything related to reading .gdb_index from read.c to
read-gdb-index.c. The only entry point exposed by read-gdb-index.{c,h}
is dwarf2_read_gdb_index.
Change-Id: I1e32c8f0720086538de8d2f612f27545377099bc
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The following 2 patches move .gdb_index and .debug_names reading code to
their own file. Prepare this by exposing some things used by that code
to read.h.
Change-Id: If8ef135758a2ff0ab3b765cc92596da8189f3bbd
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This renaming helps make it clearer that these entites (classes,
functions) are specific to .gdb_index only, they are not shared with the
.debug_names handling.
Change-Id: I1a3cf3dbf450b62d1a0879d9aedd26397abdfd13
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing
all uses with a call to value::lval.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch turns a grab bag of value functions to methods of value.
These are done together because their implementations are
interrelated.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
