| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The Guile API doesn't currently have an equivalent to the Python API's
gdb.Value.const_value(). This commit adds a procedure with equivalent
semantics to the Guile API.
gdb/ChangeLog:
* NEWS (Guile API): Note the addition of the new procedure.
* guile/scm-value.c (gdbscm_value_const_value): Add
implementation of value-const-value procedure.
(value_functions): Add value-const-value procedure.
gdb/doc/ChangeLog:
* guile.texi (Values From Inferior In Guile): Add documentation
for value-const-value.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-value.exp (test_value_in_inferior): Add test for
value-const-value.
|
|
The Guile API doesn't currently have an equivalent to the Python API's
Value.reference_value() or Value.rvalue_reference_value(). This commit
adds a procedure with equivalent semantics to the Guile API.
gdb/ChangeLog:
* NEWS (Guile API): Note the addition of new procedures.
* guile/scm-value.c (gdbscm_reference_value): Add helper function
for reference value creation.
(gdbscm_value_reference_value): Add implementation of
value-reference-value procedure.
(gdbscm_value_rvalue_reference_value): Add implementation of
value-rvalue-reference-value procedure.
(value_functions): Add value-reference-value procedure. Add
value-rvalue-reference-value procedure.
gdb/doc/ChangeLog:
* guile.texi (Values From Inferior In Guile): Add documentation
for value-reference-value. Add documentation for
value-rvalue-reference-value.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-value.exp (test_value_in_inferior): Add test for
value-reference-value. Add test for value-rvalue-reference-value.
|
|
Adds a couple of missing bits to the Guile API to make C++11 rvalue
reference values and types usable from Guile scripts.
gdb/ChangeLog:
* guile/scm-type.c (type_integer_constants): Add binding for
TYPE_CODE_RVALUE_REF.
* guile/scm-value.c (gdbscm_value_referenced_value): Handle
dereferencing of rvalue references.
* NEWS (Guile API): Note improvements in rvalue reference support.
gdb/doc/ChangeLog:
* guile.texi (Types In Guile): Add documentation for
TYPE_CODE_RVALUE_REF.
|
|
Add a '--force' flag to the '-break-condition' command to be
able to force conditions.
gdb/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* mi/mi-cmd-break.c (mi_cmd_break_condition): New function.
* mi/mi-cmds.c: Change the binding of "-break-condition" to
mi_cmd_break_condition.
* mi/mi-cmds.h (mi_cmd_break_condition): Declare.
* breakpoint.h (set_breakpoint_condition): Declare a new
overload.
* breakpoint.c (set_breakpoint_condition): New overloaded function
extracted out from ...
(condition_command): ... this.
* NEWS: Mention the change.
gdb/testsuite/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp (test_forced_conditions): Add a test
for the -break-condition command's "--force" flag.
gdb/doc/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention the
'--force' flag of the '-break-condition' command.
|
|
Add a '--force-condition' flag to the '-break-insert' command to be
able to force conditions. Because the '-dprintf-insert' command uses
the same mechanism as the '-break-insert' command, it obtains the
'--force-condition' flag, too.
gdb/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Recognize the
'--force-condition' flag to force the condition in the
'-break-insert' and '-dprintf-insert' commands.
* NEWS: Mention the change.
gdb/testsuite/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp (test_forced_conditions): New proc that
is called by the test.
gdb/doc/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention the
'--force-condition' flag of the '-break-insert' and
'-dprintf-insert' commands.
|
|
Some errors introduced in commit:
commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9
Date: Thu Aug 27 16:53:13 2020 +0100
gdb: startup commands to control Python extension language
gdb/ChangeLog:
* NEWS: Fix typo and stray full stop.
|
|
Add two new commands to GDB that can be placed into the early
initialization to control how Python starts up. The new options are:
set python ignore-environment on|off
set python dont-write-bytecode auto|on|off
show python ignore-environment
show python dont-write-bytecode
These can be used from GDB's startup file to control how the Python
extension language behaves. These options are equivalent to the -E
and -B flags to python respectively, their descriptions from the
Python man page:
-E Ignore environment variables like PYTHONPATH and PYTHONHOME
that modify the behavior of the interpreter.
-B Don't write .pyc files on import.
gdb/ChangeLog:
* NEWS: Mention new commands.
* python/python.c (python_ignore_environment): New static global.
(show_python_ignore_environment): New function.
(set_python_ignore_environment): New function.
(python_dont_write_bytecode): New static global.
(show_python_dont_write_bytecode): New function.
(set_python_dont_write_bytecode): New function.
(_initialize_python): Register new commands.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Mention new commands.
gdb/testsuite/ChangeLog:
* gdb.python/py-startup-opt.exp: New file.
|
|
This commit adds a flag to the ptype command in order to print the
offsets and sizes of struct members using the hexadecimal notation. The
'x' flag ensures use of the hexadecimal notation while the 'd' flag
ensures use of the decimal notation. The default is to use decimal
notation.
Before this patch, gdb only uses decimal notation, as pointed out in PR
gdb/22640.
Here is an example of this new behavior with hex output turned on:
(gdb) ptype /ox struct type_print_options
/* offset | size */ type = struct type_print_options {
/* 0x0000: 0x0 | 0x0004 */ unsigned int raw : 1;
/* 0x0000: 0x1 | 0x0004 */ unsigned int print_methods : 1;
/* 0x0000: 0x2 | 0x0004 */ unsigned int print_typedefs : 1;
/* 0x0000: 0x3 | 0x0004 */ unsigned int print_offsets : 1;
/* 0x0000: 0x4 | 0x0004 */ unsigned int print_in_hex : 1;
/* XXX 3-bit hole */
/* XXX 3-byte hole */
/* 0x0004 | 0x0004 */ int print_nested_type_limit;
/* 0x0008 | 0x0008 */ typedef_hash_table *local_typedefs;
/* 0x0010 | 0x0008 */ typedef_hash_table *global_typedefs;
/* 0x0018 | 0x0008 */ ext_lang_type_printers *global_printers;
/* total size (bytes): 32 */
}
This patch also adds the 'set print type hex' and 'show print type hex'
commands in order to set and inspect the default behavior regarding the
use of decimal or hexadecimal notation when printing struct sizes and
offsets.
Tested using on x86_64.
gdb/ChangeLog:
PR gdb/22640
* typeprint.h (struct type_print_options): Add print_in_hex
flag.
(struct print_offset_data): Add print_in_hex flag, add a
constructor accepting a type_print_options* argument.
* typeprint.c (type_print_raw_options, default_ptype_flags): Set
default value for print_in_hex.
(print_offset_data::indentation): Allow more horizontal space.
(print_offset_data::print_offset_data): Add ctor.
(print_offset_data::maybe_print_hole, print_offset_data::update):
Handle the print_in_hex flag.
(whatis_exp): Handle 'x' and 'd' flags.
(print_offsets_and_sizes_in_hex): Declare.
(set_print_offsets_and_sizes_in_hex): Create.
(show_print_offsets_and_sizes_in_hex): Create.
(_initialize_typeprint): Update help message for the ptype
command, register the 'set print type hex' and 'show print type
hex' commands.
* c-typeprint.c (c_print_type, c_type_print_base_struct_union)
(c_type_print_base): Construct the print_offset_data
object using the type_print_optons parameter.
* rust-lang.c (rust_language::print_type): Construct the
print_offset_data object using the type_print_optons parameter.
* NEWS: Mention the new flags of the ptype command.
gdb/doc/ChangeLog:
PR gdb/22640
* gdb.texinfo (Symbols): Describe the 'x' and 'd' flags of the
ptype command, describe 'set print type hex' and 'show print
type hex' commands. Update 'ptype/o' examples.
gdb/testsuite/ChangeLog:
PR gdb/22640
* gdb.base/ptype-offsets.exp: Add tests to verify the behavior
of 'ptype/ox' and 'ptype/od'. Check that 'set print type hex'
changes the default behavior of 'ptype/o'. Update to take into
account new horizontal layout.
* gdb.rust/simple.exp: Update ptype test to check new horizontal
layout.
* gdb.rust/union.exp: Same.
|
|
This adds a new command to change GDB to behave as though "-quiet"
were always given. This new command can be added to the gdbearlyinit
file to affect future GDB sessions.
gdb/ChangeLog:
* NEWS: Add entry.
* main.c (captured_main_1): Call check_quiet_mode.
* top.c (startup_quiet): New global.
(check_quiet_mode): New function.
(show_startup_quiet): New function.
(init_main): Register new command.
* top.h (check_quiet_mode): Declare.
gdb/doc/ChangeLog:
* gdb.texinfo (Mode Options): Mention "set startup-quietly".
gdb/testsuite/ChangeLog:
* gdb.base/startup-file.exp: Add more tests.
|
|
Adds the ability to process commands at a new phase during GDB's
startup. This phase is earlier than the current initialisation file
processing, before GDB has produced any output.
The number of commands that can be processed at this early stage will
be limited, and it is expected that the only commands that would be
processed at this stage will relate to some of the fundamentals of how
GDB starts up.
Currently the only commands that it makes sense to add to this early
initialization file are those like 'set style version ....' as the
version string is displayed during startup before the standard
initialization files are parsed. As such this commit fully resolved
bug cli/25956.
This commit adds a mechanism to execute these early initialization
files from a users HOME directory, as well as some corresponding
command line flags for GDB.
The early initialization files that GDB will currently check for are
~/.config/gdb/gdbearlyinit (on Linux like systems) or ~/.gdbearlyinit
if the former is not found.
The output of 'gdb --help' has been extended to include a list of the
early initialization files being processed.
gdb/ChangeLog:
PR cli/25956
* NEWS: Mention new early init files and command line options.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Define GDBEARLYINIT.
* main.c (get_earlyinit_files): New function.
(enum cmdarg_kind): Add CMDARG_EARLYINIT_FILE and
CMDARG_EARLYINIT_COMMAND.
(captured_main_1): Add support for new command line flags, and for
processing startup files.
(print_gdb_help): Include startup files in the output.
gdb/doc/ChangeLog:
PR cli/25956
* gdb.texinfo (File Options): Mention new command line options.
(Startup): Discuss when early init files are processed.
(Initialization Files): Add description of early init files.
(Output Styling): Update description of 'version' style.
(gdb man): Mention early init files.
gdb/testsuite/ChangeLog:
PR cli/25956
* gdb.base/early-init-file.c: New file.
* gdb.base/early-init-file.exp: New file.
* lib/gdb-utils.exp (style): Handle style 'none'.
|
|
Mention the new packets and memory tagging features.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* NEWS: Mention memory tagging changes.
|
|
We already have a command 'maint info sections', this command prints
all sections from all known object files.
However, GDB maintains a second section table internally. This
section table is used when GDB wants to read directly from an object
file rather than actually reading memory on the target. As such only
some sections (the allocatable ones) are added to this secondary
section table.
I recently ran into a situation where some of GDB's optimisations for
reading directly from the files were not working. In 'maint info
sections' I could see that GDB knew about the object file, and did
know about the sections that it _should_ have been reading from. But
I couldn't ask GDB which sections it had copied into its secondary
section table.
This commit adds a new command 'maint info target-sections' that fills
this gap. This command lists only those sections that GDB has copied
into its secondary table.
You'll notice that the testsuite includes a comment indicating that
there's a bug in GDB. Normally this is not something I would add to
the testsuite, instead we should raise an actual bugzilla bug and then
mark an xfail, however, a later patch in this series will remove this
comment once the actual bug in GDB is fixed.
gdb/ChangeLog:
* NEWS: Mention new 'maint info target-sections' command.
* maint.c (maintenance_info_target_sections): New function.
(_initialize_maint_cmds): Register new command.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Document new 'maint info target-sections'
command.
gdb/testsuite/ChangeLog:
* gdb.base/maint-info-sections.exp: Add new tests.
(check_maint_info_target_sections_output): New proc.
|
|
The 'maintenance info sections' command currently takes a list of
filters on the command line. It can also accept the magic string
'ALLOBJ' which acts more like a command line flag, telling the command
to print information about all objfiles.
The manual has this to say about the options and filters:
... In addition, 'maint info sections' provides the following
command options (which may be arbitrarily combined): ...
Implying (to me at least) that I can do this:
(gdb) maint info sections ALLOBJ READONLY
to list all the read-only sections from all currently loaded object
files.
Unfortunately, this doesn't work. The READONLY filter will work, but
ALLOBJ will not be detected correctly.
It would be fairly simple to fix the ALLOBJ detection. However, I
dislike this mixing of command options (ALLOBJ) with command data (the
filters, e.g. READONLY, etc).
As this is a maintenance command, so not really intended for end
users, I think we can be a little more aggressive in "fixing" the
option parsing. So that's what I do in this commit.
The ALLOBJ mechanism is replaced with a real command
option (-all-objects). The rest of the command operates just as
before. The example above would now become:
(gdb) maint info sections -all-objects READONLY
The manual has been updated, and I added a NEWS entry to document the
change.
gdb/ChangeLog:
* NEWS: Mention changes to 'maint info sections'.
* maint.c (match_substring): Return a bool, fix whitespace issue.
(struct single_bfd_flag_info): New struct.
(bfd_flag_info): New static global.
(match_bfd_flags): Return a bool, use bfd_flag_info.
(print_bfd_flags): Use bfd_flag_info.
(maint_print_section_info): Delete trailing whitespace.
(struct maint_info_sections_opts): New struct.
(maint_info_sections_option_defs): New static global.
(maint_info_sections_completer): New function.
(maintenance_info_sections): Use option parsing mechanism.
(_initialize_maint_cmds): Register command completer.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Update documentation for 'maint info
sections'.
gdb/testsuite/ChangeLog:
* gdb.base/maint-info-sections.exp: Update expected output, and
add additional tests. Again.
|
|
Since it has gone from bfd/.
* arm-symbian-tdep.c: Delete.
* NEWS: Mention arm-symbian removal.
* Makefile.in: Remove arm-symbian-tdep entries.
* configure.tgt: Remove arm*-*-symbianelf*.
* doc/gdb.texinfo: Remove mention of SymbianOS.
* osabi.c (gdb_osabi_names): Remove "Symbian".
* osabi.h (enum gdb_osabi): Remove GDB_OSABI_SYMBIAN.
* testsuite/gdb.base/ending-run.exp: Remove E32Main handling.
* testsuite/gdb.ada/catch_ex_std.exp: Remove arm*-*-symbianelf*
handling.
* testsuite/gdb.base/dup-sect.exp: Likewise.
* testsuite/gdb.base/long_long.exp: Likewise.
* testsuite/gdb.base/solib-weak.exp: Likewise.
* testsuite/gdb.guile/scm-section-script.exp: Likewise.
* testsuite/gdb.python/py-section-script.exp: Likewise.
* testsuite/lib/dwarf.exp: Likewise.
* testsuite/lib/gdb.exp: Likewise.
|
|
This patch makes the inferior command display information about the
current inferior when called with no argument. This behavior is similar
to the one of the thread command.
Before patch:
(gdb) info inferior
Num Description Connection Executable
* 1 process 19221 1 (native) /home/lsix/tmp/a.out
2 process 19239 1 (native) /home/lsix/tmp/a.out
(gdb) inferior 2
[Switching to inferior 2 [process 19239] (/home/lsix/tmp/a.out)]
[Switching to thread 2.1 (process 19239)]
#0 0x0000000000401146 in main ()
(gdb) inferior
Argument required (expression to compute).
After patch:
(gdb) info inferior
Num Description Connection Executable
* 1 process 18699 1 (native) /home/lsix/tmp/a.out
2 process 18705 1 (native) /home/lsix/tmp/a.out
(gdb) inferior 2
[Switching to inferior 2 [process 18705] (/home/lsix/tmp/a.out)]
[Switching to thread 2.1 (process 18705)]
#0 0x0000000000401146 in main ()
(gdb) inferior
[Current inferior is 2 [process 18705] (/home/lsix/tmp/a.out)]
gdb/doc/ChangeLog:
* gdb.texinfo (Inferiors Connections and Programs): Document the
inferior command when used without argument.
gdb/ChangeLog:
* NEWS: Add entry for the behavior change of the inferior command.
* inferior.c (inferior_command): When no argument is given to the
inferior command, display info about the currently selected
inferior.
gdb/testsuite/ChangeLog:
* gdb.base/inferior-noarg.c: New test.
* gdb.base/inferior-noarg.exp: New test.
|
|
This commit adds a new 'version' style, which replaces the hard coded
styling currently used for GDB's version string. GDB's version number
is displayed:
1. In the output of 'show version', and
2. When GDB starts up (without the --quiet option).
This new style can only ever affect the first of these two cases as
the second case is printed before GDB has processed any initialization
files, or processed any GDB commands passed on the command line.
However, because the first case exists I think this commit makes
sense, it means the style is no longer hard coded into GDB, and we can
add some tests that the style can be enabled/disabled correctly.
This commit is an alternative to a patch Tom posted here:
https://sourceware.org/pipermail/gdb-patches/2020-June/169820.html
I've used the style name 'version' instead of 'startup' to reflect
what the style is actually used for. If other parts of the startup
text end up being highlighted I imagine they would get their own
styles based on what is being highlighted. I feel this is more inline
with the other style names that are already in use within GDB.
I also decoupled adding this style from the idea of startup options,
and the possibility of auto-saving startup options. Those ideas can
be explored in later patches.
This commit should probably be considered only a partial solution to
issue PR cli/25956. The colours of the style are no longer hard
coded, however, it is still impossible to change the styling of the
version string displayed during startup, so in one sense, the styling
of that string is still "hard coded". A later patch will hopefully
extend GDB to allow it to adjust the version styling before the
initial version string is printed.
gdb/ChangeLog:
PR cli/25956
* cli/cli-style.c: Add 'cli/cli-setshow.h' include.
(version_style): Define.
(cli_style_option::cli_style_option): Add intensity parameter, and
use as appropriate.
(_initialize_cli_style): Register version style set/show commands.
* cli/cli-style.h (cli_style_option): Add intensity parameter.
(version_style): Declare.
* top.c (print_gdb_version): Use version_stype, and styled_string
to print the GDB version string.
gdb/doc/ChangeLog:
PR cli/25956
* gdb.texinfo (Output Styling): Document version style.
gdb/testsuite/ChangeLog:
PR cli/25956
* gdb.base/style.exp (run_style_tests): Add version string test.
(test_startup_version_string): Use version style name.
* lib/gdb-utils.exp (style): Handle version style name.
|
|
Add a new command to flush the dcache.
gdb/ChangeLog:
* NEWS: Mention new commands.
* target-dcache.c: Add 'cli/cli-cmds.h' include.
(maint_flush_dcache_command): New function.
(_initialize_target_dcache): Create new 'maint flush dcache'
command.
gdb/doc/ChangeLog:
* gdb.texinfo (Caching Target Data): Document 'maint flush
dcache'.
gdb/testsuite/ChangeLog:
* gdb.base/dcache-flush.c: New file.
* gdb.base/dcache-flush.exp: New file.
|
|
We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'. I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.
And so I created the 'maint flush ' command prefix. Currently there
are two commands:
(gdb) maint flush symbol-cache
(gdb) maint flush register-cache
Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild. So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.
I've updated the testsuite to use the new command syntax, and updated
the documentation too.
gdb/ChangeLog:
* NEWS: Mention new commands, and that the old commands are now
deprecated.
* cli/cli-cmds.c (maintenanceflushlist): Define.
* cli/cli-cmds.h (maintenanceflushlist): Declare.
* maint.c (_initialize_maint_cmds): Initialise
maintenanceflushlist.
* regcache.c: Add 'cli/cli-cmds.h' include.
(reg_flush_command): Add header comment.
(_initialize_regcache): Create new 'maint flush register-cache'
command, make 'flushregs' an alias.
* symtab.c: Add 'cli/cli-cmds.h' include.
(_initialize_symtab): Create new 'maint flush symbol-cache'
command, make old command an alias.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
(Maintenance Commands): Document 'maint flush register-cache'.
gdb/testsuite/ChangeLog:
* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
commands.
* gdb.base/killed-outside.exp: Likewise.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.perf/gmonster-null-lookup.py: Likewise.
* gdb.perf/gmonster-print-cerr.py: Likewise.
* gdb.perf/gmonster-ptype-string.py: Likewise.
* gdb.python/py-unwind.exp: Likewise.
|
|
gdb/ChangeLog:
* NEWS: Add entry documenting support for DWARF-based fixed
point types.
|
|
gdb/ChangeLog:
* NEWS: Document that building GDB now requires GMP.
|
|
This commit brings array slice support to GDB.
WARNING: This patch contains a rather big hack which is limited to
Fortran arrays, this can be seen in gdbtypes.c and f-lang.c. More
details on this below.
This patch rewrites two areas of GDB's Fortran support, the code to
extract an array slice, and the code to print an array.
After this commit a user can, from the GDB prompt, ask for a slice of
a Fortran array and should get the correct result back. Slices can
(optionally) have the lower bound, upper bound, and a stride
specified. Slices can also have a negative stride.
Fortran has the concept of repacking array slices. Within a compiled
Fortran program if a user passes a non-contiguous array slice to a
function then the compiler may have to repack the slice, this involves
copying the elements of the slice to a new area of memory before the
call, and copying the elements back to the original array after the
call. Whether repacking occurs will depend on which version of
Fortran is being used, and what type of function is being called.
This commit adds support for both packed, and unpacked array slicing,
with the default being unpacked.
With an unpacked array slice, when the user asks for a slice of an
array GDB creates a new type that accurately describes where the
elements of the slice can be found within the original array, a
value of this type is then returned to the user. The address of an
element within the slice will be equal to the address of an element
within the original array.
A user can choose to select packed array slices instead using:
(gdb) set fortran repack-array-slices on|off
(gdb) show fortran repack-array-slices
With packed array slices GDB creates a new type that reflects how the
elements of the slice would look if they were laid out in contiguous
memory, allocates a value of this type, and then fetches the elements
from the original array and places then into the contents buffer of
the new value.
One benefit of using packed slices over unpacked slices is the memory
usage, taking a small slice of N elements from a large array will
require (in GDB) N * ELEMENT_SIZE bytes of memory, while an unpacked
array will also include all of the "padding" between the
non-contiguous elements. There are new tests added that highlight
this difference.
There is also a new debugging flag added with this commit that
introduces these commands:
(gdb) set debug fortran-array-slicing on|off
(gdb) show debug fortran-array-slicing
This prints information about how the array slices are being built.
As both the repacking, and the array printing requires GDB to walk
through a multi-dimensional Fortran array visiting each element, this
commit adds the file f-array-walk.h, which introduces some
infrastructure to support this process. This means the array printing
code in f-valprint.c is significantly reduced.
The only slight issue with this commit is the "rather big hack" that I
mentioned above. This hack allows us to handle one specific case,
array slices with negative strides. This is something that I don't
believe the current GDB value contents model will allow us to
correctly handle, and rather than rewrite the value contents code
right now, I'm hoping to slip this hack in as a work around.
The problem is that, as I see it, the current value contents model
assumes that an object base address will be the lowest address within
that object, and that the contents of the object start at this base
address and occupy the TYPE_LENGTH bytes after that.
( We do have the embedded_offset, which is used for C++ sub-classes,
such that an object can start at some offset from the content buffer,
however, the assumption that the object then occupies the next
TYPE_LENGTH bytes is still true within GDB. )
The problem is that Fortran arrays with a negative stride don't follow
this pattern. In this case the base address of the object points to
the element with the highest address, the contents of the array then
start at some offset _before_ the base address, and proceed for one
element _past_ the base address.
As the stride for such an array would be negative then, in theory the
TYPE_LENGTH for this type would also be negative. However, in many
places a value in GDB will degrade to a pointer + length, and the
length almost always comes from the TYPE_LENGTH.
It is my belief that in order to correctly model this case the value
content handling of GDB will need to be reworked to split apart the
value's content buffer (which is a block of memory with a length), and
the object's in memory base address and length, which could be
negative.
Things are further complicated because arrays with negative strides
like this are always dynamic types. When a value has a dynamic type
and its base address needs resolving we actually store the address of
the object within the resolved dynamic type, not within the value
object itself.
In short I don't currently see an easy path to cleanly support this
situation within GDB. And so I believe that leaves two options,
either add a work around, or catch cases where the user tries to make
use of a negative stride, or access an array with a negative stride,
and throw an error.
This patch currently goes with adding a work around, which is that
when we resolve a dynamic Fortran array type, if the stride is
negative, then we adjust the base address to point to the lowest
address required by the array. The printing and slicing code is aware
of this adjustment and will correctly slice and print Fortran arrays.
Where this hack will show through to the user is if they ask for the
address of an array in their program with a negative array stride, the
address they get from GDB will not match the address that would be
computed within the Fortran program.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add f-array-walker.h.
* NEWS: Mention new options.
* f-array-walker.h: New file.
* f-lang.c: Include 'gdbcmd.h' and 'f-array-walker.h'.
(repack_array_slices): New static global.
(show_repack_array_slices): New function.
(fortran_array_slicing_debug): New static global.
(show_fortran_array_slicing_debug): New function.
(value_f90_subarray): Delete.
(skip_undetermined_arglist): Delete.
(class fortran_array_repacker_base_impl): New class.
(class fortran_lazy_array_repacker_impl): New class.
(class fortran_array_repacker_impl): New class.
(fortran_value_subarray): Complete rewrite.
(set_fortran_list): New static global.
(show_fortran_list): Likewise.
(_initialize_f_language): Register new commands.
(fortran_adjust_dynamic_array_base_address_hack): New function.
* f-lang.h (fortran_adjust_dynamic_array_base_address_hack):
Declare.
* f-valprint.c: Include 'f-array-walker.h'.
(class fortran_array_printer_impl): New class.
(f77_print_array_1): Delete.
(f77_print_array): Delete.
(fortran_print_array): New.
(f_value_print_inner): Update to call fortran_print_array.
* gdbtypes.c: Include 'f-lang.h'.
(resolve_dynamic_type_internal): Call
fortran_adjust_dynamic_array_base_address_hack.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices-bad.exp: New file.
* gdb.fortran/array-slices-bad.f90: New file.
* gdb.fortran/array-slices-sub-slices.exp: New file.
* gdb.fortran/array-slices-sub-slices.f90: New file.
* gdb.fortran/array-slices.exp: Rewrite tests.
* gdb.fortran/array-slices.f90: Rewrite tests.
* gdb.fortran/vla-sizeof.exp: Correct expected results.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Document 'set/show debug
fortran-array-slicing'.
(Special Fortran Commands): Document 'set/show fortran
repack-array-slices'.
|
|
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.
|
|
gdb/ChangeLog:
* NEWS: Mention ARC support in GDBserver.
|
|
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
|
|
gdb/ChangeLog:
2020-08-21 Jon Turney <jon.turney@dronecode.org.uk>
* NEWS: Mention x86_64 Cygwin core file support.
|
|
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.
|
|
gdb/ChangeLog:
* NEWS: Create a new section for the next release branch.
Rename the section of the current branch, now that it has
been cut.
|
|
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.
|
|
Simon noticed that I managed to put this in the "Changes in GDB 9"
section by mistake instead of in the "Changes since GDB 9" section
where it belongs.
gdb/ChangeLog:
* NEWS: Move "Multi-target debugging support" item to the
"Changes since GDB 9" section.
|
|
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.
|
|
gdb/ChangeLog:
* NEWS (New commands): Mention new command
"maintenance print core-file-backed-mappings".
gdb/doc/ChangeLog:
* gdb.texinfo (Maintenance Commands): Add documentation for
new command "maintenance print core-file-backed-mappings".
|
|
gdb/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t'
and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax',
which are deprecated in Guile 3.0.
* configure.ac (try_guile_versions): Add "guile-3.0".
* configure (try_guile_versions): Regenerate.
* NEWS: Update entry.
gdb/testsuite/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* gdb.guile/source2.scm: Add #f first argument to 'format'.
* gdb.guile/types-module.exp: Remove "ERROR:" from
regexps since Guile 3.0 no longer prints that.
gdb/doc/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* doc/guile.texi (Guile Introduction): Mention Guile 3.0.
Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679
|
|
This primarily updates code that uses the I/O port API of Guile.
gdb/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
Doug Evans <dje@google.com>
PR gdb/21104
* guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro.
(ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if
USING_GUILE_BEFORE_2_2.
(stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]:
Change type to 'scm_t_port_type *'.
(natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable.
(ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream'
parameter and honor it. Update callers.
(ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function.
(ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New
functions.
(ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if
USING_GUILE_BEFORE_2_2.
(ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use
'ioscm_read_from_port'. Call 'scm_set_port_read_wait_fd'.
(ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function.
(gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP'
and 'SCM_PORT_TYPE'.
(gdbscm_memory_port_end_input, gdbscm_memory_port_seek)
(ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2.
(gdbscm_memory_port_read, gdbscm_memory_port_write)
(gdbscm_memory_port_seek, gdbscm_memory_port_close)
[!USING_GUILE_BEFORE_2_2]: New functions.
(gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'.
(ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use
'gdbscm_memory_port_read'.
Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and
'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2.
(gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New
function.
(ioscm_init_memory_port): Remove.
(ioscm_init_memory_port_stream): New function
(ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New
function.
(gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_read_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
(gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_write_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
* configure.ac (try_guile_versions): Add "guile-2.2".
* configure: Regenerate.
* NEWS: Add entry.
gdb/testsuite/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax
error regexp to match on Guile 2.2.
gdb/doc/ChangeLog
2020-06-28 Ludovic Courtès <ludo@gnu.org>
* guile.texi (Memory Ports in Guile): Mark
'memory-port-read-buffer-size',
'set-memory-port-read-buffer-size!',
'memory-port-write-buffer-size',
'set-memory-port-read-buffer-size!' as deprecated.
* doc/guile.texi (Guile Introduction): Clarify which Guile
versions are supported.
Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31
|
|
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.
|
|
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/ChangeLog:
* NEWS: Mention removed GDBserver host support.
Change-Id: Ib9e212e525d12ac7f3f9b5c056adc5bf9c4d52cd
|
|
Fix a few typos in gdb/NEWS.
gdb/ChangeLog:
2020-06-05 Tom de Vries <tdevries@suse.de>
* NEWS: Fix typos.
|
|
This reverts commit eca1f90cf47a2edc1a1cd22e12c6c0f3b900654e. Several
changes were requested, and it seemed simplest to revert it.
gdb/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
Revert commit eca1f90c:
* NEWS: Remove entry for completion styling.
* completer.c (_rl_completion_prefix_display_length): Move
declaration later.
(gdb_fnprint): Revert.
(gdb_display_match_list_1): Likewise.
* cli/cli-style.c (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Remove.
(_initialize_cli_style): Revert.
* cli/cli-style.h (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Don't
declare.
gdb/doc/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Output Styling): Don't mention completion styling.
(Editing): Don't mention readline completion styling.
gdb/testsuite/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Remove completion styling test.
* lib/gdb-utils.exp (style): Remove completion styles.
|
|
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 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.
|
|
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.
|
|
For WOW64 processes, the Wow64* variants of SuspendThread,
GetThreadContext, SetThreadContext, and GetThreadSelectorEntry have to
be used instead.
And instead of EnumProcessModules, EnumProcessModulesEx with
LIST_MODULES_32BIT is necessary.
gdb/ChangeLog:
2020-03-04 Hannes Domani <ssbssa@yahoo.de>
* NEWS: Mention support for WOW64 processes.
* amd64-windows-nat.c (amd64_mappings): Rename and remove static.
(amd64_windows_segment_register_p): Remove static.
(_initialize_amd64_windows_nat): Update.
* configure.nat <windows> (NATDEPFILES): Add i386-windows-nat.o.
* i386-windows-nat.c (context_offset): Update.
(i386_mappings): Rename and remove static.
(i386_windows_segment_register_p): Remove static.
(_initialize_i386_windows_nat): Update.
* windows-nat.c (STATUS_WX86_BREAKPOINT): New macro.
(STATUS_WX86_SINGLE_STEP): New macro.
(EnumProcessModulesEx): New macro.
(Wow64SuspendThread): New macro.
(Wow64GetThreadContext): New macro.
(Wow64SetThreadContext): New macro.
(Wow64GetThreadSelectorEntry): New macro.
(windows_set_context_register_offsets): Add static.
(windows_set_segment_register_p): Likewise.
(windows_add_thread): Adapt for WOW64 processes.
(windows_fetch_one_register): Likewise.
(windows_nat_target::fetch_registers): Likewise.
(windows_store_one_register): Likewise.
(display_selector): Likewise.
(display_selectors): Likewise.
(handle_exception): Likewise.
(windows_continue): Likewise.
(windows_nat_target::resume): Likewise.
(windows_add_all_dlls): Likewise.
(do_initial_windows_stuff): Likewise.
(windows_nat_target::attach): Likewise.
(windows_get_exec_module_filename): Likewise.
(windows_nat_target::create_inferior): Likewise.
(windows_xfer_siginfo): Likewise.
(_initialize_loadable): Initialize Wow64SuspendThread,
Wow64GetThreadContext, Wow64SetThreadContext,
Wow64GetThreadSelectorEntry and EnumProcessModulesEx.
* windows-nat.h (windows_set_context_register_offsets):
Remove declaration.
(windows_set_segment_register_p): Likewise.
(i386_windows_segment_register_p): Add declaration.
(amd64_windows_segment_register_p): Likewise.
|
|
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
|
