GDB has two approaches to generating the target descriptions found in
gdb/features/, the whole description approach, where the XML file
contains a complete target description which is then used to generate
a single C file that builds that target description. Or, the split
feature approach, where the XML files contain a single target feature,
each feature results in a single C file to create that one feature,
and then a manually written C file is used to build a complete target
description from individual features.
There's a Makefile, gdb/features/Makefile, which is responsible for
managing the regeneration of the C files from the XML files.
However, some of the logic that selects between the whole description
approach, or the split feature approach, is actually hard-coded into
GDB, inside target-descriptions.c:maint_print_c_tdesc_cmd we check the
path to the incoming XML file and use this to choose which type of C
file we should generate.
This commit removes this hard coding from GDB, and makes the Makefile
entirely responsible for choosing the approach. This makes sense as
the Makefile already has the XML files partitioned based on which
approach they should use.
In order to allow this change the 'maint print c-tdesc' command is
given a new command option '-single-feature', which tells GDB which
type of C file should be created. The makefile now supplies this flag
to GDB.
This did reveal a bug in features/Makefile, the rx.xml file was in the
wrong list, this didn't matter previously as the actual choice of
which approach to use was done in GDB. Now the Makefile decides, so
placing each XML file in the correct list is critical.
Tested this by doing 'make GDB=/path/to/gdb clean-cfiles cfiles' to
regenerate all the C files from their XML source. There are no
changes after this commit.
gdb/ChangeLog:
* features/Makefile (XMLTOC): Add rx.xml.
(FEATURE_XMLFILES): Remove rx.xml.
(FEATURE_CFILES rule): Pass '-single-feature' flag.
* features/rx.c: Regenerate.
* features/rx.xml: Wrap in `target` tags, and reindent.
* target-descriptions.c (struct maint_print_c_tdesc_options): New
structure.
(maint_print_c_tdesc_opt_def): New typedef.
(maint_print_c_tdesc_opt_defs): New static global.
(make_maint_print_c_tdesc_options_def_group): New function.
(maint_print_c_tdesc_cmd): Make use of command line flags, only
print single feature C file for target descriptions containing a
single feature.
(maint_print_c_tdesc_cmd_completer): New function.
(_initialize_target_descriptions): Update call to register command
completer, and include command line flag in help text.
gdb/doc/ChangeLog:
* gdb.texinfo (Maintenance Commands): Update description of 'maint
print c-tdesc'.
This commit effectively changes the default location of the .gdbinit
file, while maintaining backward compatibility.
For non Apple hosts the .gdbinit file will now be looked for in the
following locations:
$XDG_CONFIG_HOME/gdb/gdbinit
$HOME/.config/gdb/gdbinit
$HOME/.gdbinit
On Apple hosts the search order is instead:
$HOME/Library/Preferences/gdb/gdbinit
$HOME/.gdbinit
I've performed an extensive rewrite of the documentation, moving all
information about initialization files and where to find them into a
new @node, text from other areas has been moved into this one
location, and other areas cross-reference to this new @node as much as
possible.
gdb/ChangeLog:
* NEWS: Mention changes to config file search path.
* main.c
gdb/doc/ChangeLog:
* gdb.texinfo (Mode Options): Descriptions of initialization files
has been moved to 'Initialization Files'.
(Startup): Likewise.
(Initialization Files): New node.
(gdb man): Update to mention alternative file paths.
(gdbinit man): Likewise.
The previous patch made it possible to define a condition if it's
valid at some locations. If the condition is invalid at all of the
locations, it's rejected. However, there may be cases where the user
knows the condition *will* be valid at a location in the future,
e.g. due to a shared library load.
To make it possible that such condition can be defined, this patch
adds an optional '-force' flag to the 'condition' command, and,
respectively, a '-force-condition' flag to the 'break'command. When
the force flag is passed, the condition is not rejected even when it
is invalid for all the current locations (note that all the locations
would be internally disabled in this case).
For instance:
(gdb) break test.c:5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 foo == 42
No symbol "foo" in current context.
Defining the condition was not possible because 'foo' is not
available. The user can override this behavior with the '-force'
flag:
(gdb) cond -force 1 foo == 42
warning: failed to validate condition at location 1.1, disabling:
No symbol "foo" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if foo == 42
1.1 N 0x0000000000001155 in main at test.c:5
Now the condition is accepted, but the location is automatically
disabled. If a future location has a context in which 'foo' is
available, that location would be enabled.
For the 'break' command, -force-condition has the same result:
(gdb) break test.c:5 -force-condition if foo == 42
warning: failed to validate condition at location 0x1169, disabling:
No symbol "foo" in current context.
Breakpoint 1 at 0x1169: file test.c, line 5.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (set_breakpoint_condition): Add a new bool parameter.
* breakpoint.c: Update the help text of the 'condition' and 'break'
commands.
(set_breakpoint_condition): Take a new bool parameter
to control whether condition definition should be forced even when
the condition expression is invalid in all of the current locations.
(condition_command): Update the call to 'set_breakpoint_condition'.
(find_condition_and_thread): Take the "-force-condition" flag into
account.
* linespec.c (linespec_keywords): Add "-force-condition" as an
element.
(FORCE_KEYWORD_INDEX): New #define.
(linespec_lexer_lex_keyword): Update to consider "-force-condition"
as a keyword.
* ada-lang.c (create_ada_exception_catchpoint): Ditto.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_condition_x): Ditto.
* python/py-breakpoint.c (bppy_set_condition): Ditto.
* NEWS: Mention the changes to the 'break' and 'condition' commands.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Expand to test forcing
the condition.
* gdb.linespec/cpcompletion.exp: Update to consider the
'-force-condition' keyword.
* gdb.linespec/explicit.exp: Ditto.
* lib/completion-support.exp: Ditto.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document the '-force-condition' flag
of the 'break'command.
* gdb.texinfo (Conditions): Document the '-force' flag of the
'condition' command.
Currently, for a conditional breakpoint, GDB checks if the condition
can be evaluated in the context of the first symtab and line (SAL).
In case of an error, defining the conditional breakpoint is aborted.
This prevents having a conditional breakpoint whose condition may
actually be meaningful for some of the location contexts. This patch
makes it possible to define conditional BPs by checking all location
contexts. If the condition is meaningful for even one context, the
breakpoint is defined. The locations for which the condition gives
errors are disabled.
The bp_location struct is introduced a new field, 'disabled_by_cond'.
This field denotes whether the location is disabled automatically
because the condition was non-evaluatable. Disabled-by-cond locations
cannot be enabled by the user. But locations that are not
disabled-by-cond can be enabled/disabled by the user manually as
before.
For a concrete example, consider 3 contexts of a function 'func'.
class Base
{
public:
int b = 20;
void func () {}
};
class A : public Base
{
public:
int a = 10;
void func () {}
};
class C : public Base
{
public:
int c = 30;
void func () {}
};
Note that
* the variable 'a' is defined only in the context of A::func.
* the variable 'c' is defined only in the context of C::func.
* the variable 'b' is defined in all the three contexts.
With the existing GDB, it's not possible to define a conditional
breakpoint at 'func' if the condition refers to 'a' or 'c':
(gdb) break func if a == 10
No symbol "a" in current context.
(gdb) break func if c == 30
No symbol "c" in current context.
(gdb) info breakpoints
No breakpoints or watchpoints.
With this patch, it becomes possible:
(gdb) break func if a == 10
warning: failed to validate condition at location 1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 3, disabling:
No symbol "a" in current context.
Breakpoint 1 at 0x11b6: func. (3 locations)
(gdb) break func if c == 30
Note: breakpoint 1 also set at pc 0x11ce.
Note: breakpoint 1 also set at pc 0x11c2.
Note: breakpoint 1 also set at pc 0x11b6.
warning: failed to validate condition at location 1, disabling:
No symbol "c" in current context.
warning: failed to validate condition at location 2, disabling:
No symbol "c" in current context.
Breakpoint 2 at 0x11b6: func. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
2 breakpoint keep y <MULTIPLE>
stop only if c == 30
2.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
2.2 N* 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
2.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
Here, uppercase 'N' denotes that the location is disabled because of
the invalid condition, as mentioned with a footnote in the legend of
the table. Locations that are disabled by the user are still denoted
with lowercase 'n'. Executing the code hits the breakpoints 1.2 and
2.3 as expected.
Defining a condition on an unconditional breakpoint gives the same
behavior above:
(gdb) break func
Breakpoint 1 at 0x11b6: func. (3 locations)
(gdb) cond 1 a == 10
warning: failed to validate condition at location 1.1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 1.3, disabling:
No symbol "a" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
Locations that are disabled because of a condition cannot be enabled
by the user:
...
(gdb) enable 1.1
Breakpoint 1's condition is invalid at location 1, cannot enable.
Resetting the condition enables the locations back:
...
(gdb) cond 1
Breakpoint 1's condition is now valid at location 1, enabling.
Breakpoint 1's condition is now valid at location 3, enabling.
Breakpoint 1 now unconditional.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 y 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
If a location is disabled by the user, a condition can still be defined
but the location will remain disabled even if the condition is meaningful
for the disabled location:
...
(gdb) disable 1.2
(gdb) cond 1 a == 10
warning: failed to validate condition at location 1.1, disabling:
No symbol "a" in current context.
warning: failed to validate condition at location 1.3, disabling:
No symbol "a" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if a == 10
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 n 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 N* 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
The condition of a breakpoint can be changed. Locations'
enable/disable states are updated accordingly.
...
(gdb) cond 1 c == 30
warning: failed to validate condition at location 1.1, disabling:
No symbol "c" in current context.
Breakpoint 1's condition is now valid at location 3, enabling.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if c == 30
1.1 N* 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 N* 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
(*): Breakpoint condition is invalid at this location.
(gdb) cond 1 b == 20
Breakpoint 1's condition is now valid at location 1, enabling.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if b == 20
1.1 y 0x00000000000011b6 in Base::func() at condbreak-multi-context.cc:23
1.2 n 0x00000000000011c2 in A::func() at condbreak-multi-context.cc:31
1.3 y 0x00000000000011ce in C::func() at condbreak-multi-context.cc:39
# Note that location 1.2 was disabled by the user previously.
If the condition expression is bad for all the locations, it will be
rejected.
(gdb) cond 1 garbage
No symbol "garbage" in current context.
For conditions that are invalid or valid for all the locations of a
breakpoint, the existing behavior is preserved.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (class bp_location) <disabled_by_cond>: New field.
* breakpoint.c (set_breakpoint_location_condition): New function.
(set_breakpoint_condition): Disable a breakpoint location if parsing
the condition string gives an error.
(should_be_inserted): Update to consider the 'disabled_by_cond' field.
(build_target_condition_list): Ditto.
(build_target_command_list): Ditto.
(build_bpstat_chain): Ditto.
(print_one_breakpoint_location): Ditto.
(print_one_breakpoint): Ditto.
(breakpoint_1): Ditto.
(bp_location::bp_location): Ditto.
(locations_are_equal): Ditto.
(update_breakpoint_locations): Ditto.
(enable_disable_bp_num_loc): Ditto.
(init_breakpoint_sal): Use set_breakpoint_location_condition.
(find_condition_and_thread_for_sals): New static function.
(create_breakpoint): Call find_condition_and_thread_for_sals.
(location_to_sals): Call find_condition_and_thread_for_sals instead
of find_condition_and_thread.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.cc: New file.
* gdb.base/condbreak-multi-context.exp: New file.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document disabling of breakpoint
locations for which the breakpoint condition is invalid.
gcore is installed on NetBSD, FreeBSD, Solaris (HAVE_NATIVE_GCORE_HOST=1)
and Linux (HAVE_NATIVE_GCORE_TARGET=1). However, even though gcore.1
is installed conditional on those variables, HAVE_NATIVE_GCORE_HOST
was missing from gdb/doc/Makefile.in, so manual installation was
skipped on NetBSD, FreeBSD, and Solaris.
gdb/doc/ChangeLog:
2020-10-06 Michael Forney <mforney@mforney.org>
* Makefile.in (HAVE_NATIVE_GCORE_HOST): Add for gcore.1
install condition.
Change-Id: I17c3ce2ecdfb806ece17f05ba78356b25ffa865e
I forgot that "set/show debug" commands are listed in the doc and in
NEWS, so here they are.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Add set/show debug event-loop.
gdb/ChangeLog:
* NEWS: Mention set/show debug event-loop.
Change-Id: If30b80177049006578280a06912ee2b97bd03a75
I want to add an item to this list, but it's so packed I have trouble
finding where one item ends and the next starts. Add a few empty lines
to make it a bit more readable.
Doing this, I also noticed that an "aix-thread" should in fact be
"aix-solib".
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Add empty lines, fix typo.
Change-Id: I7ef211f9e3988cfbc6ec94124d23a5f2412f3c82
Currently -break-insert always creates a wildmatching breakpoint, and
there's no way to ask for a fullname match. To address that, this
patch adds the equivalent of "break -qualified" to MI:
"-break-insert --qualified".
For the testcase, curiously, it doesn't look like we have _any_
testcase that tests a breakpoint with multiple locations, and, the
existing mi_create_breakpoint / mi_make_breakpoint procedures are only
good for breakpoints with a single location. This patch thus adds a
few new companion routines to mi-support.exp for breakpoints with
multiple locations: mi_create_breakpoint_multi,
mi_make_breakpoint_loc, mi_make_breakpoint_multi.
gdb/ChangeLog:
* NEWS: Document "-break-insert --qualified".
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Handle "--qualified".
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Breakpoint Commands): Document
"-break-insert --qualified" and "-dprintf-insert --qualified".
gdb/testsuite/ChangeLog:
* gdb.mi/mi-break-qualified.cc: New file.
* gdb.mi/mi-break-qualified.exp: New file.
* lib/mi-support.exp (mi_create_breakpoint_multi)
(mi_make_breakpoint_loc, mi_make_breakpoint_multi): New
procedures.
(mi_create_breakpoint_1): New, factored out from
mi_create_breakpoint.
For ARC there are registers that are not part of a required set in XML
target descriptions by default, but are almost always present on ARC
targets and are universally exposed by the ptrace interface. Hardware
loop registers being one of them.
LP_START and LP_END auxiliary registers are hardware loop start and end.
Formally, they are optional, but it is hard to find an ARC configuration
that doesn't have them. They are always present in processors that can
run GNU/Linux. GDB needs to know about those registers to implement
proper software single stepping, since they affect what instruction
will be next.
This commit adds the code to check for the existance of "lp_start" and
"lp_end" in XML target descriptions. If they exist, then the function
reports that the target supports hardware loops.
gdb/ChangeLog:
* arc-tdep.c (arc_check_for_hardware_loop): New.
* arc-tdep.h (gdbarch_tdep): New field has_hw_loops.
gdb/doc/ChangeLog:
* gdb.texinfo (Synopsys ARC): Document LP_START, LP_END and BTA.
A few changes have been made to make the register support simpler,
more flexible and extendible. The trigger for most of these changes
are the remarks [1] made earlier for v2 of this patch. The noticeable
improvements are:
- The arc XML target features are placed under gdb/features/arc
- There are two cores (based on ISA) and one auxiliary feature:
v1-core: ARC600, ARC601, ARC700
v2-core: ARC EM, ARC HS
aux: common in both
- The XML target features represent a minimalistic sane set of
registers irrespective of application (baremetal or linux).
- A concept of "feature" class has been introduced in the code.
The "feature" object is constructed from BFD and GDBARCH data.
It contains necessary information (ISA and register size) to
determine which XML target feature to use.
- A new structure (ARC_REGISTER_FEATURE) is added that allows
providing index, names, and the necessity of registers. This
simplifies the sanity checks and future extendibility.
- Documnetation has been updated to reflect ARC features better.
- Although the feature names has changed, there still exists
backward compatibility with older names through
find_obsolete_[core,aux]_names() functions.
The last two points were inspired from RiscV port.
[1]
https://sourceware.org/pipermail/gdb-patches/2020-May/168511.html
gdb/ChangeLog:
* arch/arc.h
(arc_gdbarch_features): New class to stir the selection of target XML.
(arc_create_target_description): Use FEATURES to choose XML target.
(arc_lookup_target_description): Use arc_create_target_description
to create _new_ target descriptions or return the already created
ones if the FEATURES is the same.
* arch/arc.c: Implementation of prototypes described above.
* gdb/arc-tdep.h (arc_regnum enum): Add more registers.
(arc_gdbarch_features_init): Initialize the FEATURES struct.
* arc-tdep.c (*_feature_name): Make feature names consistent.
(arc_register_feature): A new struct to hold information about
registers of a particular target/feature.
(arc_check_tdesc_feature): Check if XML provides registers in
compliance with ARC_REGISTER_FEATURE structs.
(arc_update_acc_reg_names): Add aliases for r58 and r59.
(determine_*_reg_feature_set): Which feature name to look for.
(arc_gdbarch_features_init): Given MACH and ABFD, initialize FEATURES.
(mach_type_to_arc_isa): Convert from a set of binutils machine types
to expected ISA enums to be used in arc_gdbarch_features structs.
* features/Makefile (FEATURE_XMLFILES): Add new files.
* gdb/features/arc/v1-aux.c: New file.
* gdb/features/arc/v1-aux.xml: Likewise.
* gdb/features/arc/v1-core.c: Likewise.
* gdb/features/arc/v1-core.xml: Likewise.
* gdb/features/arc/v2-aux.c: Likewise.
* gdb/features/arc/v2-aux.xml: Likewise.
* gdb/features/arc/v2-core.c: Likewise.
* gdb/features/arc/v2-core.xml: Likewise.
* NEWS (Changes since GDB 9): Announce obsolence of old feature names.
gdb/doc/ChangeLog:
* gdb.texinfo (Synopsys ARC): Update the documentation for ARC
Features.
gdb/testsuite/ChangeLog:
* gdb.arch/arc-tdesc-cpu.xml: Use new feature names.
This documents some recent Ravenscar changes, and further documents
the known limitation where stepping through the runtime initialization
code does not work properly.
gdb/doc/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Ravenscar Profile): Add examples.
Document runtime initialization limitation.
This patch adds basic support for the eBPF target: tdep and build
machinery. The accompanying simulator is introduced in subsequent
patches.
gdb/ChangeLog:
2020-08-04 Weimin Pan <weimin.pan@oracle.com>
Jose E. Marchesi <jose.marchesi@oracle.com>
* configure.tgt: Add entry for bpf-*-*.
* Makefile.in (ALL_TARGET_OBS): Add bpf-tdep.o
(ALLDEPFILES): Add bpf-tdep.c.
* bpf-tdep.c: New file.
* MAINTAINERS: Add bpf target and maintainer.
gdb/doc/ChangeLog:
2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.texinfo (Contributors): Add information for the eBPF
support.
(BPF): New section.
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class,
this allows gdb.RegisterDescriptor objects to be looked up directly by
register name rather than having to iterate over all registers.
This will be of use for a later commit.
I've documented the new function in the manual, but I don't think a
NEWS entry is required here, as, since the last release, the whole
register descriptor mechanism is new, and is already mentioned in the
NEWS file.
gdb/ChangeLog:
* python/py-registers.c: Add 'user-regs.h' include.
(register_descriptor_iter_find): New function.
(register_descriptor_iterator_object_methods): New static global
methods array.
(register_descriptor_iterator_object_type): Add pointer to methods
array.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: Add additional tests.
gdb/doc/ChangeLog:
* python.texi (Registers In Python): Document new find function.
The list of commands that a stub must implement was wrong.
gdb/ChangeLog:
2020-07-22 Reuben Thomas <rrt@sc3d.org>
* gdb.texinfo (Remote Protocol, Overview): Correct the description
of which remote protocol commands are mandatory for a stub to
implement.
The addition of an anchor for the "frame apply" command was causing
the HTML documentation to include files named both "frame-apply.html"
and "Frame-Apply.html", which collide on case-insensitive file
systems. This patch removes the redundant anchor and adjusts the two
xrefs to it.
2020-07-13 Paul Carroll <pcarroll@codesourcery.com>
PR gdb/25716
gdb/doc/
* gdb.texinfo (Frame Apply): Remove anchor for 'frame
apply' and adjust xrefs to it.
It was deemed better to explicitly mention in help and doc that build IDs
are used for comparison, and that symbols are loaded when asking to
load the exec-file.
This is V2, fixing 2 typos and replacing 'If the user asks to load'
by 'If the user confirms loading', as suggested by Pedro.
gdb/ChangeLog
2020-07-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* exec.c (_initialize_exec): Update exec-file-mismatch help.
gdb/doc/ChangeLog
2020-07-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Attach): Update exec-file-mismatch doc.
Fixes this testsuite fail on Windows:
FAIL: gdb.base/auto-load.exp: print $script_loaded
Converts the debugfile path from c:/dir/file to /c/dir/file, so it can be
appended to the auto-load path.
gdb/ChangeLog:
2020-07-08 Hannes Domani <ssbssa@yahoo.de>
* auto-load.c (auto_load_objfile_script_1): Convert drive part
of debugfile path on Windows.
gdb/doc/ChangeLog:
2020-07-08 Hannes Domani <ssbssa@yahoo.de>
* gdb.texinfo: Document Windows drive conversion of
'set auto-load scripts-directory'.
Add a new method gdb.Architecture.register_groups which returns a new
object of type gdb.RegisterGroupsIterator. This new iterator then
returns objects of type gdb.RegisterGroup.
Each gdb.RegisterGroup object just wraps a single reggroup pointer,
and (currently) has just one read-only property 'name' that is a
string, the name of the register group.
As with the previous commit (adding gdb.RegisterDescriptor) I made
gdb.RegisterGroup an object rather than just a string in case we want
to add additional properties in the future.
gdb/ChangeLog:
* NEWS: Mention additions to Python API.
* python/py-arch.c (archpy_register_groups): New function.
(arch_object_methods): Add 'register_groups' method.
* python/py-registers.c (reggroup_iterator_object): New struct.
(reggroup_object): New struct.
(gdbpy_new_reggroup): New function.
(gdbpy_reggroup_to_string): New function.
(gdbpy_reggroup_name): New function.
(gdbpy_reggroup_iter): New function.
(gdbpy_reggroup_iter_next): New function.
(gdbpy_new_reggroup_iterator): New function
(gdbpy_initialize_registers): Register new types.
(reggroup_iterator_object_type): Define new Python type.
(gdbpy_reggroup_getset): New static global.
(reggroup_object_type): Define new Python type.
* python/python-internal.h
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-groups.exp: New file.
gdb/doc/ChangeLog:
* gdb.texi (Registers): Add @anchor for 'info registers
<reggroup>' command.
* python.texi (Architectures In Python): Document new
register_groups method.
(Registers In Python): Document two new object types related to
register groups.
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
It could be useful to determine the architecture of a frame being
unwound during the frame unwind process, that is, before we have a
gdb.Frame, but when we only have a gdb.PendingFrame.
The PendingFrame already has a pointer to the gdbarch internally, this
commit just exposes an 'architecture' method to Python, and has this
return a gdb.Architecture object (list gdb.Frame.architecture does).
gdb/ChangeLog:
* NEWS: Mention new Python API method.
* python/py-unwind.c (pending_framepy_architecture): New function.
(pending_frame_object_methods): Add architecture method.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for
gdb.PendingFrame.architecture method.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Document
PendingFrame.architecture method.
gdb/doc/ChangeLog:
2020-06-26 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Shell Commands): More accurate description of use
of $SHELL. Reported by Sandra Loosemore <sandra@codesourcery.com>.
This commit adds a new maintenance command that dumps the current
target description as an XML document. This is a maintenance command
as I currently only see this being useful for GDB developers, or for
people debugging a new remote target.
By default the command will print whatever the current target
description is, whether this was delivered by the remote, loaded by
the user from a file, or if it is a built in target within GDB.
The command can also take an optional filename argument. In this case
GDB loads a target description from the file, and then reprints it.
This could be useful for testing GDB's parsing of target descriptions,
or to check that GDB can successfully parse a particular XML
description.
It is worth noting that the XML description printed will not be an
exact copy of the document fed into GDB. For example this minimal
input file:
<target>
<feature name="abc">
<reg name="r1" bitsize="32"/>
</feature>
</target>
Will produce this output:
(gdb) maint print xml-tdesc path/to/file.xml
<?xml version="1.0"?>
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
<feature name="abc">
<reg name="r1" bitsize="32" type="int" regnum="0"/>
</feature>
</target>
Notice that GDB filled in both the 'type' and 'regnum' fields of the
<reg>. I think this is actually a positive as it means we get to
really understand how GDB processed the document, if GDB made some
assumptions that differ to those the user expected then hopefully this
will bring those issues to the users attention.
To implement this I have tweaked the output produced by the
print_xml_feature which is defined within the gdbsupport/ directory.
The changes I have made to this class are:
1. The <architecture>...</architecture> tags are now not produced if
the architecture name is NULL.
2. The <osabi>...</osabi> tags get a newline at the end.
3. And, the whole XML document is indented using white space in a
nested fashion (as in the example output above).
I think that these changes should be fine, the print_xml_feature class
is used:
1. In gdbserver to generate an XML document to send as the target
description to GDB.
2. In GDB as part of a self-check function, a target_desc is
converted to XML then parsed back into a target_desc. We then check
the before and after target_desc objects are the same.
3. In the new 'maint print xml-tdesc' command.
In all of these use cases adding the extra white space should be fine.
gdbsupport/ChangeLog:
* tdesc.cc (print_xml_feature::visit_pre): Use add_line to add
output content, and call indent as needed in all overloaded
variants.
(print_xml_feature::visit_post): Likewise.
(print_xml_feature::visit): Likewise.
(print_xml_feature::add_line): Two new overloaded functions.
* tdesc.h (print_xml_feature::indent): New member function.
(print_xml_feature::add_line): Two new overloaded member
functions.
(print_xml_feature::m_depth): New member variable.
gdb/ChangeLog:
* target-descriptions.c (tdesc_architecture_name): Protect against
NULL pointer dereference.
(maint_print_xml_tdesc_cmd): New function.
(_initialize_target_descriptions): Register new 'maint print
xml-tdesc' command and give it the filename completer.
* NEWS: Mention new 'maint print xml-tdesc' command.
gdb/testsuite/ChangeLog:
* gdb.xml/tdesc-reload.c: New file.
* gdb.xml/tdesc-reload.exp: New file.
* gdb.xml/maint-xml-dump-01.xml: New file.
* gdb.xml/maint-xml-dump-02.xml: New file.
* gdb.xml/maint-xml-dump.exp: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Maintenance Commands): Document new 'maint print
xml-desc' command.
gdb/ChangeLog
2020-06-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Mention change to the alias command.
gdb/doc/ChangeLog
2020-06-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Command aliases default args): New node documenting
how to use default args for a command using aliases.
(Aliases): Document the new 'DEFAULT-ARGS...' option.
(Help): Update help aliases text and describe when full alias
definition is provided.
.gdb_index now supports Ada, so update the documentation to reflect
this.
gdb/doc/ChangeLog
2020-06-11 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Index Files): Reword. Remove Ada limitation.
gdb/doc/ChangeLog:
* gdb.texinfo: Remove broken links Previous and Up from
contents.
Signed-off-by: Jonny Grant <jg@jguk.org>
Change-Id: Iad7323580a3c0c7f00eab1264d66f39e8d156e38
Readline has a styling feature for completion -- if it is enabled, the
common prefix of completions will be displayed in a different style.
This doesn't work in gdb, because gdb implements its own completer.
This patch implements the feature. However, it doesn't directly use
the Readline feature, because gdb can do a bit better: it can let the
user control the styling using the existing mechanisms.
This version incorporates an Emacs idea, via Eli: style the prefix,
the "difference character", and the suffix differently.
gdb/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for completion styling.
* completer.c (_rl_completion_prefix_display_length): Move
declaration earlier.
(gdb_fnprint): Use completion_style.
(gdb_display_match_list_1): Likewise.
* cli/cli-style.c (completion_prefix_style)
(completion_difference_style, completion_suffix_style): New
globals.
(_initialize_cli_style): Register new globals.
* cli/cli-style.h (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Declare.
gdb/doc/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Output Styling): Mention completion styling.
(Editing): Mention readline completion styling.
gdb/testsuite/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add completion styling test.
* lib/gdb-utils.exp (style): Add completion styles.
The patch makes GDB do exec-file-mismatch validation by comparing
build IDs instead of the current method of comparing filenames.
Currently, the exec-file-mismatch feature simply compares filenames to
decide whether the exec file loaded in gdb and the exec file the
target reports is running match. This causes false positives when
remote debugging, because it'll often be the case that the paths in
the host and the target won't match. And of course misses the case of
the files having the same name but being actually different files
(e.g., different builds).
This also broke many testcases when running against gdbserver, causing
tests to be skipped like (here native-extended-gdbserver):
(gdb) run
Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink-filelink
warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink-filelink
and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink"? (y or n) UNTESTED: gdb.base/argv0-symlink.exp: could not run to main
or to fail like (here native-gdbserver):
(gdb) spawn /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2346 /home/pedro/gdb/binutils-gdb/build/gdb/te
stsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x
Process /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x created; pid = 20040
Listening on port 2346
target remote localhost:2346
Remote debugging using localhost:2346
warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/temp/19968/skip_btrace_tests-19968.x
and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x"? (y or n) Quit
(gdb) UNSUPPORTED: gdb.btrace/buffer-size.exp: target does not support record-btrace
The former case is about GDB not realizing the two files are the same,
because one of the them is a symlink to the other. The latter case is
about GDB realizing that one file is a copy of the other.
Over the years, the toolchain has settled on build ID matching being
the canonical method to match core dumps to executables, and
executables with no debug info to their debug info.
This patch makes us use build IDs to match the running image of a
binary with its version loaded in gdb, which may or may not have debug
info. This is very much like the core dump/executable matching.
The change to gdb_bfd_open is necessary to get rid of the "transfers
from remote targets can be slow" warning when we open the remote file
to read its build ID:
(gdb) r
Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break
Reading /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break
and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink"? (y or n)
While trying this out, I was worried that bfd would read a lot of
stuff from the binary in order to extract the build ID, making it
potentially slow, but turns out we don't read all that much. Maybe a
couple hundred bytes, and most of it seemingly is the read-ahead
cache. So I'm not worried about that. Otherwise I'd consider whether
a new qXfer:buildid:read would be better. But I'm happy that we
seemingly don't need to worry about it.
gdb/ChangeLog:
2020-05-19 Pedro Alves <palves@redhat.com>
* NEWS (set exec-file-mismatch): Adjust entry.
* exec.c: Include "build-id.h".
(validate_exec_file): Try to match build IDs instead of filenames.
* gdb_bfd.c (struct gdb_bfd_open_closure): New.
(gdb_bfd_iovec_fileio_open): Adjust to use gdb_bfd_open_closure
and pass down 'warn_if_slow'.
(gdb_bfd_open): Add 'warn_if_slow' parameter. Use
gdb_bfd_open_closure to pass it down.
* gdb_bfd.h (gdb_bfd_open): Add 'warn_if_slow' parameter.
gdb/doc/ChangeLog:
2020-05-19 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Attach): Update exec-file-mismatch description to
mention build IDs.
(Separate Debug Files): Add "build id" anchor.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Mention changes to help and apropos.
gdb/doc/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Help): Document the help and apropos changes.
(Aliases): Document new meaning of -a abbreviation flag.
Now that Python code can create TUI windows, it seemed appropriate to
allow Python commands to appear in the "TUI" help class. This patch
adds this capability.
gdb/ChangeLog
2020-04-28 Tom Tromey <tom@tromey.com>
* NEWS: Update.
* python/py-cmd.c (gdbpy_initialize_commands): Add COMMAND_TUI.
(cmdpy_init): Allow class_tui.
gdb/doc/ChangeLog
2020-04-28 Tom Tromey <tom@tromey.com>
* python.texi (Commands In Python): Document gdb.COMMAND_TUI.
This expands the Python dynamic type documentation, as suggested by
Christian.
gdb/doc/ChangeLog
2020-04-27 Tom Tromey <tromey@adacore.com>
* python.texi (Types In Python): Mention missing fields. Add
dynamic type example.
This changes the gdb Python API to add support for dynamic types. In
particular, this adds an attribute to gdb.Type, and updates some
attributes to reflect dynamic sizes and field offsets.
There's still no way to get the dynamic type from one of its concrete
instances. This could perhaps be added if needed.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python/py-type.c (convert_field): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
(typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH.
(typy_get_dynamic): Nw function.
(type_object_getset): Add "dynamic".
* NEWS: Add entry.
gdb/doc/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python.texi (Types In Python): Document new features.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* gdb.ada/variant.exp: Add Python checks.
* gdb.rust/simple.exp: Add dynamic type checks.
Building gdb-9.1 on a system that has an older version of makeinfo
(4.8) shows the following warnings:
-----------------
make[4]: Entering directory '/home/tester/gdb-9.1/build/gdb/doc'
makeinfo --split-size=5000000 --split-size=5000000 -I
../../../gdb/doc/../../readline/readline/doc -I ../../../gdb/doc/../mi
-I ../../../gdb/doc \
-o gdb.info ../../../gdb/doc/gdb.texinfo
../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character ] in @var.
../../../gdb/doc//python.texi:3297: warning: `.' or `,' must follow
@xref, not `A'.
make[4]: Leaving directory '/home/tester/gdb-9.1/build/gdb/doc'
-----------------
These are thrown by expressions like `@var{[host]}`, intended to
produce `[HOST]`.
In that context this should instead be changed to `[@var{host}]`, which
has the same effect but without the warnings.
As for the warning in `python.texi`, there's period missing at the end
of one `@xref{}` clause. Added.
gdb/doc/ChangeLog:
2020-04-15 Artur Shepilko <nomadbyte@gmail.com>
* gdb.texinfo: Transform @var{[host]} to [@var{host}]; this
clears makeinfo warnings.
* python.texi: Add a missing period trailing an @xref{} clause;
this clears a makeinfo warning.
Replace "the the" by "the".
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* NEWS: Fix "the the".
* ctfread.c: Same.
gdb/doc/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* gdb.texinfo: Fix "the the".
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* README: Fix "the the".
* gdb.base/dprintf.exp: Same.
Since commit 3453e7e409 'Clean up "Reading symbols" output' we no longer print
"done." after the "Reading symbols from" message:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb)
...
Update docs accordingly.
Build on x86_64-linux.
gdb/doc/ChangeLog:
2020-03-04 Tom de Vries <tdevries@suse.de>
* gdb.texinfo: Remove trailing "done." in "Reading symbols from" lines.
* python.texi: Same.
This commit aims to give a cleaner mechanism by which the user can
prevent GDB from trying to load any previous command history.
Currently the user can change the path to the history file, either
using a command line flag, or by setting the GDBHISTFILE environment
variable, and if the path is set to a non-existent file, then
obviously GDB wont load any command history. However, this feels like
a bit of a bodge, I'd like to add an official mechanism by which we
can disable command history loading.
Why would we want to prevent command history loading? The specific
use case I have is GDB starting with a CWD that is a network mounted
directory, and there is no command history present. Still GDB will
access the network in order to check for the file. In my particular
use case I'm actually starting a large number of GDB instances in
parallel, all in the same network mounted directory, the large number
of network accesses looking for this file introduces a noticeable
delay at GDB startup.
The approach I'm proposing here is a slight adjustment to the current
rules for setting up the history filename. Currently, if a user does
this, they see an error:
(gdb) set history filename
Argument required (filename to set it to.).
However, if a user does this:
$ GDBHISTFILE= gdb --quiet
(gdb) set history save on
(gdb) q
warning: Could not rename -gdb18416~ to : No such file or directory
So, we already have a bug in this area. My plan is to allow the empty
filename to be accepted, and for this to mean, neither load, nor save
the command history.
This does mean that we now have two mechanisms to prevent saving the
command history:
(gdb) set history filename
or
(gdb) set history save off
But the only way to prevent loading the command history is to set the
filename to the empty string _before_ you get to a GDB prompt, either
using a command line option, or the environment variable.
I've updated some of the show commands, for example this session:
(gdb) set history filename
(gdb) show history filename
There is no filename currently set for recording the command history in.
(gdb) show history save
Saving of the history record on exit is off.
(gdb) set history save on
(gdb) show history save
Saving of the history is disabled due to the value of 'history filename'.
(gdb) set history filename /tmp/hist
(gdb) show history save
Saving of the history record on exit is on.
I've updated the manual, and added some tests.
gdb/ChangeLog:
* NEWS: Mention new behaviour of the history filename.
* top.c (write_history_p): Add comment.
(show_write_history_p): Add header comment, give a different
message when history writing is on, but the history filename is
empty.
(history_filename): Add comment.
(history_filename_empty): New function.
(show_history_filename): Add header comment, give a different
message when the filename is empty.
(init_history): Compare history_filename against nullptr, and only
read history if the filename is not empty.
(set_history_filename): Add header comment, and only make
non-empty filenames absolute.
(init_main): Make the filename argument to 'set history filename'
optional.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Extend description for
GDBHISTFILE and GDBHISTSIZE, add detail about the filename for
'set history filename' being optional. Describe the effect of an
empty history filename on 'set history save on'.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Remove test of 'set history filename'.
* gdb.base/gdbinit-history.exp: Add tests for setting the history
filename to the empty string.
* lib/gdb.exp (gdb_init): Unset environment variables GDBHISTFILE
and GDBHISTSIZE.
Change-Id: Ia586e4311182fac99113b60f11ef8a11fbd5450b
debuginfod is a lightweight web service that indexes ELF/DWARF debugging
resources by build-id and serves them over HTTP.
This patch enables GDB to query debuginfod servers for separate debug
files and source code when it is otherwise not able to find them.
GDB can be built with debuginfod using the --with-debuginfod configure
option.
This requires that libdebuginfod be installed and found at configure time.
debuginfod is packaged with elfutils, starting with version 0.178.
For more information see https://sourceware.org/elfutils/.
Tested on x86_64 Fedora 31.
gdb/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* Makefile.in: Handle optional debuginfod support.
* NEWS: Update.
* README: Add --with-debuginfod summary.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Handle optional debuginfod support.
* debuginfod-support.c: debuginfod helper functions.
* debuginfod-support.h: Ditto.
* doc/gdb.texinfo: Add --with-debuginfod to configure options
summary.
* dwarf2/read.c (dwarf2_get_dwz_file): Query debuginfod servers
when a dwz file cannot be found.
* elfread.c (elf_symfile_read): Query debuginfod servers when a
debuginfo file cannot be found.
* source.c (open_source_file): Query debuginfod servers when a
source file cannot be found.
* top.c (print_gdb_configuration): Include
--{with,without}-debuginfod in the output.
gdb/testsuite/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* gdb.debuginfod: New directory for debuginfod tests.
* gdb.debuginfod/main.c: New test file.
* gdb.debuginfod/fetch_src_and_symbols.exp: New tests.
Fixes small white space issue in the example output of 'info threads'.
gdb/doc/ChangeLog:
* gdb.texinfo (Threads): Fix alignment in 'info threads' example
output.
This patch adds support for writing new TUI windows in Python.
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for gdb.register_window_type.
* tui/tui-layout.h (window_factory): New typedef.
(tui_register_window): Declare.
* tui/tui-layout.c (saved_tui_windows): New global.
(tui_apply_current_layout): Use it.
(tui_register_window): New function.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_tui.
(python_GdbMethods): Add "register_window_type" function.
* python/python-internal.h (gdbpy_register_tui_window)
(gdbpy_initialize_tui): Declare.
* python/py-tui.c: New file.
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* python.texi (Python API): Add menu item.
(TUI Windows In Python): New node.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.python/tui-window.exp: New file.
* gdb.python/tui-window.py: New file.
Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
This changes the TUI layout engine to add horizontal splitting. Now,
windows can be side-by-side.
A horizontal split is defined using the "-horizontal" parameter to
"tui new-layout".
This also adds the first "winheight" test to the test suite. One open
question is whether we want a new "winwidth" command, now that
horizontal layouts are possible. This is easily done using the
generic layout code.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* tui/tui-win.c (tui_gen_win_info::max_width): New method.
* tui/tui-layout.h (class tui_layout_base) <get_sizes>: Add
"height" argument.
(class tui_layout_window) <get_sizes>: Likewise.
(class tui_layout_split) <tui_layout_split>: Add "vertical"
argument.
<get_sizes>: Add "height" argument.
<m_vertical>: New field.
* tui/tui-layout.c (tui_layout_split::clone): Update.
(tui_layout_split::get_sizes): Add "height" argument.
(tui_layout_split::adjust_size, tui_layout_split::apply): Update.
(tui_new_layout_command): Parse "-horizontal".
(_initialize_tui_layout): Update help string.
(tui_layout_split::specification): Add "-horizontal" when needed.
* tui/tui-layout.c (tui_layout_window::get_sizes): Add "height"
argument.
* tui/tui-data.h (struct tui_gen_win_info) <max_width, min_width>:
New methods.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* gdb.texinfo (TUI Commands): Document horizontal layouts.
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
PR tui/17850:
* gdb.tui/new-layout.exp: Add horizontal layout and winheight
tests.
Change-Id: I38b35e504f34698578af86686be03c0fefd954ae
This adds a new command, "tui new-layout". This command can be used
to define a new TUI window layout.
The command is used like:
(gdb) tui new-layout name src 1 regs 1 status 0 cmd 1
The first argument is the name of the layout. In this example, it is
"name", so the new layout could be seen by "layout name".
Subsequent arguments come in pairs, where the first item in a pair is
the name of a window, and the second item in a pair is the window's
weight. A weight is just an integer -- a window's allocated size is
proportional to the total of the weights given. So, in the above
example, all windows will have the same size (the status windows's
weight does not matter, because it has fixed height).
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* NEWS: Add "tui new-layout" item.
* tui/tui-layout.c (add_layout_command): Return cmd_list_element.
Add new-layout command to help text.
(validate_window_name): New function.
(tui_new_layout_command): New function.
(_initialize_tui_layout): Register "new-layout".
(tui_layout_window::specification): New method.
(tui_layout_window::specification): New method.
* tui/tui-layout.h (class tui_layout_base) <specification>: New
method.
(class tui_layout_window) <specification>: New method.
(class tui_layout_split) <specification>: New method.
gdb/doc/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Overview): Mention user layouts.
(TUI Commands): Document "tui new-layout".
gdb/testsuite/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* gdb.tui/new-layout.exp: New file.
Change-Id: Id7c3ace20ab1e8924f8f4ad788f40210f58a5c05
From what I can tell, The m68k floating point target feature should
apparently always be called "org.gnu.gdb.coldfire.fp" -- even when the
primary feature is not "coldfire", because m68k_gdbarch_init only
checks for this feature when assigning register numbers.
However, the floating point registers are expected to match what gdb
thinks are the register sizes for the primary feature. For example,
if the main feature is "coldfire", then the floating point registers
should be 64 bits.
See this note for some an instance of this confusion:
https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg04564.html
This patch documents the oddity.
Let me know what you think. An alternate approach here might be to
make gdb adapt to the register sizes as actually reported. I'm not
sure if this makes sense or not.
gdb/doc/ChangeLog
2020-01-26 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (M68K Features): Document floating-point feature
correspondence.
Change-Id: I4cd86acbe3449a29ce38327524c508c206b25b8f
Mention in NEWS the new option and the set/show commands.
Document in gdb.texinfo the new option and the set/show commands.
gdb/ChangeLog
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Mention the new option and the set/show commands.
gdb/doc/ChangeLog
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Attach): Document the new option and the
set/show commands.
(Connecting): Reference the exec-file-mismatch option.
I spotted a few misplaced entries in the ChangeLog-2019 entries, and
went on to fix them.
Looking around I saw a good number of other entries in other years.
Then OCD got the best of me and I fixed them all.
Also fixes cases of wrong paths in entries, like "* gdb/foo.c" instead
of "* foo.c".
This commit documents the new multi-target features in both NEWS and
user manual.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* NEWS: Mention multi-target debugging, "info connections", and
"add-inferior -no-connection".
gdb/doc/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Starting): Say "current inferior not connected"
instead of "GDB not connected".
(Inferiors and Programs): Rename node to ...
(Inferiors Connections and Programs): ... this. Update all
references. Talk about multiple target connections. Update "info
inferiors" info to mention the connections column. Describe "info
connections". Document "add-inferior -no-connection".
* guile.texi, python.texi: Update cross references.
