For C/C++/Fortran languages GDB prints same name variable multiple times in
case of variable shadowing and it is confusing for user to identify which
variable belongs to the current scope. So GDB now prints location information
for shadowed variables and add 'shadowed' field also in '-stack-list-locals'
and '-stack-list-variables' mi commands for super-block shadowed variable.
Suppose we have test.c file
1:int x = 3;
2: {
3: int x = 4;
4: int y = 5;
5: x = 99; /* break here */
6: }
The "-stack-list-locals" and "-stack-list-variables" mi commands at the
"break here" line gives the following output:
Before the change:
~~~
(gdb)
-stack-list-locals 0
^done,locals=[name="x",name="y",name="x"]
(gdb)
-stack-list-locals 1
^done,locals=[{name="x",value="4"},{name="y",value="5"},{name="x",value="3"}]
(gdb)
-stack-list-locals 2
^done,locals=[{name="x",type="int",value="4"},{name="y",type="int",value="5"},{name="x",type="int",value="3"}]
(gdb)
-stack-list-variables 0
^done,variables=[{name="x"},{name="y"},{name="x"}]
(gdb)
-stack-list-variables 1
^done,variables=[{name="x",value="4"},{name="y",value="5"},{name="x",value="3"}]
(gdb)
-stack-list-variables 2
^done,variables=[{name="x",type="int",value="4"},{name="y",type="int",value="5"},{name="x",type="int",value="3"}]
~~~
With this patch we obtain:
~~~
(gdb)
-stack-list-locals 0
^done,locals=[name="x",name="y",name="x"]
(gdb)
-stack-list-locals 1
^done,locals=[{name="x",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",value="5"},{name="x",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-locals 2
^done,locals=[{name="x",type="int",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",type="int",value="5"},{name="x",type="int",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-variables 0
^done,variables=[{name="x",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y"},{name="x",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-variables 1
^done,variables=[{name="x",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",value="5"},{name="x",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-variables 2
^done,variables=[{name="x",type="int",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",type="int",value="5"},{name="x",type="int",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
~~~
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
For C/C++/Fortran/Ada languages GDB prints same name variable multiple
times in case of variable shadowing and it is confusing for user to identify
which variable belongs to the current scope. So for such cases add location
info to the innermost listed variables and for super block variables add
"shadowed" annotation in the form of "<file.c:line, shadowed>".
Suppose we have
1:int x = 3;
2: {
3: int x = 4;
4: int y = 52;
5: x = 99; /* break here */
6: }
Currently:
(gdb) info locals
x = 4
y = 52
x = 3
After applying this patch, we obtain:
(gdb) info locals
x = 4 <file.c:3>
y = 52
x = 3 <file.c:1, shadowed>
The patch adds the location annotations by keeping track of inner block
and already printed variables to identify shadowing. So, GDB now prints
"<file.c:line, shadowed>" for shadowed super-block variables and
"<file.c:line>" for innermost declarations of such variables only.
The location annotations are printed for shadowed variables in case of
C/C++/Fortran/Ada languages. In Rust, it is possible to declare a
variable with the same name many times. So in this case, just the first
instance of the variable is printed. RUST language test "var_reuse.exp"
fails with rustc compiler version >= 1.73 so XFAIL is added accordingly.
Fix regex expression in the gdb.opt/inline-locals.exp test according to
this change. The test update is only required due to the existing gdb
known ticket gdb/25695 where this issue is seen with 7.5.0 version on
sles15sp6 but it is not seen anymore on the newer gcc versions e.g.
gcc-11.4.0.
The symtab()/filename() nullptr check was added specifically to avoid
the crash seen in gdb.dwarf2/missing-type-name-for-templates.exp where
template symbols may have no associated source file.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The recent ptid work came from a bug where a problem was observed due
to sign extension. That bug also suggested documenting the guaranteed
range of thread- and process-ids in the remote protocol.
This patch documents these as being 32-bit values at minimum. I also
added static asserts to ensure this is true -- note that although
'int' may be 16 bit per the C standard, I doubt gdb would build on
such a host.
I didn't specify a maximum because it is host-dependent. This is
perhaps something to change, and while I do have some work in this
area, it's quite invasive. Also, while widening the range here would
be good, it would also be incompatible in a sense, where a newer
protocol implementation may end up using values not supported by older
versions of gdb. Perhaps one idea would be to simply change these
both to int32_t and move on.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33979
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
We stopped updating ChangeLog files in 2021, and they are no longer
maintained.
If I want to see history, I use git log, so I don't use them for any purpose.
And they're in my way when I'm searching for files, grepping, or refactoring
using sed.
Move them out of the way, into a root-level directory named archive
(alternative names: legacy, deprecated, attic, stale, historical,
unmaintained).
Result of:
...
for f in $(find gdb* -name "ChangeLog*"); do
dir=$(dirname $f)
f=$(basename $f)
u=archive/$dir
mkdir -p $u
git mv $dir/$f $u/$f
done
...
Also drop ignoring ChangeLog files in some pre-commit tools.
A less impactful but also less effective change would be to move <dir>/ChangeLog
into <dir>/archive/ChangeLog.
We have some form of doxygen support, allowing to run "make doxy" in
build/gdb/doc, but in the result I didn't find any references to gdbsupport
(moved to top-level in 2019), so I'm assuming this is unmaintained for a long
time now.
Remove it.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34186
Split @acronym{AMD GPU} into @acronym{AMD} @acronym{GPU},
and @acronym{AMD ROCm} into @acronym{AMD} @acronym{ROCm}.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Hi there,
The Debian maintainer of babeltrace (Michael, in CC) is working
towards removing the version 1 package from the archive in favour of
version 2. This makes sense as version 1 is unsupported and projects
should move to version 2.
While digging through the archives I found PR buid/27142 (from
Matthias, also in Cc) which was filed 5 years ago requesting GDB to
support babeltrace v2. At the time Simon started a thread on gdb@
suggesting that we should actually remove the support for CTF (Common
Trace Format) altogether, since it's a niche feature (CTF) within a
niche feature (tracepoints) and apparently GDB itself records CTF data
in an unconventional way that might break other tools. You can see
the thread here:
https://inbox.sourceware.org/gdb/3fb1fbb6-836a-0e39-73a9-ef721630da88@polymtl.ca/
Long story short, the consensus seems to be that CTF support is ripe
to be removed, so that's what this patch does. I think I covered all
places that referred to either CTF or babeltrace; I recompiled GDB
here and things are still working as expected. I ran the tests I
touched and there are some failures, but they're unrelated to CTF and
I could reproduce them in a pristine tree as well.
I've been a bit distant from the community so I don't know whether we
have a specific procedure to remove features from GDB. I remember
that when we removed support for an architecture, we used to deprecate
it in release N and then proceed with the removal on release N+1. Not
sure if this is applicable here, but let me know.
Either way, I intend to disable support for babeltrace on Debian's GDB
soon.
WDYT?
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27142
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Running test gdb.dwarf2/fission-with-type-unit.exp with the
cc-with-gdb-index target board fails with:
(gdb) maint expand-symtabs
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3064: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error)
This is a consequence of .gdb_index not supporting skeletonless type
units in .dwo files. That is, type units in .dwo files that don't have
a corresponding skeleton (or stub) in the main file.
For context: in DWARF 4, gcc 4.x used to create skeletons for type units
in .dwo files, but subsequent versions don't. DWARF 5 doesn't have
support for type unit skeletons at all. So skeletons for type units are
mostly a historical curiosity at this point, the norm is to not have
them.
Here's what leads up to the crash. First, this is what is in the main
file's .debug_info section (the first and last CUs are dummy CUs added
by the testsuite):
Compilation Unit @ offset 0:
Length: 0x8 (32-bit)
Version: 4
Abbrev Offset: 0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
Compilation Unit @ offset 0xc:
Length: 0x15 (32-bit)
Version: 5
Unit Type: DW_UT_skeleton (4)
Abbrev Offset: 0x6
Pointer Size: 8
DWO ID: 0xf00d
<0><20>: Abbrev Number: 1 (DW_TAG_compile_unit)
<21> DW_AT_dwo_name : (strp) (offset: 0): fission-with-type-unit-dw.dwo
Compilation Unit @ offset 0x25:
Length: 0x8 (32-bit)
Version: 4
Abbrev Offset: 0xe
Pointer Size: 8
<0><30>: Abbrev Number: 1 (DW_TAG_compile_unit)
And here is what is in the fission-with-type-unit-dw.dwo file (one TU
and the CU):
Contents of the .debug_info.dwo section:
Compilation Unit @ offset 0:
Length: 0x1d (32-bit)
Version: 5
Unit Type: DW_UT_type (2)
Abbrev Offset: 0
Pointer Size: 8
Signature: 0xcafe
Type Offset: 0x19
<0><18>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><19>: Abbrev Number: 2 (DW_TAG_base_type)
<1a> DW_AT_byte_size : (sdata) 4
<1b> DW_AT_encoding : (sdata) 5 (signed)
<1c> DW_AT_name : (string) int
<1><20>: Abbrev Number: 0
Contents of the .debug_info.dwo section:
Compilation Unit @ offset 0:
Length: 0x2d (32-bit)
Version: 5
Unit Type: DW_UT_split_compile (5)
Abbrev Offset: 0
Pointer Size: 8
DWO ID: 0xf00d
<0><14>: Abbrev Number: 3 (DW_TAG_compile_unit)
<1><15>: Abbrev Number: 4 (DW_TAG_base_type)
<16> DW_AT_byte_size : (sdata) 4
<17> DW_AT_encoding : (sdata) 5 (signed)
<18> DW_AT_name : (string) int
<1><1c>: Abbrev Number: 5 (DW_TAG_variable)
<1d> DW_AT_name : (string) global_var
<28> DW_AT_type : (ref4) <0x15>, int
<2c> DW_AT_location : (exprloc) 3 byte block: 8 c 9f (DW_OP_const1u: 12; DW_OP_stack_value)
<1><30>: Abbrev Number: 0
After loading the above in GDB, here is what is in GDB's mind (contents
of dwarf2_per_bfd::all_units):
- CU at offset 0x0 of .debug_info in fission-with-type-unit -- dummy
- CU at offset 0xc of .debug_info in fission-with-type-unit
- CU at offset 0x25 of .debug_info in fission-with-type-unit -- dummy
- TU at offset 0x0 of .debug_info.dwo in fission-with-type-unit-dw.dwo
This is correct. Then, this is the generated .gdb_index:
Contents of the .gdb_index section:
Version 9
CU table:
[ 0] 0 - 0xb -- dummy
[ 1] 0xc - 0x24
[ 2] 0x25 - 0x30 -- dummy
TU table:
[ 0] 0 0x19 000000000000cafe
Address table:
Symbol table:
[ 3] global_var: 1 [static, variable]
[754] int: 1 [static, type]
Shortcut table:
Language of main: unknown: 0
Name of main: <unknown>
The TU table says that there exists a TU at offset 0. Unfortunately,
there is no way for a reader of that index to know that this TU is
really in a .dwo file, not in the main file. So when GDB loads this
index back (creating dwarf2_per_bfd::all_units from .gdb_index this
time, rather than walking the debug info), this is what is in its mind:
- CU at offset 0x0 of .debug_info in fission-with-type-unit -- dummy
- TU at offset 0x0 of .debug_info in fission-with-type-unit
- CU at offset 0xc of .debug_info in fission-with-type-unit
- CU at offset 0x25 of .debug_info in fission-with-type-unit -- dummy
GDB now incorrectly believes there's a TU at offset 0 of .debug_info in
the main file, which is wrong. When trying to expand that TU with
"maint expand-symtabs", we're not really reading the TU, so we hit the
assert checking that the signature in the TU header matches what was
given by the index.
The .debug_names format has a way to list the TUs found in the .dwo
files, called the "foreign TU list" (see section 6.1.1.2 "Structure of
the Name Index" of DWARF 5). That list only includes the signature of
the type, and there is some capability to figure out which .dwo file
contains that type unit. The .gdb_index format does not have something
like that. We could try to retrofit such a feature in the .gdb_index
format, but I think we prefer to put our efforts on the standard
.debug_names format.
To avoid producing a misleading index like shown above, I propose to
make GDB refuse to produce an index if there exists a skeletonless type
unit. This patch implements that by looking at section of all
signatured_types. If the containing section ends with .dwo, then this
is a skeletonless type unit.
As a reminder: if a unit has a skeleton, the dwarf2_per_cu section will
point at the skeleton section, in the main file. If the unit does not
have a skeleton, the dwarf2_per_cu section will point at the section in
the .dwo file. All .dwo section names end with ".dwo".
Add a "endswith" utils function to help with that.
With this patch, running the gdb.dwarf/fission-with-type-unit.exp leads
to a compilation failure:
gdb compile failed, Error while writing index for `/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit': Found skeletonless type units, unable to produce .gdb_index. Consider using .debug_names instead.
... which makes the test "untested".
Add a new test, gdb.dwarf2/gdb-index-skeletonless-tu.exp, to verify the new error path.
Change-Id: I1e2e0204c9c2b48763aa99ce63521ae4a5262b22
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
This patch originated from this mailing list discussion:
https://inbox.sourceware.org/gdb-patches/b9b5bf03c59b58e02ca27b522338c6103d5ae49f.camel@gnu.org
The user has some core files which lack an NT_FILE note. They
wondered why GDB was still unable to find the shared libraries based
on their build-id.
The reason right now is that GDB only records the build-id information
for mappings based on the entries in the NT_FILE note. With the
entries in this note we build several lookup tables; a filename to
build-id table, a soname (extracted from the file if it is a shared
library) to build-id table, and an address range to build-id table.
When a shared library is being loaded we perform a lookup using two
pieces of information; the shared library's filename, and an address
that we know is within the shared library. If either of these give a
build-id, then we can use that build-id to ensure GDB loads the
shared library that matches the core file.
If the NT_FILE note is missing then none of the lookup tables are
created, and so the shared library build-id lookup fails, meaning that
all GDB can do is look for the shared library by name on the local
file system. This often results in the wrong library version being
loaded, or the library not being found at all.
However, Linux core files also have the segment table. This table
gives address ranges. The segment table doesn't tell us what file was
mapped in, or the offset within the file that was mapped in. But if
we go back to the three lookup tables, we can use the segment table to
build the address to build-id lookup table, and that would be enough
to allow GDB to find the build-id for a shared library in most cases.
So, here's what this patch does: linux_read_core_file_mappings (in
linux-tdep.c) is updated to first parse the NT_FILE note as it
currently does. But after this we also walk the segment table (BFD
actually converts these into sections with the LOAD flag set), and if
a segment has a build-id, and doesn't correspond to an entry found in
the NT_FILE note, we create an anonymous mapping. An anonymous
mapping is just like a mapping from the NT_FILE note, but without a
filename and file offset. This mapping is passed through the callback
just like the traditional, non-anonymous, mappings.
Then in corelow.c various functions are updated in order to handle
anonymous mappings.
Back in linux-tdep.c, function linux_core_info_proc_mappings gets a
small update to handle anonymous mappings.
The corefile-buildid.exp test is updated to remove the NT_FILE notes
and rerun the tests. This should make no difference as all this test
is checking is that GDB is able to find and load the shared libraries
and executable based on their build-ids; this is something we can do
fine now without the NT_FILE note.
I have also had to update the Python core file API documentation after
this commit. Previously we claimed that CorefileMappedFile.filename
would never be empty, but this is now possible. Luckily, this API has
not yet been in a released version of GDB, so this minor tweak isn't
going to break any existing user code. I did consider having
CorefileMappedFile.filename be a non-empty string or None, but I
couldn't see much value in this, so I just documented that the string
could be empty, and what this means.
The py-corefile.exp test needed a minor update to filter out anonymous
mappings (those without a filename), this matches the behaviour of the
builtin 'info proc mappings' command.
Reviewed-By: Keith Seitz <keiths@redhat.com>
This provides the following improvements to the GDB user manual, where
we document "set non-stop" and "maint set target-non-stop":
- In the "set non-stop" section:
- Names "all-stop" earlier.
- Says what mode is the default.
- Removes old pagination suggestion.
- Clarifies text.
- In the "maint set target-non-stop" section:
- Clarifies "maint set target-non-stop" vs "set non-stop" .
- Corrects the "auto" description to current reality.
- Gives a couple examples of what "GDB targets" are.
- Documents the "all-stop on top of non-stop" term.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Ia720e5091dd57321fb19e6a306678b834ab822df
commit-id:dbc519ee
This patch adds core file support to GDB's DAP interface.
Core files are supported as a GDB specific argument to 'attach', the
new argument is 'coreFile', the name of the core file to debug.
I think handling core files via attach makes the most sense; attach is
for connecting to existing processes, but these targets are (usually)
stopped as soon as GDB attaches, and that's what a core file looks
like, a target that was running, but is now stopped. It just happens
that core file targets are special in that the target cannot be
resumed again, nor can the user modify the program state (e.g. write
to memory or registers).
Prior to starting this work I took a look at what lldb does. The
documentation is not super clear, but this page seems to indicate that
lldb might also use the 'coreFile' argument to 'attach':
https://lldb.llvm.org/use/lldbdap.html#configuration-settings-reference
Like I said, it's not very clear, but search for "coreFile" and you'll
see it mentioned, just once, under the "attach" header. In order to
be compatible with lldb I used the same argument name with the same
capitalisation.
The new argument is added to the documentation and mentioned in NEWS.
I had to make some changes to testsuite/lib/dap-support.exp to support
this new feature. There's a new dap_corefile proc to handle setting
up the initial connection. This seemed cleaner that overloading
dap_attach, even though under the hood it is still an 'attach' request
that gets sent.
The new test tries to write to memory and registers with the core file
target in place, neither of these requests succeed, which is what we
want, but the exceptions are logged into the dap log file. The
dap_shutdown proc calls dap_check_log_file to check the log for
exceptions, and these two exceptions are spotted and trigger a FAIL.
To avoid this I've added a new "expected_exception_count" argument
for dap_shutdown. Now we check that we see the expected number of
exceptions. We don't check for the specific exception types right
now, but as the test is already checking that the expected requests
fail, I think we're OK.
Approved-By: Tom Tromey <tom@tromey.com>
Add a new Python event registry, events.corefile_changed. This event
is emitted each time the corefile within an inferior changes.
The event object has a single 'inferior' attribute which is the
gdb.Inferior object for which the core file changed. The user can
then inspect Inferior.corefile to see details about the new core file,
or this will be None if the core file was removed from the inferior.
I've updated the existing test to cover this new event.
The new test covers both the corefile_changed event, but also monitors
the exited event. This ties into the work done in the previous
commit where we use whether the inferior has exited or not as a guard
for whether core_target::exit_core_file_inferior should be called.
Unloading a core file should result in a single corefile_changed event
and a single exited event.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I had difficulty finding the 'dir' command in the manual (I forgot its
name, amazingly enough), so I've installed this to improve its indexing.
* gdb/doc/gdb.texinfo (Source Path): Improve indexing.
This updates the .debug_names documentation to explain some DWARF
issues that we've handled in gdb.
This list still isn't exhaustive. I think there are some situations
where gdb may examine a declaration (which DWARF says not to do), but
I didn't document this as I don't recall the details.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Acked-By: Tom de Vries <tdevries@suse.de>
There are cases when a user might wish to skip every file of a
particular type within a directory, and all its sub-directories.
Currently, you'll need to account for each sub-directory in your skip
patterns, so given:
/include/a.h
/include/xxx/b.h
/include/yyy/zzz/c.h
To skip all of these requires:
skip -gfile /include/*.h
skip -gfile /include/*/*.h
skip -gfile /include/*/*/*.h
Which isn't really that much, but if another layer of sub-directory is
added then you'll need to add yet another skip pattern.
This commit introduces '**' which is modelled after the bash globstar
feature. The '**' matches 0 or more directories. You can now write:
skip -gfile /include/**/*.h
And this will skip all of the files listed above in a single command.
There was an earlier attempt to solve this problem with commit:
commit 02646a4c56
Date: Sun Dec 29 14:57:44 2024 -0800
skip -gfile: call fnmatch without FNM_FILE_NAME
But I reverted this in commit:
commit f08ffbbf26
Date: Mon Feb 9 16:31:23 2026 +0000
Revert "skip -gfile: call fnmatch without FNM_FILE_NAME"
Due to bug PR gdb/33872. The initial commit also changed GDB in a
non-backward compatible way, that is 'skip -gfile /include/*.h' would
now match all .h files in every sub-directory of /include/, which
might not be what the user wants. The approach taken in this commit
avoids changing this behaviour and allows the user to better select
what they want to match.
My initial implementation can be found here:
https://inbox.sourceware.org/gdb-patches/cover.1770819471.git.aburgess@redhat.com
This worked by splitting both the filename and the glob on every '/'
and then using a recursive algorithm to match each part of the file
name. This initial approach only split on '/' which means there would
have been some regressions on DOS based file systems where '\' can be
used as a directory separator, though this would probably have been
easy enough to fix.
However, it was pointed out that the splitting and matching was rather
inefficient, and it might be better to convert the glob into a regexp
and use that for matching. I figured; how hard can that be, which is
how this version of the patch came to be.
Turns out it's not that simple. I'm not going to go though all the
details here, but the basic idea is that, when the user creates a glob
skip GDB calls glob_to_regexp to convert the glob to a regexp, which
is then compiled and stored in the skiplist_entry. The regexp can
then be used as you'd expect to check for matches.
The matching is now done in a global function do_skip_gfile_p, which
makes it easier to write unit tests. The
skiplist_entry::do_skip_gfile_p just calls the global function.
I've retained the initial file basename check, which still uses
fnmatch, as this is likely quicker than performing the regexp match,
at least, I hope so, I've not tried to benchmark anything.
Converting a glob to a regexp is mostly straight forward, except for
bracket expressions, we dont want these to match against directory
separators, so we need to filter the directory separators out, this
retains compatibility with the fnmatch FNM_PATHNAME flag. It is this
filtering that is the cause of most of the pain. The details for all
of this can be found in glob_bracket_expr::parse.
We also need to take care to handle case insensitive file systems.
This is mostly just adding REG_ICASE to the regexp flags, however,
there are some issues with, you guessed it, bracket expressions. If
we have a character range that spans out of the upper case letter set,
for example [W-_], then, at least for glibc, when REG_ICASE is set
this ends up being treated like [w-_]. This is unfortunate because
'w' is after '_' so the range is now invalid. To resolve this we end
up splitting the range into two giving: [W-Z[-_], now when glibc
adjusts to lower case, we end up matching with [w-z[-_].
For DOS like file systems, the created regexp adds a pattern that
matches both '/' and '\' whenever either of these is seen in the glob.
But there's also some additional work needed for, you guessed it,
bracket expressions; we need to ensure '\' is removed from any ranges.
One final issue with, you guessed it, bracket expressions, is
character classes, e.g. [:alpha:]. Many classes are fine, but some,
like [:punct:] include '/' and '\'. For now I just raise an error if
the user tries to use a class that includes a directory separator.
This is a change in behaviour, but hopefully isn't going to impact too
many people. The only fix I can currently see for this would be to
expand the problematic character classes into their component
characters, and then remove the directory separators. But I haven't
tried to do that just yet.
There are documentation updates and tests for the new feature. All
existing behaviour should remain unchanged. On the testing side I've
added both some full DejaGNU tests and some self tests. The self
tests are focused on just the core glob matching function, but the
full DejaGNU tests ensure that the whole mechanism, from skip
creation to its final usage, is also tested.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33872
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
This commit adds a new property - ranges - to gdb.Block object. It holds
a tuple of ranges for that block. Each range is a tuple of (start, end)
address. For contiguous blocks it contains only one range.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Extend the Architecture.disassemble API to allow the user to request
styled disassembler output via a new styling argument. A user can now
write:
insn = arch.disassemble(address, styling = True)
The instruction strings returned within INSN will contain ANSI escape
sequences so long as 'set style enabled on' is in effect. This means
that the user's personal settings (disabling styling) will override a
GDB extension that requests styled disassembler output. I think this
makes sense.
The default for the styling argument is False, this maintains the
current unstyled output as default.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
A note about the C++ demangler in the Rust documentation hasn't been
accurate for a while. Also, it probably isn't clear to users how this
related to the next bit of text in the same bullet point. This patch
removes the obsolete comment.
Approved-By: Eli Zaretskii <eliz@gnu.org>
The last user of psymtabs has been changed not to use them, remove them.
Update the tests minimally to avoid introducing failures (mostly due to
tests using the removed maintenance commands). There are still a lot of
references to partial symtabs in the comments or test names. There are
probably some tests that are just not relevant anymore. It would be quite
difficult to do this job all at once, we can clean this up little by
little.
Update the docs to remove references to partial symbols/symtabs.
Mention the removal of the maintenance commands in NEWS.
Change-Id: I58ae48c30e0303bcaa48298146d69fb8f059cb32
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Add some debug statements, to be able to visualize what is happening
when loading CTF debug info. Add a new "set debug ctf" command, with
the usual logging macros.
Here's an example of the result, when reading the binary from test
gdb.ctf/cruss-tu-cyclic:
[ctf] elfctf_build_psymtabs: start: building psymtabs for /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic
[ctf] scan_partial_symbols: start: fname='.ctf'
[ctf] scan_partial_symbols: is parent, using fname='/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic'
[ctf] ctf_psymtab_type_cb: adding type tid=0x1 kind=INTEGER name='int'
[ctf] ctf_psymtab_type_cb: adding type tid=0x2 kind=INTEGER name='long int'
[ctf] ctf_psymtab_type_cb: adding type tid=0x3 kind=FORWARD name='B'
[ctf] ctf_psymtab_type_cb: adding type tid=0x5 kind=FORWARD name='A'
[ctf] ctf_psymtab_type_cb: adding type tid=0x8 kind=STRUCT name='C'
[ctf] ctf_psymtab_add_stt_entries: adding function psym 'main' tid=0x7 kind=FUNCTION
[ctf] scan_partial_symbols: end: fname='.ctf'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-1.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='B'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000002 kind=STRUCT name='A'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-1.c'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-2.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='A'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-2.c'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-3.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='A'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-3.c'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-4.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='A'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000002 kind=STRUCT name='B'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-4.c'
[ctf] elfctf_build_psymtabs: end: building psymtabs for /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic
Change-Id: If3800d14dd965ccefa67a24ef5c4481aef70ffa4
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Creating a Python gdb.FinishBreakpoint for an inline frame doesn't
work.
If we look at the 'finish' command, in the finish_command
function (infcmd.c) then we see that GDB handles inline frames very
different to non-inline frames.
For non-inline frames GDB creates a temporary breakpoint and then
resumes the inferior until the breakpoint is hit.
But for inline frames, GDB steps forward until we have left the inline
frame.
When it comes to gdb.FinishBreakpoint we only have the "create a
temporary breakpoint" mechanism; that is, after all, what the
FinishBreakpoint is, it's a temporary breakpoint placed at the
return address in the caller.
Currently, when a FinishBreakpoint is created within an inline frame,
GDB ends up creating the breakpoint at the current $pc. As a result
the breakpoint will not be hit before the current function
exits (unless there's a loop going on, but that's not the point).
We could imagine what a solution to this problem would look like, GDB
would need to figure out the set of addresses for all possible exit
points from the inline function, and place a breakpoint at each of
these locations. I don't propose doing that in this commit.
Instead, I plan to update the docs to note that creating a
FinishBreakpoint within an inline frame is not allowed, and I will
catch this case within bpfinishpy_init (python/py-finishbreakpoint.c)
and throw an error.
Though the error is new, all I'm doing is raising an error for a case
that never worked.
There's a new test to cover this case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18339
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
The `$_` convenience var, as set by the "info breakpoints" and
"info line" commands, has the type builtin_data_ptr (i.e. `void *`).
However, both of the aforementioned commands deal with code addresses.
Hence, it makes more sense to use builtin_func_ptr (i.e.
`void (*)()`).
With this change:
(gdb) b main
Breakpoint 2 at 0x402547: file test.cpp, line 20.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000402547 in main(int, char**) at test.cpp:20
(gdb) p $_
$2 = (void (*)(void)) 0x402547 <main(int, char**)+39>
(gdb) ptype $_
type = void (*)(void)
(gdb) ptype &main
type = int (*)(int, char **)
(gdb) info line 22
Line 22 of "test.cpp" starts at address 0x40256d <main(int, char**)+77> and ends at 0x4025bd <main(int, char**)+157>.
(gdb) p $_
$3 = (void (*)(void)) 0x40256d <main(int, char**)+77>
(gdb) ptype $_
type = void (*)(void)
(gdb)
This also matches the type of PC:
(gdb) ptype $pc
type = void (*)(void)
Also add test cases to check that "info breakpoints" and "info line"
set the `$_` var.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that forward-search and reverse-search commands set the $_
convenience variable. This is mentioned in the help menu (see below)
but is not stated in the documentation. Add related text to the doc.
(gdb) help search
forward-search, fo, search
Search for regular expression (see regex(3)) from last line listed.
The matching line number is also stored as the value of "$_".
(gdb) help rev
reverse-search, rev
Search backward for regular expression (see regex(3)) from last line listed.
The matching line number is also stored as the value of "$_".
(gdb)
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds a new method gdb.Symtab.source_lines. This method
can be used to read the lines from a symtab's source file. This is
similar to GDB's internal source_cache::get_source_lines function.
Currently using the Python API, if a user wants to display source
lines then they need to use Symtab.fullname() to get the source file
name, then open this file and parse out the lines themselves.
This isn't too much effort, but the problem is that these lines will
not be styled. The user could style the source content themselves,
but will this be styled exactly as GDB would style it?
The new Symtab.source_lines() method returns source lines with styling
included (as ANSI terminal escape sequences), assuming of course, that
styling is currently enabled.
Of course, in some cases, a user of the Python API might want source
code without styling. That's supported too, the new method has an
'unstyled' argument. If this is True then the output is forced to be
unstyled. The argument is named 'unstyled' rather than 'styled'
because the API call cannot force styling on. If 'set style enabled
off' is in effect then making the API call will never return styled
source lines.
The new API call allows for a range of lines to be requested if
desired.
As part of this commit I've updated the host_string_to_python_string
utility function to take a std::string_view.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
This commit introduces a new Python event, selected_context. This
event is attached to the user_selected_context_changed observer, which
triggers when the user changes the currently selected inferior,
thread, or frame.
Adding this event allows a Python extension to update in response to
user driven changes without having to poll the state from a
before_prompt hook, which is what I currently do to achieve the same
results.
I did consider splitting the user_selected_context_changed observer
into 3 separate Python events, inferior_changed, thread_changed, and
frame_changed, but I couldn't see any significant advantage to doing
this, so in the end I went with just a single event, and the event
object contains the inferior, thread, and frame.
Additionally, the user isn't informed about which aspect of the
context changed. That is, every event carries the inferior, thread,
and frame, so an event triggered when switching frames will looks
identical to an event triggered when switching inferiors. If the user
wants to know what changed then they will have to track the current
state themselves, and then compare the event state to the stored
current state. In many cases though I suspect that just being told
something changed, and then updating everything will be sufficient,
which is why I've not bothered trying to inform the user what changed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24482
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds proper option completion for the 'skip' command, the
skip_command function (skip.c) has been rewritten as a consequence.
All the existing functionality should have been retained, though some
of the error messages have changed as we now get the errors generated
by the option parsing code rather than the ones from skip_command.
I've added more skip tests to cover error cases that were not
previously tested. And I've added a test for 'skip FUNCTION_NAME'
which was previously untested.
Consider the -gfile option for the skip command. Previously the skip
command was hard coded to accept -gfile or -gfi, these were aliases.
But you couldn't pass -gfil. Now we've switched to the general option
handling routine the only option is -gfile, but our option handling
code will accept any partial option name that uniquely identifies an
option, so -g, -gf, -gfi, -gfil, and -gfile are all valid, and all
aliases of each other. The same is true for all the options that skip
accepts.
Because of this I've gone through and removed all references to the
short form option names that I can find. Now that tab-completion
works, there's no need to advertise specific short form names, and as
discussed above, all unique short forms are still valid.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Skips are created using 'skip', 'skip file', or 'skip function', then
managed with 'skip enable', 'skip disable', and 'skip delete'.
This is slightly different to other things, for example breakpoint,
where we have a command to create the thing, e.g. 'break', but then we
have 'enable breakpoints', 'disable breakpoints', and 'delete
breakpoints' to manage the thing.
If you tab-complete on any of the 'enable', 'disable', or 'delete'
prefix commands you'll find these are used to manage a whole bunch of
different types of thing.
When I started playing with skips, my instinct, given the existing
patterns in GDB, was to try 'enable skip', 'disable skip', and 'delete
skip', and it surprised me that these didn't work.
But notice we do have 'info skip' rather than 'skip info'. So the
"normal" pattern does apply in some cases.
In this commit I propose that we create aliases 'enable skip',
'disable skip', and 'delete skip' which just alias back to the
existing commands. We cannot delete the existing commands for fear of
breaking existing user scripts.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Add a new "environ" subcommand to "info proc" to print the initial
environment variables of a given process. The environment variables
are printed line-by-line and are indented by two spaces, so that they
can be distinguished from the rest of the output in "info proc all".
Note that the information printed by this new command is not
necessarily the same as `show environment`, which lists the
environment variables that will be given to the program next time it
is started under GDB. The two information may differ in particular
when GDB attached to a running program that was started in an
environment different than GDB's.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR cli/23664 points out that it would sometimes be convenient to
immediately save the current history to a file. This patch implements
this feature.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23664
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR cli/17997 points out that it would sometimes be convenient to save
the current "skip"s to a file. This patch implements this feature.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17997
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR cli/19395 points out that it would sometimes be convenient to save
one's user-defined commands to a file. This patch implements this
feature.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19395
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
The "info line" command can be used with or without arguments.
About using it without arguments, the documentation [1] says the following:
...
info line
With no locspec, information about the current source line is printed.
...
After info line, using info line again without specifying a location will
display information about the next source line.
...
That does not describe the fact that the command may also show the last line
listed:
...
(gdb) info line
No line number information available.
(gdb) list main
20 #include "interps.h"
21 #include "run-on-main-thread.h"
22
23 int
24 main (int argc, char **argv)
25 {
26 /* The first call to is_main_thread () should be from the main thread.
27 If this is the first call, then that requirement is fulfilled here.
28 If this is not the first call, then this verifies that the first call
29 fulfilled that requirement. */
(gdb) info line
Line 29 of "gdb/gdb.c" is at address 0x419684 <main(int, char**)+30>
but contains no code.
(gdb)
...
Update the documentation to list this additional functionality.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33783
[1] https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Machine-Code.html#index-info-line
Building GDB documentation in the info format requires makeinfo 5.0 [1].
Bail out when trying to use an older makeinfo version.
I tested this by requiring 7.0 in two setups that have respectively makeinfo
7.1 and 6.5.
In the 7.1 case I got (make output):
...
makeinfo-wrapper.sh 7 0 makeinfo ... -o gdb.info gdb/doc/gdb.texinfo
makeinfo-wrapper.sh 7 0 makeinfo ... -o annotate.info gdb/doc/annotate.texinfo
rluser.texi:2: warning: @setfilename after the first element
...
and in the 6.5 case I got instead:
...
makeinfo-wrapper.sh 7 0 makeinfo ... -o gdb.info gdb/doc/gdb.texinfo
makeinfo-wrapper.sh 7 0 makeinfo ... -o annotate.info gdb/doc/annotate.texinfo
makeinfo is too old, have 6.5, require 7.0. Info documentation will not be build.
makeinfo is too old, have 6.5, require 7.0. Info documentation will not be build.
...
Checked new file gdb/doc/makeinfo-wrapper.sh with shellcheck.
Changes in v2:
- handle version line 'texi2any (GNU texinfo) 7.2.90+nc'
Changes in v3:
- handle version line 'texi2any (GNU texinfo) 5.0+dev'
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33870
Add some debug prints throughout the ifunc resolution code, to be able
to better understand what GDB does. Add the new "set debug gnu-ifunc"
knob to control it.
Add the debug_prefixed_printf_cond_func macro to implement
gnu_ifunc_debug_printf_func, that takes an explicit function name. This
is needed to avoid showing "operator()" as the function name in the
debug message.
Here is a sample session with the new debug output enabled.
(gdb) b the_function
[gnu-ifunc] elf_gnu_ifunc_resolve_name: resolving name "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolve_by_cache: resolving "the_function" by cache
[gnu-ifunc] elf_gnu_ifunc_resolve_by_cache: cache miss for "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: resolving "the_function" by GOT
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: GOT entry "the_function@got.plt" points to 0x7ffff7fb7036
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fb7036
[gnu-ifunc] elf_gnu_ifunc_record_cache: minimal symbol "the_function@plt" at 0x7ffff7fb7030 does not match addr 0x7ffff7fb7036, not caching
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: GOT entry "the_function@got.plt" points to 0x7ffff7fb2036
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fb2036
[gnu-ifunc] elf_gnu_ifunc_record_cache: minimal symbol "the_function@plt" at 0x7ffff7fb2030 does not match addr 0x7ffff7fb2036, not caching
[gnu-ifunc] elf_gnu_ifunc_resolve_by_got: failed to resolve "the_function" by GOT
[gnu-ifunc] elf_gnu_ifunc_resolve_name: failed to resolve name "the_function"
Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7fa80e9
(gdb) c
Continuing.
[gnu-ifunc] elf_gnu_ifunc_resolver_stop: stop on resolver for "the_function"
[gnu-ifunc] elf_gnu_ifunc_resolver_stop: created resolver return breakpoint at 0x7ffff7fd7186
[gnu-ifunc] elf_gnu_ifunc_resolver_return_stop: stop on resolver return
[gnu-ifunc] elf_gnu_ifunc_resolver_return_stop: resolver for "the_function" returned resolved address=0x7ffff7fad0e9, resolved pc=0x7ffff7fad0e9
[gnu-ifunc] elf_gnu_ifunc_record_cache: recording cache entry for "the_function" at 0x7ffff7fad0e9
[gnu-ifunc] elf_gnu_ifunc_record_cache: cached "the_function" -> 0x7ffff7fad0e9 in objfile /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/ifunc-resolver/libimpl.so
Breakpoint 2, the_function_impl_0 (caller_id=1) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/ifunc-resolver-libimpl.c:25
25 the_function_last_caller_id = caller_id; /* break-in-impl */
Change-Id: I64f667e3457feaedfe9bb530de58faaf22545fa5
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-by: Kevin Buettner <kevinb@redhat.com>
A user pointed out a crash when opaque-type-resolution is "off".
The bug was that type resolution was happening anyway, so this patch
disables it entirely when the feature is disabled.
There were no other tests for this feature in the tree.
I've included a minor documentation change. This feature does
sometimes work even after symbols have been read.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33857
Reviewed-By: Keith Seitz <keiths@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
A co-worker reported that certain symbols weren't appearing in the DAP
'scopes' response. In particular, symbols with non-ASCII names didn't
appear; though further research showed that this was in fact a result
of the variable in question actually being a constant.
Unfortunately Ada still requires the user to set the Ada source
character set in order to properly display symbol names. For DAP, it
seemed to make sense to allow this as a launch parameter. This patch
implements this.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
This updates the copyright headers to include 2026. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
When starting GDB it is possible to set an inferior argument that
contains a newline, for example:
shell> gdb --args my.app "abc
> def"
...
(gdb) show args
Argument list to give program being debugged when it is started is "abc'
'def".
However, once GDB is started, the only way to install an argument
containing a newline is to use the Python API.
This commit changes that.
After this commit 'set args' as well as 'run', 'start', and 'starti',
will now accept multi-line inferior arguments, e.g.:
(gdb) set args "abc
> def"
(gdb) show args
Argument list to give program being debugged when it is started is ""abc
def"".
And also:
(gdb) run "abc
> def"
... etc ...
Once GDB has presented the secondary prompt to gather the remaining
inferior arguments then it is possible for the user to quit argument
entry by sending SIGINT (usually, Ctrl-c), or sending EOF (usually,
Ctrl-d). For the 'set args' case this will abort the argument change,
leaving the arguments as they were previously. For the run style
commands, this aborts the run command completely, the inferior is not
changed, and the partially collected arguments are not installed.
On Unix hosts, arguments can be wrapped with either single or double
quotes, while on MS-Windows hosts, arguments can only be wrapped with
double quotes. This gives the expected behaviour when native
debugging, but isn't entirely accurate. If a user is cross debugging
between Unix and MS-Windows then the host machine will determine which
set of quotes is valid, which will then be incorrect for the actual
target machine. This should probably be fixed in the future, but
isn't something I plan to fix immediately. If this patch is accepted,
then I can create a bug to track this issue.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Replace "the the" with "the".
Result of running:
...
$ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the /the /'
$ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the$/the/'
...
The only change I have doubts about, is this comment in queue_comp_unit in
gdb/dwarf2/read.c:
...
... . If the CU gets enqueued by this function but its DIEs
- are not yet loaded, the the caller must load the CU's DIEs to ensure the
+ are not yet loaded, the caller must load the CU's DIEs to ensure the
invariant is respected.
...
where I think "the the" -> "then the" also make sense. But for now, I'm going
with "the the" -> "the".
Tested by building gdb on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In commit:
commit 255a9c4270
Date: Fri Dec 5 11:33:29 2025 +0000
gdb: new setting to disable progress bars
I incorrectly used @value{on} and @value{off} to reference the on/off
settings of a new flag. This caused the following warnings when
building the docs:
gdb.texinfo:51356: warning: undefined flag: off
gdb.texinfo:51357: warning: undefined flag: on
Looking through the docs there seems to be a split, in some cases we
use @code and in others we use @samp. I'm not sure @code is correct,
so I've switched to use @samp. The warnings are gone after this
patch.
Two commits ago, in the commit titled:
gdb: make get_chars_per_line return an unsigned value
A bodge was added in cli-out.c so that progress bars (as seen when
debuginfod downloads a file) would be disabled when the output
terminal had unlimited width.
The hack was added because this previous commit fixed a bug such that
progress bars could now be displayed in very wide, or even on
unlimited width output terminals. By fixing this bug, progress bars
were now being displayed when running the testsuite, as the testsuite
sets the output terminal to unlimited width.
To avoid breaking the tests, this previous commit added a bodge such
that on unlimited width output terminals, progress bars would always
be disabled. This got the tests passing again, but isn't an ideal
solution.
This commit cleans things up. We now have a new setting:
set progress-bars enabled on|off
show progress-bars enabled
This setting allows progress bars to be turned off. The tests are
then updated to explicitly turn off progress bars. The bodge from the
earlier commit is then removed.
Now, progress bars should display correctly on any width of output
terminal over 50 characters, the minimum required. And the debuginfod
tests should all pass as they turn off progress bars.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
