| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix the following codespell warnings:
...
$ codespell --config gdb/contrib/setup.cfg gdb/config
gdb/config/djgpp/README:178: unitialized ==> uninitialized
gdb/config/djgpp/djconfig.sh:126: conatain ==> contain
...
and add gdb/config to the pre-commit codespell configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.dwarf2/fission-with-type-unit.exp with a remote
host configuration, say host board local-remote-host and target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) maint expand-symtabs^M
During symbol reading: Could not find DWO CU \
fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0x2d7 \
[in module /home/remote-host/fission-with-type-unit]^M
warning: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced \
by CU at offset 0x2d7 [in module /home/remote-host/fission-with-type-unit]^M
(gdb) FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs
...
Fix this by adding the missing download to remote host of the .dwo file.
Tested by running make-check-all.sh on x86_64-linux.
|
|
When writing the test, I copied these copyright entries from another
file but forgot to adjust the dates, do that now.
Change-Id: Ie458ad4ec81062b5ef24f78334f3d0920c99b318
|
|
gdb.threads/infcall-from-bp-cond-simple.exp
With a gdb 15.2 based package and test-case
gdb.threads/infcall-from-bp-cond-simple.exp, I ran into:
...
Thread 2 "infcall-from-bp" hit Breakpoint 3, function_with_breakpoint () at \
infcall-from-bp-cond-simple.c:51
51 return 1; /* Nested breakpoint. */
Error in testing condition for breakpoint 2:
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(function_with_breakpoint) will be abandoned.
When the function is done executing, GDB will silently stop.
[Thread 0x7ffff73fe6c0 (LWP 951822) exited]
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_bp_cond_hits_breakpoint: continue
...
The test fails because it doesn't expect the "[Thread ... exited]" message.
I have tried to reproduce this test failure, both using 15.2 and current
trunk, but haven't managed.
Regardless, I think the message is harmless, so allow it to occur, both in
run_bp_cond_segfaults and run_bp_cond_hits_breakpoint.
Tested on x86_64-linux.
PR testsuite/32785
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32785
|
|
On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into:
...
(gdb) p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: $exp: o1: printed size of optimized out vla
...
The variable a has type 0xbf:
...
<1><bf>: Abbrev Number: 12 (DW_TAG_array_type)
<c0> DW_AT_type : <0xe3>
<c4> DW_AT_sibling : <0xdc>
<2><c8>: Abbrev Number: 13 (DW_TAG_subrange_type)
<c9> DW_AT_type : <0xdc>
<cd> DW_AT_upper_bound : 13 byte block:
a3 1 5a 23 1 8 20 24 8 20 26 31 1c
(DW_OP_entry_value: (DW_OP_reg10 (a0));
DW_OP_plus_uconst: 1; DW_OP_const1u: 32;
DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
DW_OP_lit1; DW_OP_minus)
...
which has an upper bound using a DW_OP_entry_value, and since the
corresponding call site contains no information to resolve the value of a0 at
function entry:
...
<2><6b>: Abbrev Number: 6 (DW_TAG_call_site)
<6c> DW_AT_call_return_pc: 0x638
<74> DW_AT_call_origin : <0x85>
...
evaluting the dwarf expression fails, and we get <optimized out>.
My first thought was to try breaking at *f1 instead of f1 to see if that would
help, but actually the breakpoint resolved to the same address.
In other words, the inferior is stopped at function entry.
Fix this by resolving DW_OP_entry_value when stopped at function entry by
simply evaluating the expression.
This handles these two cases (x86_64, using reg rdi):
- DW_OP_entry_value: (DW_OP_regx: 5 (rdi))
- DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4)
Tested on x86_64-linux.
Tested gdb.base/vla-optimized-out.exp on riscv64-linux.
Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on
riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so
I haven't tested the current version there.
|
|
The Linaro CI reported a regression [1] in test-case
gdb.base/step-over-syscall.exp due to commit 674d4856730 ("[gdb/testsuite] Fix
gdb.base/step-over-syscall.exp with glibc 2.41").
Investigation shows that it's a progression in the sense that the test-case
fails at a later point than before.
The cause for the test-case failure is that an atomic sequence
ldaex/adds/strex is not skipped over when instruction stepping, leading to a
hang (in the sense of not being able to instruction-step out of the loop
containing the atomic sequence).
The arm target does have support for recognizing atomic sequences, but it
fails because it doesn't recognize the ldaex insn.
Fix this by:
- adding a new function ldaex_p which recognizes ldaex instructions, based
on information found in opcodes/arm-dis.c, and
- using ldaex_p in thumb_deal_with_atomic_sequence_raw.
I was not able to reproduce the failure in its original setting, but I
was able to do so using a test.c:
...
static void exit (int status) {
while (1)
;
}
void _start (void) {
int a = 0;
__atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE);
exit (0);
}
...
compiled like this:
...
$ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static
...
giving this atomic sequence of 32-bit Thumb-2 instructions:
...
100ce: e8d3 1fef ldaex r1, [r3]
100d2: f101 0101 add.w r1, r1, #1
100d6: e843 1200 strex r2, r1, [r3]
...
Without the fix, after 100 stepi's we're still in _start (and likewise with
10.000 stepi's):
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100dc in _start ()
1: x/i $pc
=> 0x100dc <_start+26>: bne.n 0x100ce <_start+12>
...
but with the fix we've managed to progress to exit:
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100c0 in exit ()
1: x/i $pc
=> 0x100c0 <exit+8>: b.n 0x100c0 <exit+8>
...
Having addressed the "-mthumb" case, do we need a similar fix for "-marm"?
Adding "-marm" in the compilation line mentioned above gives the following
atomic sequence:
...
100e4: e1931e9f ldaex r1, [r3]
100e8: e2811001 add r1, r1, #1
100ec: e1832f91 strex r2, r1, [r3]
...
and gdb already recognizes it as such because of this statement:
...
if ((insn & 0xff9000f0) != 0xe1900090)
return {};
...
The trouble with this statement is that it requires knowledge of arm
instruction encoding to understand which cases it does and doesn't cover.
Note that the corresponding comment only mentions ldrex:
...
/* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */
...
but evidently at least some forms of ldaex are also detected.
So, also use ldaex_p in arm_deal_with_atomic_sequence_raw. This may or may
not be redundant, but at least ldaex_p is explicit and precise about what it
supports.
Likewise for stlex (generated when using __ATOMIC_RELEASE instead of
__ATOMIC_ACQUIRE in the example above).
Tested in arm-linux chroot on aarch64-linux.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Co-Authored-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/32796
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32796
[1] https://linaro.atlassian.net/browse/GNU-1541
|
|
print_doc_line uses a static buffer and manually manages memory. I
think neither of these is really needed, so this patch rewrites the
function to use std::string. The new implementation tries to avoid
copying when possible.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
These includes are reported as unused by clangd.
Change-Id: I1cde043244f9efe350310955b2a02ac874be12b3
|
|
Commit 71a48752660b ("gdb/dwarf: remove create_dwo_cu_reader")
introduced a regression when handling files compiled with "-gsplit-dwarf
-fdebug-types-section" (at least with clang):
$ cat test.cpp
#include <vector>
int main()
{
std::vector<int> v;
return v.size ();
}
$ clang++ -O0 test.cpp -g -gdwarf-5 -gsplit-dwarf -fdebug-types-section -o test
$ ./gdb -nx -q --data-directory=data-directory ./test -ex "maint expand-symtabs"
Reading symbols from ./test...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6159: internal-error: setup_type_unit_groups: Assertion `per_cu->is_debug_types' failed.
In the main file, we have a skeleton CU with a certain DWO ID:
0x00000000: Compile Unit: ..., unit_type = DW_UT_skeleton, ..., DWO_id = 0x146eaa4daf5deef2, ...
In the .dwo file, the first unit is a type unit with a certain type
signature:
0x00000000: Type Unit: ..., unit_type = DW_UT_split_type, ..., type_signature = 0xb499dcf29e2928c4, ...
and the split compile unit matching the DWO ID from the skeleton from
the main file comes later:
0x0000117f: Compile Unit: ..., unit_type = DW_UT_split_compile, ..., DWO_id = 0x146eaa4daf5deef2, ...
The problem introduced by the aforementioned commit is that when
creating a dwo_unit structure representing the type unit, we use the
signature (DWO id) from the skeleton, instead of the signature from the
type unit's header. As a result, all dwo_units get created with the
same signature (the DWO id) and only the first unit gets inserted in the
hash table. When looking up the comp unit by DWO ID later on, we
wrongly find the type unit, and try to expand a type unit as a comp
unit, hitting the assert.
Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which
yields a dwarf2_cu built from parsing the type unit's header. This
dwarf2_cu contains the comp_unit_header with the correct signature. Fix
the code to use `reader.cu ()` again.
Another thing that enables this bug is the fact that since DWARF 5, type
and compile units are all in .debug_info, and therefore read by
create_cus_hash_table, so they both end up in dwo_file::cus. Type units
should end up in dwo_file::tus, otherwise they won't be found by
lookup_dwo_cutu. This bug hasn't given me trouble so far, so I'm not
fixing it right now, but it's on my todo list.
The problem can be seen with some tests, when using the
dwarf5-fission-debug-types board:
$ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ...
FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error)
But this patch also adds a DWARF assembler-based test that triggers the
internal error.
Note that the new test does not use the build_executable_and_dwo_files
proc, because I found that it is subtly broken and doesn't work to put
multiple units in a single .dwo file. The debug abbrev offset field in
the second unit's header would be 0, when it should have been something
else. The problem is that no linking is ever done to generate the .dwo
file, so the relocation that would apply for this field is never
applied. Instead, I generate two DWARF debug infos separately and link
the .dwo file using gdb_compile, it seems to work fine.
Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix what looks like a copy paste error resulting in the wrong abbrev
section name. The resulting section name in my test was
".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo".
Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add support to the DWARF assembler to generate DWARF 5 split compile
units. The assembler knows how to generate DWARF < 5 split compile
units (fission), DWARF 5 compile units, but not DWARF 5 split compile
units. What's missing is:
- using the right unit type in the header: skeleton for the unit in the
main file and split_compile for the unit in the DWO file
- have a way for the caller to specify the DWO ID that will end up in
the unit header
Add a dwo_id parameter to the cu proc. In addition to specifying the
DWO ID, the presence of this parameter tells the assembler to use the
skeleton or split_compile unit type.
This is used in a subsequent patch.
Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I'm currently fixing bugs and performance issues when GDB encounters
this particular configuration. Since split DWARF + type units makes GDB
take some code paths not taken by any other board files, I think it
deserves to be its own board file. One particularity is that the
produced .dwo files have a .debug_info.dwo section that contains some
ype units, in addition to the compile unit.
Add that board to make-check-all.sh.
Change-Id: I245e6f600055a27e0c31f1a4a9af1f68292fe18c
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
and move it from gdb.base to gdb.arch as it's a target specific test.
Reviewed-by: Maciej W. Rozycki <macro@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Consider the following scenario:
...
$ cat hello
int
main (void)
{
printf ("hello\n");
return 0;
}
$ gcc -x c hello -g
$ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x4005db: file hello, line 6.
Starting program: /data/vries/gdb/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at hello:6
6 printf ("hello\n");
...
This doesn't produce highlighting for line 6, because:
- pygments is used for highlighting instead of source-highlight, and
- pygments guesses the language for highlighting only based on the filename,
which in this case doesn't give a clue.
Fix this by:
- adding a language parameter to the extension_language_ops.colorize interface,
- passing the language as found in the debug info, and
- using it in gdb.styling.colorize to pick the pygments lexer.
The new test-case gdb.python/py-source-styling-2.exp excercises a slightly
different scenario: it compiles a c++ file with a .c extension, and checks
that c++ highlighting is done instead of c highlighting.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
|
|
I noticed that if deferred curses initialization fails, for instance when
using TERM=dumb, and we try the same again, we run into the same error:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
...
I think it's better to try deferred curses initialization only once.
Fix this by changing bool tui_finish_init into a tribool, and using
TRIBOOL_UNKNOWN to represent the "initialization failed" state, such that we
get instead:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
GDB has had basic support for linkage namespaces for some time already,
but only in the sense of managing multiple copies of the same shared
object being loaded, and a very fragile way to find the correct copy of
a symbol (see PR shlibs/32054).
This commit is the first step in improving the user experience around
multiple namespace support. It introduces a user-friendly identifier for
namespaces, in the format [[<number>]], that will keep consistent between
dlmopen and dlclose calls. The plan is for this identifier to be usable
in expressions like `print [[1]]::var` to find a specific instance of a
symbol, and so the identifier must not be a valid C++ or Ada namespace
identifier, otherwise disambiguation becomes a problem. Support for
those expressions has not been implemented yet, it is only mentioned to
explain why the identifier looks like this.
This syntax was chosen based on the C attributes, since nothing in GDB
uses a similar syntax that could confuse users. Other syntax options
that were explored were "#<number>" and "@<number>". The former was
abandoned because when printing a frame, the frame number is also
printed with #<number>, so in a lot of the context in which that the
identifier would show up, it appears in a confusing way. The latter
clashes with the array printing syntax, and I believe that the having
"@N::foo" working completely differently to "foo@2" would also lead to a
bad user experience.
The namespace identifiers are stored via a vector inside svr4_info
object. The vector stores the address of the r_debug objects used by
glibc to identify each namespace, and the user-friendly ID is the index
of the r_debug in the vector. This commit also introduces a set storing
the indices of active namespaces. The glibc I used to develop this patch
(glibc 2.40 on Fedora 41) doesn't allow an SO to be loaded into a
deactivated namespace, and requesting a new namespace when a namespace
was previously closed will reuse that namespace. Because of how this is
implemented, this patch lets GDB easily track the exact namespace IDs
that the inferior will see.
Finally, two new solib_ops function pointers were added, find_solib_ns
and num_active_namespaces, to allow code outside of solib-svr4 to find
and use the namespace identifiers and the number of namespaces,
respectively. As a sanity check, the command `info sharedlibrary` has
been changed to display the namespace identifier when the inferior has
more than one active namespace. With this final change, a couple of tests
had to be tweaked to handle the possible new column, and a new test has
been created to make sure that the column appears and disappears as
needed, and that GDB can track the value of the LMID for namespaces.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This cleans up the last codespell reports in the Guile directory and
adds gdb/guile to pre-commit.
It also tells codespell to ignore URLs. I think this is warranted
because many URLs don't really contain words per se; and furthermore
if any URL-checking is needed at all, it would be for liveness and not
spelling.
Also I was wondering why the codespell config is in contrib and not
gdb/setup.cfg.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
This cleans up the last codespell report in the Python directory and
adds gdb/python to pre-commit.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
"cache" is just a bit too generic to be clear.
Change-Id: I8bf01c5fe84e076af1afd2453b1a115777630271
|
|
I ran codespell on gdb/*.[chyl] and fixed a bunch of simple typos.
Most of what remains is trickier, i.e., spots where a somewhat natural
name of something in the code is flagged as a typo.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
In commit af2b87e649b ("[gdb/testsuite] Add xfail for PR gcc/101633"), I added
an xfail that was controlled by variable old_gcc, triggering the xfail for
gcc 7 and before, but not for gcc 8 onwards:
...
set old_gcc [expr [test_compiler_info {gcc-[0-7]-*}]]
...
In commit 1411185a57e ("Introduce and use gnat_version_compare"), this changed
to:
...
set old_gcc [gnat_version_compare <= 7]
...
which still triggered the xfail for gcc 7, because of a bug in
gnat_version_compare.
After that bug got fixed, the xfail was no longer triggered because the gnatmake
version is 7.5.0, and [version_compare {7 5 0} <= {7}] == 0.
We could have the semantics for version_compare where we clip the input
arguments to the length of the shortest, and so we'd have
[version_compare {7 5 0} <= {7}] == [version_compare {7} <= {7}] == 1.
But let's stick with the current version-sort semantics, and fix this by
using [gnat_version_compare < 8] instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a test-case gdb.testsuite/version-compare.exp that excercises proc
version_compare, and a note to proc version_compare that it considers
v1 < v1.0 instead of v1 == v1.0.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Some architectures, such as MIPS, have signed addresses and this changes
read_addrmap_from_aranges to record them as signed when required.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32658
Approved-By: Tom Tromey <tom@tromey.com>
|
|
gccrs still can't process all of gdb's Rust tests, but I did manage to
manually test it on a few. In addition to filing some bug reports, I
came up with this patch.
There are two fixes here. First, gccrs emits tuple field names as
integers ("0", "1", etc) whereas rustc uses a leading double
underscore ("__0", "__1", etc). This patch changes gdb to accept the
gccrs output, which IMO makes sense (and for which there's already a
rustc feature request).
Second, it changes rust_struct_anon::evaluate to use check_typedef.
This is a gdb necessity in general, so could be described as an
oversight; but in this case it works around the gccrs oddity that most
named types are emitted as DW_TAG_typedef. I've filed a gccrs bug
report for that.
|
|
The cooked index worker maintains the state for the various state
transition in the scanner. It is held by the cooked_index while
scanning is in progress, then deleted once this has completed.
I noticed that none of the arguments to cooked_index::done_reading
were really needed -- the cooked_index already has access to the
worker should it need it. Removing these parameters makes the code a
bit simpler and also cleans up some confusing code around the use of
the deferred warnings object.
Regression tested on x86-64 Fedora 40.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
copyright.py needed an addition for unordered_dense.h.
Then, when running it, I saw it complain about some .pyc files I had
in the source tree. I don't know why I had these, but the script
should ignore them.
For this, Kévin suggested using "git ls-files" to determine which
files to update -- that should automatically exclude any random files
in the tree. This version of the patch makes this change.
There were complaints about some sim/ppc files that were renamed.
Ignoring the entire directory seems simpler given the comment.
I also made a few more minor changes:
* Removed the 'CVS' exclusion, as this hasn't been relevant in years.
* Moved the 'copying.c' exclusion to EXCLUDE_LIST
* Changed the script to run from the top level (we could have it
automatically find this if we really wanted).
After this lands, I plan to run it and check in the result. The patch
may be too large (and certainly too uninteresting) to post, so if/when
this happens I will send a brief note to the list about it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Remove some includes reported as unused by clangd.
Change-Id: I841938c3c6254e4f0d154a1e172c4968ff326333
|
|
Remove includes reported as unused by clangd.
Change-Id: I12e5cf254d211f42f3cfdab90d1f42a5986e53a3
|
|
Compile a 32-bit x86 executable and then stop within a system call.
Change the sysroot to a non-existent directory, GDB should try (and
fail) to reload the currently loaded shared libraries. However, GDB
should retain the symbols for the vDSO library as that is not loaded
from the file system.
Check the backtrace to ensure that the __kernel_vsyscall symbol is
still in the backtrace, this indicates GDB still has the vDSO
symbols available.
This test was present in Fedora for a long time and was
originally written by Jan Kratochvil for this fix
829a902da291e72ad17e8c44fa8d9ead3db41b1f.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The relocate method of addrmap is unnecessarily virtual. Only
addrmap_fixed provides a meaningful implementation. Move the method to
addrmap_fixed only and make it non-virtual.
Change-Id: If61d5e70abc12c17d1e600adf0dd0707e77a6ba2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add support for the gdb dir in the codespell section of gdb/contrib/setup.cfg,
specifically adding files in the skip line.
This allows us to run codespell from the command line on the gdb dir:
...
$ codespell --config gdb/contrib/setup.cfg gdb 2>/dev/null | wc -l
1665
...
without running into warnings in generated files.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This updates the cooked_index comment with some notes about object
lifetimes, in an attempt to make navigating this code a bit simpler.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The two readers currently using cooked_index_worker shared some code.
This patch factors this out into a new "done_reading" method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
cooked_index_worker::result_type is an ad hoc tuple type used for
transferring data between phases of the indexer. It's a bit unwieldy
and another patch I'm working on would be somewhat nicer without it.
This patch removes the type. Now cooked_index_ephemeral objects are
transferred instead, which is handy because they already hold the
needed state.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
It was convenient to add a 'clear' method to addrmap_mutable. The
cleanest way to do this was to change the class to lazily initialize
its 'tree' member. This also makes addrmap_mutable::operator= a bit
less weird.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This updates the "See xyz.h" comments for all the methods that were
moved earlier in this series. Perhaps I should have removed them
instead.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This moves the cooked_index_worker class to cooked-index-worker.[ch].
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes cooked-index-worker.h to include the new header files.
This breaks the circular dependency that would otherwise be introduced
in the next patch.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This moves cooked_index_shard to a couple of new files,
dwarf2/cooked-index-shard.[ch]. The rationale is the same as the
previous patch: cooked-index.h had to be split to enable other
cleanups.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This moves cooked_index_entry and some related helper code to a couple
of new files, dwarf2/cooked-index-entry.[ch].
The main rationale for this is that in order to finish this series and
remove "cooked_index_worker::result_type", I had to split
cooked-index.h into multiple parts to avoid circular includes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
language_requires_canonicalization is only called from cooked-index.c,
so mark it as static.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This renames cooked_index_storage to cooked_index_worker_result,
making its function more clear. It also updates the class comment to
as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
A discussion with Simon made me realize that cooked_index_storage
isn't a very clear name, especially now that it's escaped from read.c.
While it does provide some storage (I guess any object does in a
sense), it is really a helper for cooked_index_worker -- a temporary
object that is destroyed after reading has completed.
This patch renames this file. Later patches will rename the class and
move cooked_index_worker here, something I think is reasonable given
that cooked_index_storage is really something of a helper class for
cooked_index_worker.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Tom de Vries pointed out that my earlier change to
gnat_version_compare made it actually test gcc's version -- not
gnat's.
This patch changes gnat_version_compare to examine gnatmake's version,
while preserving the nicer API.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Commit
c221b2f77080 Testsuite: Add gdb_can_simple_compile
changed the source file name extension of the test program from .s to .c
resulting in compile fails. This, in turn, causes is_aarch32_target
checks to fail.
Change the test source from an assembly program to a C program using
inline assembly.
is_amd64_regs_target had a similar problem, which was fixed by commit
224d30d39365 testsuite: fix is_amd64_regs_target
This fix — and commit message — are mostly copied from it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In enum gdb_syscall, there are 3 entries that do not have the gdb_sys_ prefix
...
$ grep gdb_old_ gdb/linux-record.h
gdb_old_select = 82,
gdb_old_readdir = 89,
gdb_old_mmap = 90,
...
like all the other entries:
...
gdb_sys_restart_syscall = 0,
gdb_sys_exit = 1,
gdb_sys_fork = 2,
gdb_sys_read = 3,
...
The three correspond to these entries in
arch/x86/entry/syscalls/syscall_32.tbl:
...
<number> <abi> <name> <entry point> [<compat entry point> [noreturn]]
82 i386 select sys_old_select compat_sys_old_select
89 i386 readdir sys_old_readdir compat_sys_old_readdir
90 i386 mmap sys_old_mmap compat_sys_ia32_mmap
...
As we can see, the enum uses the entry point name, but without the sys_
prefix.
There doesn't seem to be a good reason for this.
There's another enum value:
...
gdb_sys_old_getrlimit = 76,
...
corresponding to:
...
76 i386 getrlimit sys_old_getrlimit compat_sys_old_getrlimit
...
where we do use the sys_ prefix.
Fix this by consistenly using the gdb_sys_ prefix in enum gdb_syscall.
No functional changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Now that we've started using codespell, remove gdb/contrib/spellcheck.sh and
associated file gdb/contrib/common-misspellings.txt.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In noticed two occurrences of "if (strpbrk (...))".
Fix this style issue by checking against nullptr.
|
|
Add a pre-commit codespell hook for directories gdbsupport and gdbserver,
which are codespell-clean:
...
$ pre-commit run codespell --all-files
codespell................................................................Passed
...
A non-trivial question is where the codespell configuration goes.
Currently we have codespell sections in gdbsupport/setup.cfg and
gdbserver/setup.cfg, but codespell doesn't automatically use those because the
pre-commit hook runs codespell at the root of the repository.
A solution would be to replace those 2 setup.cfg files with a setup.cfg in the
root of the repository. Not ideal because generally we try to avoid adding
files related to subdirectories at the root.
Another solution would be to add two codespell hooks, one using
--config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and
add a third one once we start supporting gdb. Not ideal because it creates
duplication, but certainly possible.
I went with the following solution: a setup.cfg file in gdb/contrib (alongside
codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport.
So, what can this new setup do for us? Let's demonstrate by simulating a typo:
...
$ echo "/* aways */" >> gdbsupport/agent.cc
...
We can check unstaged changes before committing:
...
$ pre-commit run codespell --all-files
codespell................................................................Failed
- hook id: codespell
- exit code: 65
gdbsupport/agent.cc:282: aways ==> always, away
...
Likewise, staged changes (no need for the --all-files):
...
$ git add gdbsupport/agent.cc
$ pre-commit run codespell
codespell................................................................Failed
- hook id: codespell
- exit code: 65
gdbsupport/agent.cc:282: aways ==> always, away
...
Or we can try to commit, and run into the codespell failure:
...
$ git commit -a
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell................................................................Failed
- hook id: codespell
- exit code: 65
gdbsupport/agent.cc:282: aways ==> always, away
check-include-guards.................................(no files to check)Skipped
...
which makes the commit fail.
Approved-By: Tom Tromey <tom@tromey.com>
|
