| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Reduce manual memory management and make the code a bit easier to read.
This helps me a bit in the following patch.
I don't have a way to test this, it's best-effort.
Change-Id: I64af9cd756311deabc6cd95e701dfb21234a40a5
|
|
Change subfile::name to be a string, for easier memory management.
Change buildsym_compunit::m_comp_dir as well, since we move one in to
the other at some point in patch_subfile_names, so it's easier to do
both at the same time. There are various NULL checks for both fields
currently, replace them with empty checks, I think it ends up
equivalent.
I can't test the change in xcoffread.c, it's best-effort.
Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016
|
|
Allocate struct subfile with new, initialize its fields instead of
memset-ing it to 0. Use a unique_ptr for the window after a subfile has
been allocated but before it is linked in the buildsym_compunit's list
of subfile (and therefore owned by the buildsym_compunit.
I can't test the change in xcoffread.c, it's best-effort. I couldn't
find where subfiles are freed in that file, I assume they were
intentionally (or not) leaked.
Change-Id: Ib3b6877de31b7e65bc466682f08dbf5840225f24
|
|
When building with -std=c++11, I get:
CXX dwarf2/read.o
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c: In function ‘void dwarf2_build_psymtabs_hard(dwarf2_per_objfile*)’:
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7130:23: error: expected type-specifier before ‘typeof’
7130 | using iter_type = typeof (per_bfd->all_comp_units.begin ());
| ^~~~~~
This is because typeof is a GNU extension. Use C++'s decltype keyword
instead.
Change-Id: Ieca2e8d25e50f71dc6c615a405a972a54de3ef14
|
|
Now that the psymtab reader has been removed, the
dwarf2_per_cu_data::v union is no longer needed. Instead, we can
simply move the members from dwarf2_per_cu_quick_data into
dwarf2_per_cu_data and remove the "quick" object entirely.
|
|
This removes the DWARF psymtab reader.
|
|
This patch finally enables the new indexer. It is left until this
point in the series to avoid any regressions; in particular, it has to
come after the changes to the DWARF index writer to avoid this
problem.
However, if you experiment with the series, this patch can be moved
anywhere from the patch to wire in the new reader to this point.
Moving this patch around is how I got separate numbers for the
parallelization and background finalization patches.
In the ongoing performance example, this reduces the time from the
baseline of 1.598869 to 0.903534.
|
|
This updates the .debug_names writer to work with the new DWARF
scanner.
|
|
This updates the .gdb_index writer to work with the new DWARF scanner.
The .debug_names writer is deferred to another patch, to make review
simpler.
This introduces a small hack to psyms_seen_size, but is
inconsequential because this function will be deleted in a subsequent
patch.
|
|
This updates the DWARF index writing code to make the addrmap-writing
a bit more generic. Now, it can handle multiple maps, and it can work
using the maps generated by the new indexer.
Note that the new addrmap_index_data::using_index field will be
deleted in a future patch, when the rest of the DWARF psymtab code is
removed.
|
|
To support the removal of partial symtabs from the DWARF index writer,
this makes a small change to have write_address_map accept the address
map as a parameter, rather than assuming it always comes from the
per-BFD object.
|
|
In order to change the DWARF index writer to avoid partial symtabs,
this patch changes the key type in psym_index_map (and renames that
type as well). Using the dwarf2_per_cu_data as the key makes it
simpler to reuse this code with the new indexer.
|
|
We'll be removing all the psymtab code from the DWARF reader. As a
preparatory step, this renames write_psymtabs_to_index to avoid the
"psymtab" name.
|
|
After scanning the CUs, the DWARF indexer merges all the data into a
single vector, canonicalizing C++ names as it proceeds. While not
necessarily single-threaded, this process is currently done in just
one thread, to keep memory costs lower.
However, this work is all done without reference to any data outside
of the indexes. This patch improves the apparent performance of GDB
by moving it to the background. All uses of the index are then made
to wait for this process to complete.
In our ongoing example, this reduces the scanning time on gdb itself
to 0.173937 (wall). Recall that before this patch, the time was
0.668923; and psymbol reader does this in 1.598869. That is, at the
end of this series, we see about a 10x speedup.
|
|
This parallelizes the new DWARF indexer. The indexer's storage was
designed so that each storage object and each indexer is fully
independent. This setup makes it simple to scan different CUs
independently.
This patch creates a new cooked index storage object per thread, and
then scans a subset of all the CUs in each such thread, using gdb's
existing thread pool.
In the ongoing "gdb gdb" example, this patch reduces the wall time
down to 0.668923, from 0.903534. (Note that the 0.903534 is the time
for the new index -- that is, when the "enable the new index" patch is
rebased to before this one. However, in the final series, that patch
appears toward the end. Hopefully this isn't too confusing.)
|
|
Because BFD is not thread-safe, we need to be sure that any section
data that is needed is read before trying to do any DWARF indexing in
the background.
This patch takes a simple approach to this -- it pre-reads the
"info"-related sections. This is done for the main file, but also any
auxiliary files as well, such as the DWO file.
This patch could be perhaps enhanced by removing some now-redundant
calls to dwarf2_section_info::read.
|
|
This introduces a new class that can be used to make the "complaint"
code thread-safe. Instantiating the class installs a new handler that
collects complaints, and then prints them all when the object is
destroyed.
This approach requires some locks. I couldn't think of a better way
to handle this, though, because the I/O system is not thread-safe.
It seemed to me that only GDB developers are likely to enable
complaints, and because the complaint macro handle this case already
(before any locks are required), I reasoned that any performance
degradation that would result here would be fine.
As an aside about complaints -- are they useful at all? I just ignore
them, myself, since mostly they seem to indicate compiler problems
that can't be solved in the GDB world anyway. I'd personally prefer
them to be in a separate tool, like a hypothetical 'dwarflint'.
|
|
This wires the new DWARF indexer into the existing reader code. That
is, this patch makes the modification necessary to enable the new
indexer. It is not actually enabled by this patch -- that will be
done later.
I did a bit of performance testing for this patch and a few others. I
copied my built gdb to /tmp, so that each test would be done on the
same executable. Then, each time, I did:
$ ./gdb -nx
(gdb) maint time 1
(gdb) file /tmp/gdb
This patch is the baseline and on one machine came in at 1.598869 wall
time.
|
|
This implements quick_symbol_functions for the cooked DWARF index.
This is the code that interfaces between the new index and the rest of
gdb. Cooked indexes still aren't created by anything.
For the most part this is straightforward. It shares some concepts
with the existing DWARF indices. However, because names are stored
pre-split in the cooked index, name lookup here is necessarily
different; see expand_symtabs_matching for the gory details.
|
|
This patch adds the code to index DWARF. This is just the scanner; it
reads the DWARF and constructs the index, but nothing calls it yet.
The indexer is split into two parts: a storage object and an indexer
object. This is done to support the parallelization of this code -- a
future patch will create a single storage object per thread.
|
|
This patch introduces the new DWARF index class. It is called
"cooked" to contrast against a "raw" index, which is mapped from disk
without extra effort.
Nothing constructs a cooked index yet. The essential idea here is
that index entries are created via the "add" method; then when all the
entries have been read, they are "finalize"d -- name canonicalization
is performed and the entries are added to a sorted vector.
Entries use the DWARF name (DW_AT_name) or linkage name, not the full
name as is done for partial symbols.
These two facets -- the short name and the deferred canonicalization
-- help improve the performance of this approach. This will become
clear in later patches, when parallelization is added.
Some special code is needed for Ada, because GNAT only emits mangled
("encoded", in the Ada lingo) names, and so we reconstruct the
hierarchical structure after the fact. This is also done in the
finalization phase.
One other aspect worth noting is that the way the "main" function is
found is different in the new code. Currently gdb will notice
DW_AT_main_subprogram, but won't recognize "main" during reading --
this is done later, via explicit symbol lookup. This is done
differently in the new code so that finalization can be done in the
background without then requiring a synchronization to look up the
symbol.
|
|
This updates skip_one_die to speed it up in the cases where either
sibling_offset or size_if_constant are set.
|
|
The new DIE scanner works more or less along the lines indicated by
the text for the .debug_names section, disregarding the bugs in the
specification.
While working on this, I noticed that whether a DIE is interesting is
a static property of the DIE's abbrev. It also turns out that many
abbrevs imply a static size for the DIE data, and additionally that
for many abbrevs, the sibling offset is stored at a constant offset
from the start of the DIE.
This patch changes the abbrev reader to analyze each abbrev and stash
the results on the abbrev. These combine to speed up the new indexer.
If the "interesting" flag is false, GDB knows to skip the DIE
immediately. If the sibling offset is statically known, skipping can
be done without reading any attributes; and in some other cases, the
DIE can be skipped using simple arithmetic.
|
|
The replacement for the DWARF psymbol reader works in a somewhat
different way. The current reader reads and stores all the DIEs that
might be interesting. Then, if it is missing a DIE, it re-scans the
CU and reads them all. This approach is used for both intra- and
inter-CU references.
I instrumented the partial DIE hash to see how frequently it was used:
[ 0] -> 1538165
[ 1] -> 4912
[ 2] -> 96102
[ 3] -> 175
[ 4] -> 244
That is, most DIEs are never used, and some are looked up twice -- but
this is just an artifact of the implementation of
partial_die_info::fixup, which may do two lookups.
Based on this, the new implementation doesn't try to store any DIEs,
but instead just re-scans them on demand. In order to do this,
though, it is convenient to have a cache of DWARF abbrevs. This way,
if a second CU is needed to resolve an inter-CU reference, the abbrevs
for that CU need only be computed a single time.
|
|
This changes the file_and_directory object to be able to compute and
cache the "fullname" in the same way that is done by other code, like
the psymtab reader.
|
|
parallel_for_each currently requires each thread to process at least
10 elements. However, when indexing, it's fine for a thread to handle
just a single CU. This patch parameterizes this, and updates the one
user.
|
|
The new DWARF scanner needs to save the entire cutu_reader object, not
just parts of it. In order to make this possible, this patch
refactors build_type_psymtabs_reader. This change is done separately
because it is easy to review in isolation and it helps make the later
patches smaller.
|
|
This adds a new overload of dwarf5_djb_hash. This is used in
subsequent patches.
|
|
The new DWARF index code works by keeping names pre-split. That is,
rather than storing a symbol name like "a::b::c", the names "a", "b",
and "c" will be stored separately.
This patch introduces some helper code to split a full name into its
components.
|
|
This patch adds an option to skip_one_die that causes it not to skip
child DIEs. This is needed in the new scanner.
|
|
The new DWARF scanner records names as they appear in DWARF. However,
because Ada is unusual, it also decodes the Ada names to synthesize
package components for them. In order for this to work out properly,
gdb also needs a mode where ada_decode can be instructed not to decode
Ada operator names. That is what this patch implements.
|
|
This changes dwarf2_get_pc_bounds so that it does not directly access
a psymtab or psymtabs_addrmap. Instead, both the addrmap and the
desired payload are passed as parameters. This makes it suitable to
be used by the new indexer.
|
|
This adds a new member to dwarf2_per_cu_data that indicates whether
addresses have been seen for this CU. This is then set by the
.debug_aranges reader. The idea here is to detect when a CU does not
have address information, so that the new indexer will know to do
extra scanning in that case.
|
|
Tom de Vries found a failure that we tracked down to a latent bug in
read_addrmap_from_aranges (previously create_addrmap_from_aranges).
The bug is that this code can erroneously reject .debug_aranges when
dwz is in use, due to CUs at duplicate offsets. Because aranges can't
refer to a CU coming from the dwz file, the fix is to simply skip such
CUs in the loop.
|
|
This patch splits create_addrmap_from_aranges into a wrapper function
and a worker function. The worker function is then used in a later
patch.
|
|
thread-pool.h requires CXX_STD_THREAD in order to even be included.
However, there's no deep reason for this, and during review we found
that one patch in the new DWARF indexer series unconditionally
requires the thread pool.
Because the thread pool already allows a task to be run in the calling
thread (for example if it is configured to have no threads in the
pool), it seemed straightforward to make this code ok to use when host
threads aren't available at all.
This patch implements this idea. I built it on a thread-less host
(mingw, before my recent configure patch) and verified that the result
builds.
After the thread-pool change, parallel-for.h no longer needs any
CXX_STD_THREAD checks at all, so this patch removes these as well.
|
|
When running test-case gdb.base/stap-probe.exp with make target check-read1, I
run into this and similar:
...
FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \
info probes stap (timeout)
...
Fix this by using gdb_test_lines instead of gdb_test.
Tested on x86_64-linux.
|
|
I found a bug in the new DWARF reader series, related to the handling
of enumerator names. This bug caused a crash, so this patch adds a
regression test for this particular case. I'm checking this in.
|
|
A while back, I sent a patch to unify the Ada varsize-limit setting
with the more generic max-value-size:
https://sourceware.org/pipermail/gdb-patches/2021-September/182004.html
However, it turns out I somehow neglected to send part of the patch.
Internally, I also removed the "Ada Settings" node from the manual, as
it only documents the obsolete setting.
This patch removes this text.
|
|
A few Ada tests require some debug info in the GNAT runtime. When run
without this info, these tests can't pass. This patch changes these
tests to detect this situation and stop with "untested".
|
|
Earlier versions of the change in
1285ce8629b37f800bf21731ee7c7a8b1b8d0233 used this variable, but not
the final version that landed.
|
|
Replace with equivalent getter/setter macros.
Change-Id: I1042564dd47347337374762bd64ec31b5c573ee2
|
|
Remove MSYMBOL_HAS_SIZE, MSYMBOL_SIZE and SET_MSYMBOL_SIZE, replace them
with equivalent methods.
Change-Id: I6ee1cf82df37e58dff52ea6568ceb4649c7d7538
|
|
Add a getter and a setter for a minimal symbol's type. Remove the
corresponding macro and adjust all callers.
Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
|
|
Remove all macros related to getting and setting some symbol value:
#define SYMBOL_VALUE(symbol) (symbol)->value.ivalue
#define SYMBOL_VALUE_ADDRESS(symbol) \
#define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \
#define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes
#define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block
#define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block
#define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain
#define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue
#define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0)
#define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \
#define BMSYMBOL_VALUE_ADDRESS(symbol) \
#define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \
#define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes
#define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block
Replace them with equivalent methods on the appropriate objects.
Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
|
|
The earlier version of this document had no sections about the
available Fortran intrinsic functions or the Fortran builtin types.
I added two sections 'Fortran intrinsics' and 'Fortran types' to
document the available Fortran language features. The subsection
'Fortran Defaults' has been integrated into the Fortran subsection.
|
|
When working on the files I noted that there was no actual test for a
COMPLEX built from two INTEGERS. I added that now for completion.
|
|
The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept
(some only with Fortran 2003) the optional parameter KIND. This
parameter determines the kind of the associated return value. So far,
implementation of this kind parameter has been missing in GDB.
Additionally, the one argument overload for the CMPLX intrinsic function
was not yet available.
This patch adds overloads for all above mentioned functions to the
Fortran intrinsics handling in GDB.
It re-writes the intrinsic function handling section to use the helper
methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic.
These methods define the action taken when a Fortran intrinsic function
is called with a certain amount of arguments (1/2/3). The helper methods
fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents
to the existing wrap and wrap2 methods.
After adding more overloads to the intrinsics handling, some of the
operation names were no longer accurate. E.g. UNOP_FORTRAN_CEILING
has been renamed to FORTRAN_CEILING as it is no longer a purely unary
intrinsic function. This patch also introduces intrinsic functions with
one, two, or three arguments to the Fortran parser and the
UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added.
|
|
Rename f77_keywords to f_keywords since some of the introduced keywords
in the array are f90 only.
|
|
Currently, when asking GDB to print the type of a Fortran default type
such as INTEGER or REAL, GDB will return the default name of that type,
e.g. "integer"/"real":
(gdb) ptype integer
type = integer
(gdb) ptype real
type = real
For LOGICAL and COMPLEX it would return the actual underlying types
(gdb) ptype logical
type = logical*4
(gdb) ptype complex
type = complex*4
Similarly, GDB would print the default integer type for the underlying
default type:
(gdb) ptype integer*4
type = integer
(gdb) ptype real*4
type = real
(gdb) ptype logical
type = logical*4
(gdb) ptype complex*4
type = complex*4
This is inconsistent and a bit confusing. Both options somehow indicate
what the internal underlying type for the default type is - but I think
the logical/complex version is a bit clearer.
Consider again:
(gdb) ptype integer
type = integer
This indicates to a user that the type of "integer" is Fortran's default
integer type. Without examining "ptype integer*4" I would expect, that
any variable declared integer in the actual code would also fit into a
GDB integer. But, since we cannot adapt out internal types to the
compiler flags used at compile time of a debugged binary, this might be
wrong. Consider debugging Fortran code compiled with GNU and e.g. the
"-fdefault-integer-8" flag. In this case the gfortran default integer
would be integer*8 while GDB internally still would use a builtin_integer,
so an integer of the size of an integer*4 type. On the other hand having
GDB print
(gdb) ptype integer
type = integer*4
makes this clearer. I would still be tempted to fit a variable declared
integer in the code into a GDB integer - but at least ptype would
directly tell me what is going on. Note, that when debugging a binary
compiled with "-fdefault-integer-8" a user will always see the actual
underlying type of any variable declared "integer" in the Fortran code.
So having the code
program test
integer :: a = 5
print *, a ! breakpt
end program test
will, when breaking at breakpt print
(gdb) ptype var
type = integer(kind=4)
or
(gdb) ptype var
type = integer(kind=8)
depending on the compiler flag.
This patch changes the outputs for the REAL and INTEGER default types to
actually print the internally used type over the default type name.
The new behavior for the above examples is:
(gdb) ptype integer
type = integer*4
(gdb) ptype integer*4
type = integer*4
Existing testcases have been adapted to reflect the new behavior.
|
