Now that libiberty includes htab_eq_string, we can remove the
identical function from gdb.
gdb/ChangeLog
2021-05-07 Tom Tromey <tom@tromey.com>
* breakpoint.c (ambiguous_names_p): Use htab_eq_string.
* utils.c (streq_hash): Remove.
* utils.h (streq_hash): Don't declare.
* completer.c (completion_tracker::discard_completions): Update
comment.
* ada-lang.c (_initialize_ada_language): Use htab_eq_string.
Re-format all Python files using black [1] version 21.4b0. The goal is
that from now on, we keep all Python files formatted using black. And
that we never have to discuss formatting during review (for these files
at least) ever again.
One change is needed in gdb.python/py-prettyprint.exp, because it
matches the string representation of an exception, which shows source
code. So the change in formatting must be replicated in the expected
regexp.
To document our usage of black I plan on adding this to the "GDB Python
Coding Standards" wiki page [2]:
--8<--
All Python source files under the `gdb/` directory must be formatted
using black version 21.4b0.
This specific version can be installed using:
$ pip3 install 'black == 21.4b0'
All you need to do to re-format files is run `black <file/directory>`,
and black will re-format any Python file it finds in there. It runs
quite fast, so the simplest is to do:
$ black gdb/
from the top-level.
If you notice that black produces changes unrelated to your patch, it's
probably because someone forgot to run it before you. In this case,
don't include unrelated hunks in your patch. Push an obvious patch
fixing the formatting and rebase your work on top of that.
-->8--
Once this is merged, I plan on setting a up an `ignoreRevsFile`
config so that git-blame ignores this commit, as described here:
https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame
I also plan on working on a git commit hook (checked in the repo) to
automatically check the formatting of the Python files on commit.
[1] https://pypi.org/project/black/
[2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
gdb/ChangeLog:
* Re-format all Python files using black.
gdb/testsuite/ChangeLog:
* Re-format all Python files using black.
* gdb.python/py-prettyprint.exp (run_lang_tests): Adjust.
Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
In code dealing with commands, there's a pattern repeated a few times of
calling lookup_cmd with some speficic arguments and then using strcmp
on the returned command to check for an exact match.
As a later patch would add a few more similar lines of code, this patch
adds a new lookup_cmd_exact function which simplify this use case.
gdb/ChangeLog:
* cli/cli-decode.c (lookup_cmd_exact): Add.
* cli/cli-script.c (do_define_command): Use lookup_cmd_exact.
(define_prefix_command): Ditto.
* command.h: Add lookup_cmd_exact.
With the test-case attached in PR26327, gdb aborts:
...
$ gdb -q -batch 447.dealII -ex "b main"
Aborted (core dumped)
...
when running out of stack due to infinite recursion:
...
#8 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x35e4b40)
at src/gdb/dwarf2/read.c:700
#9 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x22ee2c0)
at src/gdb/dwarf2/read.c:700
#10 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x35e4b40)
at src/gdb/dwarf2/read.c:700
#11 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x22ee2c0)
at src/gdb/dwarf2/read.c:700
...
We're recursing in this code in dwarf2_cu::get_builder():
...
/* Otherwise, search ancestors for a valid builder. */
if (ancestor != nullptr)
return ancestor->get_builder ();
...
due to the fact that the ancestor chain is a cycle.
Higher up in the call stack, we find some code that is responsible for
triggering this, in new_symbol:
...
case DW_TAG_formal_parameter:
{
/* If we are inside a function, mark this as an argument. If
not, we might be looking at an argument to an inlined function
when we do not have enough information to show inlined frames;
pretend it's a local variable in that case so that the user can
still see it. */
struct context_stack *curr
= cu->get_builder ()->get_current_context_stack ();
if (curr != nullptr && curr->name != nullptr)
SYMBOL_IS_ARGUMENT (sym) = 1;
...
This is code that was added to support pre-4.1 gcc, to be able to show
arguments of inlined functions as locals, in the absense of sufficiently
correct debug information.
Removing this code (that is, doing SYMBOL_IS_ARGUMENT (sym) = 1
unconditially), fixes the crash. The ancestor variable also seems to have
been added specifically to deal with fallout from this code, so remove that as
well.
Tested on x86_64-linux:
- openSUSE Leap 15.2 with gcc 7.5.0, and
- openSUSE Tumbleweed with gcc 10.3.0.
gdb/ChangeLog:
2021-05-07 Tom de Vries <tdevries@suse.de>
PR symtab/26327
* dwarf2/read.c (struct dwarf2_cu): Remove ancestor.
(dwarf2_cu::get_builder): Remove ancestor-related code.
(new_symbol): Remove code supporting pre-4.1 gcc that show arguments
of inlined functions as locals.
(follow_die_offset, follow_die_sig_1): Remove setting of ancestor.
gdb/doc/ChangeLog:
2021-05-07 Tom de Vries <tdevries@suse.de>
PR symtab/26327
* gdb.texinfo (Inline Functions): Update.
Change gdbscm_safe_source_script to return a
gdb::unique_xmalloc_ptr<char> instead of a raw char*. Update the
users of this function.
There should be no user visible change after this commit.
gdb/ChangeLog:
* guile/guile-internal.h (gdbscm_safe_source_script): Change
function return type.
* guile/guile.c (gdbscm_source_script): Update to handle change in
gdbscm_safe_source_script.
* guile/scm-objfile.c (gdbscm_source_objfile_script): Likewise.
* guile/scm-safe-call.c (gdbscm_safe_source_script): Change return
type.
Currently, using the guile API, if a user tries to print a breakpoint
object that represents a watchpoint, then GDB will crash. For
example:
(gdb) guile (use-modules (gdb))
(gdb) guile (define wp1 (make-breakpoint "some_variable" #:type BP_WATCHPOINT #:wp-class WP_WRITE))
(gdb) guile (register-breakpoint! wp1)
(gdb) guile (display wp1) (newline)
Aborted (core dumped)
This turns out to be because GDB calls event_location_to_string on the
breakpoints location, and watchpoint breakpoints don't have a
location.
This commit resolves the crash by just skipping the printing of the
location if the breakpoint doesn't have one.
Potentially, we could improve on this by printing details about what
the watchpoint is watching, however, I'm considering this a possible
future enhancement, this commit focuses just on having GDB not crash.
gdb/ChangeLog:
* guile/scm-breakpoint.c (bpscm_print_breakpoint_smob): Only print
breakpoint locations when the breakpoint actually has a location.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_watchpoints): Print the
watchpoint object before and after registering it with GDB.
Convert gdb.guile/scm-breakpoint.exp to use proc_with_prefix instead
of using nested with_test_prefix calls. Allows a level of indentation
to be removed from most of the test procs.
There were two procs that didn't use with_test_prefix, but I converted
them to be proc_with_prefix anyway, for consistency.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Convert to
'proc_with_prefix', remove use of 'with_test_prefix', and
reindent.
(test_bkpt_deletion): Likewise.
(test_bkpt_cond_and_cmds): Likewise.
(test_bkpt_invisible): Likewise.
(test_watchpoints): Likewise.
(test_bkpt_internal): Likewise.
(test_bkpt_eval_funcs): Likewise.
(test_bkpt_registration): Likewise.
(test_bkpt_address): Convert to 'proc_with_prefix'.
(test_bkpt_probe): Likewise.
Extend some test names to avoid duplicates.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Extend test
names to avoid duplicates.
(test_bkpt_cond_and_cmds): Likewise.
(test_bkpt_eval_funcs): Likewise.
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.
When running test-case gdb.threads/detach-step-over.exp with target board
readnow, I run into:
...
Reading symbols from /lib64/libc.so.6...^M
Reading symbols from \
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
Expanding full symbols from \
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
FAIL: gdb.threads/detach-step-over.exp: \
breakpoint-condition-evaluation=host: target-non-stop=on: non-stop=on: \
displaced=off: iter 2: attach (timeout)
...
Fix this by doing exp_continue when encountering the "Reading symbols" or
"Expanding full symbols" lines.
This is still fragile and times out with a higher load, similated f.i. by
stress -c 5. Fix that by using a timeout factor of 2.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-05 Tom de Vries <tdevries@suse.de>
* gdb.threads/detach-step-over.exp: Do exp_continue when encountering
"Reading symbols" or "Expanding full symbols" lines. Using timeout
factor of 2 for attach.
When running test-case gdb.threads/fork-plus-threads.exp with target board
readnow, I run into:
...
[LWP 9362 exited]^M
[New LWP 9365]^M
[New LWP 9363]^M
[New LWP 9364]^M
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
inferior 1 exited (timeout)
...
There is code in the test-case to prevent timeouts with readnow:
...
-re "Thread \[^\r\n\]+ exited" {
# Avoid timeout with check-read1
exp_continue
}
-re "New Thread \[^\r\n\]+" {
# Avoid timeout with check-read1
exp_continue
}
...
but this doesn't trigger because we get LWP rather than Thread.
Fix this by making these regexps accept LWP as well.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-05 Tom de Vries <tdevries@suse.de>
* gdb.threads/fork-plus-threads.exp: Handle "New LWP <n>" and
"LWP <n> exited" messages.
I noticed two errors in the Type.fields documentation:
1. It is possible to call `fields` on an array type, in which case it
returns one field representing the array's range. It is not
mentioned.
2. When calling `fields` on a type that doesn't have fields (by nature,
like an int), GDB raises a TypeError. It does not return an empty
sequence, as currently documented.
Fix these, and change the text into a bullet list. I find it easier to
read than one big paragraph.
The first issue is already tested in gdb.python/py-type.exp, but the
second one doesn't seem tested. Add a test in gdb.python/py-type.exp
for it.
gdb/doc/ChangeLog:
* python.texi (Types In Python): Re-organize Type.fields doc.
Mention handling of array types. Correct doc for when calling
the method on another type.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp (test_fields): Test calling fields on
an int type.
Change-Id: I11c688177504cb070b81a4446ac91dec50b56a22
The `Type.range ()` tests in gdb.python/flexible-array-member.exp pass
when the test is compiled with gcc 9 or later, but not with gcc 8 or
earlier:
$ make check TESTS="gdb.python/flexible-array-member.exp" RUNTESTFLAGS="CC_FOR_TARGET='gcc-8'"
python print(zs['items'].type.range())^M
(0, 0)^M
(gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zs['items'].type.range())
python print(zso['items'].type.range())^M
(0, 0)^M
(gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zso['items'].type.range())
The value that we get for the upper bound of a flexible array member
declared with a "0" size is 0 with gcc <= 8 and is -1 for gcc >= 9.
This is due to different debug info. For this member, gcc 8 does:
0x000000d5: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000034 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000e4)
0x000000de: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int")
For the same type, gcc 9 does:
0x000000d5: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000034 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000e5)
0x000000de: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int")
DW_AT_count [DW_FORM_data1] (0x00)
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like. But for now, just change the test to accept the two
values, to get rid of the failure and make the test in sync
I also realized (by looking at the py-type.exp test) that calling the
fields method on an array type yields one field representing the "index"
of the array. The type of that field is of type range
(gdb.TYPE_CODE_RANGE). When calling `.range()` on that range type, it
yields the same range tuple as when calling `.range()` on the array type
itself. For completeness, add some tests to access the range tuple
through that range type as well.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Adjust expected range
value for member declared with 0 size. Test accessing range
tuple through range type.
Change-Id: Ie4e06d99fe9315527f04577888f48284d649ca4c
Since gdb commit 880ae75a2b7 "gdb delay guile initialization until
gdbscm_finish_initialization" I'm running into:
...
(gdb) print My_Var > 10.0^M
free(): invalid pointer^M
ERROR: GDB process no longer exists
GDB process exited with wait status 5995 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.ada/fixed_cmp.exp: gnat_encodings=all: print My_Var > 10.0
...
The problem is that both gdb and libguile try to set the libgmp memory functions,
and since the gdb commit the ones from libguile are effective, which results
in gdb freeing some memory in a way that is not compatible with the way that
memory was actually allocated.
The fact that libguile tries to set the libgmp memory functions is a bug which
should be fixed starting version v3.0.6.
Meanwhile, work around this in gdb by not allowing libguile to set the libgomp
memory functions.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-04 Tom de Vries <tdevries@suse.de>
PR guile/27806
* guile/guile.c (gdbscm_initialize): Don't let guile change libgmp
memory functions.
The test gdb.python/py-startup-opt.exp checks the behaviour of GDB's:
set python dont-write-bytecode on
This flag (when on) stops Python creating .pyc files. The test first
checks that .pyc files will be created, then turns this option on and
checks .pyc files will not be created.
However, if the user has PYTHONDONTWRITEBYTECODE set in their
environment then this will prevent Python from creating .pyc files, as
such the first test, that .pyc files are being created, currently
fails.
We could unset PYTHONDONTWRITEBYTECODE, however, until Python 3.8
there is no way to control where Python writes the .pyc files. As the
GDB developer clearly doesn't want .pyc files created in their
file-system it feels wrong to silently unset this environment
variable.
My proposal then, is that we just spot when this environment variable
is set and adjust the expected results. My hope is that across all
GDB developers some will be running with PYTHONDONTWRITEBYTECODE
unset, so this feature will be fully tested at least some of the time.
gdb/testsuite/ChangeLog:
PR testsuite/27788
* gdb.python/py-startup-opt.exp (test_python_settings): Change the
expected results when environment variable PYTHONDONTWRITEBYTECODE
is set.
Currently, the DWARF reader has a separate pass to read type units --
create_all_type_units. While working on other patches, I discovered
that this caused DWARF 5 type units to be read twice, once by
create_all_comp_units and once by create_all_type_units.
There's no need any more (if there ever was) to treat type units
differently from CUs. So, this patch removes create_all_type_units
and unifies the code paths.
Note that the DWO code still has a second pass. I haven't looked into
this code yet; perhaps it can also be simplified.
Regression tested using the debug-types board file on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_initialize_objfile): Update.
(add_signatured_type_cu_to_table): Remove.
(create_debug_type_hash_table): Assume dwo_file is non-null.
(create_debug_types_hash_table): Update comment.
(create_all_type_units): Remove.
(sort_tu_by_abbrev_offset): Update comment.
(build_type_psymtabs): Rename from build_type_psymtabs_1.
(build_type_psymtabs): Remove.
(process_skeletonless_type_unit, dwarf2_build_psymtabs_hard):
Update.
(read_comp_units_from_section): Add types_htab, section_kind
parameters.
(create_all_comp_units): Read type units.
I don't think there is any deep reason to separate CUs and TUs in
dwarf2_per_bfd. This patch removes all_type_units and unifies these
two containers. Some minor tweaks are needed to the index writers,
because both forms of index keep CUs and TUs separate;
Regression tested on x86-63 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct tu_stats) <nr_tus>: New member.
(struct dwarf2_per_bfd) <get_cutu, get_tu>: Remove
<get_cu>: Now inline.
<all_type_units>: Remove.
* dwarf2/read.c (dwarf2_per_bfd::~dwarf2_per_bfd): Update.
(dwarf2_per_bfd::get_cutu, dwarf2_per_bfd::get_cu)
(dwarf2_per_bfd::get_tu): Remove.
(dwarf2_per_bfd::allocate_signatured_type): Update nr_tus.
(create_signatured_type_table_from_index)
(create_signatured_type_table_from_debug_names)
(dw2_symtab_iter_next, dwarf2_base_index_functions::print_stats)
(dwarf2_base_index_functions::expand_all_symtabs)
(dw2_expand_marked_cus, dw_expand_symtabs_matching_file_matcher)
(dwarf2_base_index_functions::map_symbol_filenames)
(dw2_debug_names_iterator::next, dwarf2_initialize_objfile)
(add_signatured_type_cu_to_table, create_all_type_units)
(add_type_unit, build_type_psymtabs_1, print_tu_stats)
(create_all_comp_units): Update.
* dwarf2/index-write.c (check_dwarf64_offsets, write_gdbindex)
(write_debug_names): Update.
In a patch series I am working on, I'd like to have a non-POD member
in dwarf2_per_cu_data. This currently can't be done because
dwarf2_per_cu_data is allocated on an obstack and initialized with
memset.
This patch changes the DWARF reader to allocate objects of this type
with 'new'. The various "subclasses" of this type (signatured_type in
particular) are now changed to derive from dwarf2_per_cu_data, and
also use 'new' for allocation.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_bfd) <allocate_per_cu,
allocate_signatured_type>: Change return type.
<all_comp_units, all_type_units>: Hold unique pointers.
(struct dwarf2_per_cu_data): Add constructor and initializers.
(struct signatured_type): Derive from dwarf2_per_cu_data.
* dwarf2/read.c (type_unit_group): Derive from
dwarf2_per_cu_data.
(dwarf2_per_bfd::get_cutu, dwarf2_per_bfd::get_cu)
(dwarf2_per_bfd::get_tu)
(dwarf2_per_bfd::allocate_signatured_type)
(dwarf2_per_bfd::allocate_signatured_type)
(create_cu_from_index_list, create_cus_from_index_list)
(create_signatured_type_table_from_index)
(create_signatured_type_table_from_debug_names)
(create_addrmap_from_aranges)
(dwarf2_base_index_functions::find_last_source_symtab)
(dw_expand_symtabs_matching_file_matcher)
(dwarf2_gdb_index::expand_symtabs_matching)
(dwarf2_base_index_functions::map_symbol_filenames)
(create_cus_from_debug_names_list)
(dw2_debug_names_iterator::next)
(dwarf2_debug_names_index::expand_symtabs_matching)
(create_debug_type_hash_table, add_type_unit)
(fill_in_sig_entry_from_dwo_entry, lookup_dwo_signatured_type):
Update.
(allocate_type_unit_groups_table): Use delete.
(create_type_unit_group): Change return type. Use new.
(get_type_unit_group, build_type_psymtabs_1)
(build_type_psymtab_dependencies)
(process_skeletonless_type_unit, set_partial_user)
(dwarf2_build_psymtabs_hard, read_comp_units_from_section)
(create_cus_hash_table, queue_and_load_dwo_tu, follow_die_sig_1)
(read_signatured_type): Update.
(dwarf2_find_containing_comp_unit): Change type of
'all_comp_units'.
(run_test): Update.
(dwarf2_per_bfd::allocate_per_cu)
(dwarf2_per_bfd::allocate_signatured_type): Change return type.
Use new.
(add_signatured_type_cu_to_table): Update.
* dwarf2/index-write.c (write_one_signatured_type)
(check_dwarf64_offsets, psyms_seen_size, write_gdbindex)
(write_debug_names): Update.
The only callers of get_image_name are nat/windows-nat.c, so make it
static.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (get_image_name): Don't declare.
* nat/windows-nat.c (get_image_name): Now static.
This moves the new DLL-loading code into nat/windows-nat.c, and
changes both gdb and gdbserver to use the shared code. One
client-provided callback, handle_load_dll, is changed to allow the
code to be shared. This callback was actually never called from
nat/windows-nat.c; maybe I had planned to share more here and then
didn't finish... I'm not sure.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll): Update.
(windows_nat_target::get_windows_debug_event): Call
dll_loaded_event.
(windows_add_all_dlls, windows_add_dll): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_load_dll): Change parameters.
(dll_loaded_event, windows_add_all_dlls): Declare.
* nat/windows-nat.c (windows_add_dll, windows_add_all_dlls): Move
from windows-nat.c.
(dll_loaded_event): New function.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (do_initial_child_stuff): Update.
(windows_nat::handle_load_dll): Rename from win32_add_one_solib.
Change parameter type.
(win32_add_dll, win32_add_all_dlls)
(windows_nat::handle_load_dll): Remove.
(get_child_debug_event): Call dll_loaded_event.
This changes gdbserver to use the function indirection code that was
just moved into nat/windows-nat.[ch]. One additional function is used
by gdbserver that was not used by gdb.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (GenerateConsoleCtrlEvent): New define.
(GenerateConsoleCtrlEvent_ftype, GenerateConsoleCtrlEvent):
Declare.
* nat/windows-nat.c (GenerateConsoleCtrlEvent): Define.
(initialize_loadable): Initialize GenerateConsoleCtrlEvent.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (GETPROCADDRESS): Remove.
(winapi_DebugActiveProcessStop, winapi_DebugSetProcessKillOnExit)
(winapi_DebugBreakProcess, winapi_GenerateConsoleCtrlEvent)
(winapi_Wow64SetThreadContext, win32_Wow64GetThreadContext)
(win32_Wow64SetThreadContext): Remove.
(win32_set_thread_context, do_initial_child_stuff)
(win32_process_target::attach, win32_process_target::detach):
Update.
(winapi_EnumProcessModules, winapi_EnumProcessModulesEx)
(winapi_GetModuleInformation, winapi_GetModuleInformationA):
Remove.
(win32_EnumProcessModules, win32_EnumProcessModulesEx)
(win32_GetModuleInformation, win32_GetModuleInformationA):
Remove.
(load_psapi): Remove.
(win32_add_dll, win32_process_target::request_interrupt): Update.
(initialize_low): Call initialize_loadable.
gdb and gdbserver both look for functions in some Windows DLLs at
runtime. This patch moves this code out of gdb and into
nat/windows-nat, so it can be shared by both programs.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c: Move code to nat/windows-nat.[ch].
(_initialize_windows_nat): Call initialize_loadable.
* nat/windows-nat.h (AdjustTokenPrivileges)
(DebugActiveProcessStop, DebugBreakProcess)
(DebugSetProcessKillOnExit, EnumProcessModules)
(EnumProcessModulesEx, GetModuleInformation)
(GetModuleFileNameExA, GetModuleFileNameExW)
(LookupPrivilegeValueA, OpenProcessToken, GetConsoleFontSize)
(GetCurrentConsoleFont, Wow64SuspendThread)
(Wow64GetThreadContext, Wow64SetThreadContext)
(Wow64GetThreadSelectorEntry): Move from windows-nat.c.
(AdjustTokenPrivileges_ftype)
(DebugActiveProcessStop_ftype, DebugBreakProcess_ftype)
(DebugSetProcessKillOnExit_ftype, EnumProcessModules_ftype)
(EnumProcessModulesEx_ftype, GetModuleInformation_ftype)
(GetModuleFileNameExA_ftype, GetModuleFileNameExW_ftype)
(LookupPrivilegeValueA_ftype, OpenProcessToken_ftype)
(GetConsoleFontSize_ftype)
(GetCurrentConsoleFont_ftype, Wow64SuspendThread_ftype)
(Wow64GetThreadContext_ftype, Wow64SetThreadContext_ftype)
(Wow64GetThreadSelectorEntry_ftype): Likewise.
(initialize_loadable): Declare.
* nat/windows-nat.c (AdjustTokenPrivileges)
(DebugActiveProcessStop, DebugBreakProcess)
(DebugSetProcessKillOnExit, EnumProcessModules)
(EnumProcessModulesEx, GetModuleInformation, GetModuleFileNameExA)
(GetModuleFileNameExW, LookupPrivilegeValueA, OpenProcessToken)
(GetCurrentConsoleFont, GetConsoleFontSize, Wow64SuspendThread)
(Wow64GetThreadContext, Wow64SetThreadContext)
(Wow64GetThreadSelectorEntry): Define.
(bad, bad_GetCurrentConsoleFont, bad_GetConsoleFontSize): Move
from windows-nat.c.
(initialize_loadable): Likewise, and rename.
windows-nat.c defines a number of replacement functions that simply
return zero. This patch removes these in favor of a couple of
template functions.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (bad_GetModuleFileNameEx): Remove define.
(bad_DebugActiveProcessStop, bad_DebugBreakProcess)
(bad_DebugSetProcessKillOnExit, bad_EnumProcessModules)
(bad_GetModuleFileNameExW, bad_GetModuleFileNameExA)
(bad_GetModuleInformation, bad_OpenProcessToken): Remove.
(bad): New template functions.
(_initialize_loadable): Update.
Running the AdaCore internal test suite with -fgnat-encodings=minimal
found a gdb crash. The bug is that GDB ends up with a typedef in
ada_index_type, resulting in a NULL dereference.
This crash can be reproduced using GCC 11 with the included test case.
Tested on x86-64 Fedora 32. Because this is Ada-specific, and was
already reviewed by Joel, I am going to check it in.
2021-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_index_type): Use ada_check_typedef.
gdb/testsuite/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* gdb.ada/enum_idx_packed/pck.ads (My_Enum, My_Array_Type)
(Confused_Array): New types.
* gdb.ada/enum_idx_packed/foo.adb (Confused_Array): New variable.
* gdb.ada/enum_idx_packed.exp: Add new tests.
Once in a while, I run into this timeout:
...
FAIL: gdb.mi/mi-sym-info.exp: List all variables from debug information \
only (timeout)
...
I can make the timeout reproducible by setting timeout to 8s (instead of the
default 10s) for the duration of that test.
Make the test-case more stable by fixing all timeouts caused by setting
timeout to 5, either by adding with_timeout_factor, or increasing its factor.
Tested on x86_64-linux. Also tested in parallel with stress -c 5, to simulate
a busy system in another way.
gdb/testsuite/ChangeLog:
2021-04-30 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Add with_timeout_factor, and increase
existing timeout factors.
Since commit 2d61316c32a "[gdb/testsuite] Fix buffer full errors in
gdb.mi/mi-sym-info.exp", we have a duplicate test name:
...
Running src/gdb/testsuite/gdb.mi/mi-sym-info.exp ...
DUPLICATE: gdb.mi/mi-sym-info.exp: List all variables
...
This is caused by a copy-paste accident: the idea was to copy the test, edit
it, and then remove the old test, but I forgot to remove the old one.
Remove it now.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-30 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Remove duplicate test.
Since commit 6d5702a5eb3 "Fix test case gdb.base/valgrind-bt.exp" I run into:
...
FAIL: gdb.base/valgrind-infcall-2.exp: target remote for vgdb (timeout)
FAIL: gdb.base/valgrind-infcall-2.exp: monitor v.set gdb_output (timeout)
...
The commit adds this line in proc vgdb_start:
...
set vgdbcmd "set remotetimeout 3"
...
which has no effect given that the value of var vgdbcmd is not used before
it's overwritten. We can fix this by doing instead:
...
set_remotetimeout 3
...
The FAIL I'm observing is fixed by increasing the remotetimeout value to 4.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-29 Tom de Vries <tdevries@suse.de>
PR testsuite/27786
* lib/valgrind.exp (vgdb_start): Use set_remotetimeout. Increase
remotetimeout to 4.
In a review, I suggested to use "namespace gdb::observers" instead of
two separate namespace declarations. I didn't realize that this was a
C++17 feature, which breaks compilers that default to an earlier version
of the language, like g++ 4.8. Change it back to two separate
declarations.
gdb/ChangeLog:
* auto-load.h: Split namespace declaration.
Change-Id: I701537161967fbd9fcc298ff600bd072aab1251d
These two variables:
struct regcache *regcache = get_thread_regcache (tp);
const address_space *aspace = regcache->aspace ();
are only needed inside the "if". Getting a thread's regcache is a
somewhat expensive operation, so it's good to avoid it if not necessary.
Move the variable declarations and their initialization to the "if"
scope.
gdb/ChangeLog:
* infrun.c (save_waitstatus): Move variables to inner scope.
Change-Id: Ief1463728755b4dcc142c0a0a76896e9d594ae84
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.
Currently, the Ada expression parser treats 'null' as an integer 0.
However, this causes overloading to fail in certain cases.
This patch changes the Ada expression parser to use a special type for
'null'. I chose pointer-to-int0, because I think that's not likely to
be needed for any other Ada expression. Note this works because a
"mod 1" type has an underlying non-zero byte size; the test includes a
check for this.
The output is changed so that "print null", by default, shows "null".
And, ada_type_match is changed both to recognize the special null type
and to remove a bit of weird code related to how pointers are treated
for overload type matching.
Tested on x86-64 Fedora 32. Because this only touches Ada, and Joel
already approved it internally at AdaCore, I am checking it in.
gdb/ChangeLog
2021-04-28 Tom Tromey <tromey@adacore.com>
* ada-exp.y (primary): Use new type for null pointer.
* ada-lang.c (ada_type_match): Remove "may_deref"
parameter. Handle null pointer.
(ada_args_match): Update.
* ada-valprint.c (ada_value_print_ptr, ada_value_print):
Handle null pointer.
gdb/testsuite/ChangeLog
2021-04-28 Tom Tromey <tromey@adacore.com>
* gdb.ada/null_overload.exp: New file.
* gdb.ada/null_overload/foo.adb: New file.
Clean up a few places where we are not using @env{...} to reference
environment variables.
gdb/doc/ChangeLog:
* gdb.texinfo (Initialization Files): Use @env when referencing
environment variables.
(Shell Commands): Likewise.
(Starting): Likewise.
(Arguments): Likewise.
(Environment): Likewise.
(Edit): Likewise.
(Compiling and Injecting Code): Likewise.
(Files): Likewise.
(Command History): Likewise.
(Screen Size): Likewise.
(Emacs): Likewise.
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.
Now that both Python and Guile are fully initialized from their
respective finish_initialization methods, the "finish" in the method
name doesn't really make sense; initialization starts _and_ finishes
with that method.
As such, this commit renames finish_initialization to just initialize.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* extension-priv.h (struct extension_language_ops): Rename
'finish_initialization' to 'initialize'.
* extension.c (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this, update comment, and updated
the calls to reflect the change in struct extension_language_ops.
* extension.h (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this.
* guile/guile.c (gdbscm_finish_initialization): Renamed to...
(gdbscm_initialize): ...this, update comment at definition.
(guile_extension_ops): Update.
* main.c (captured_main_1): Update call to
finish_ext_lang_initialization.
* python/python.c (gdbpy_finish_initialization): Rename to...
(gdbpy_initialize): ...this, update comment at definition, and
update call to do_finish_initialization.
(python_extension_ops): Update.
(do_finish_initialization): Rename to...
(do_initialize): ...this, and update comment.
Now (thanks to the last few commits) all extension languages are
fully initialised in their finish_initialization method, this commit
delays the call to this method until after the early initialization
files have been processed.
Right now there's no benefit from doing this, but in a later commit I
plan to add new options for Python that will control how Python is
initialized.
With this commit in place, my next commits will allow the user to add
options to their early initialization file and alter how Python starts
up.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (captured_main_1): Add a call to
finish_ext_lang_initialization.
* top.c (gdb_init): Remove call to finish_ext_lang_initialization.
Like with the previous commit, this commit delays the initialisation
of the guile extension language until gdbscm_finish_initialization.
This is mostly about splitting the existing gdbscm_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbscm_initialize_*
functions.
Then the call to code previously in _initialize_guile is moved into
gdbscm_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* guile/guile.c (gdbscm_set_backtrace): Add declaration.
(gdbscm_finish_initialization): Add code moved from
_initialize_guile.
(_initialize_guile): Move code to gdbscm_finish_initialization.
* guile/scm-arch.c (gdbscm_initialize_arches): Move some code into
_initialize_scm_arch.
(_initialize_scm_arch): New function.
* guile/scm-block.c (gdbscm_initialize_blocks): Move some code
into _initialize_scm_block.
(_initialize_scm_block): New function.
* guile/scm-frame.c (gdbscm_initialize_frames): Move some code
into _initialize_scm_frame.
(_initialize_scm_frame): New function.
* guile/scm-objfile.c (gdbscm_initialize_objfiles): Move some code
into _initialize_scm_objfile.
(_initialize_scm_objfile): New function.
* guile/scm-progspace.c (gdbscm_initialize_pspaces): Move some
code into _initialize_scm_progspace.
(_initialize_scm_progspace): New function.
* guile/scm-symbol.c (gdbscm_initialize_symbols): Move some code
into _initialize_scm_symbol.
(_initialize_scm_symbol): New function.
* guile/scm-symtab.c (gdbscm_initialize_symtabs): Move some code
into _initialize_scm_symtab.
(_initialize_scm_symtab): New function.
* guile/scm-type.c (gdbscm_initialize_types): Move some code into
_initialize_scm_type.
(_initialize_scm_type): New function.
Delay Python initialisation until gdbpy_finish_initialization.
This is mostly about splitting the existing gdbpy_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbpy_initialize_*
functions.
Then the call to do_start_initialization (in python/python.c) is moved
from the _initialize_python function into gdbpy_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-arch.c (_initialize_py_arch): New function.
(gdbpy_initialize_arch): Move code to _initialize_py_arch.
* python/py-block.c (_initialize_py_block): New function.
(gdbpy_initialize_blocks): Move code to _initialize_py_block.
* python/py-inferior.c (_initialize_py_inferior): New function.
(gdbpy_initialize_inferior): Move code to _initialize_py_inferior.
* python/py-objfile.c (_initialize_py_objfile): New function.
(gdbpy_initialize_objfile): Move code to _initialize_py_objfile.
* python/py-progspace.c (_initialize_py_progspace): New function.
(gdbpy_initialize_pspace): Move code to _initialize_py_progspace.
* python/py-registers.c (_initialize_py_registers): New function.
(gdbpy_initialize_registers): Move code to
_initialize_py_registers.
* python/py-symbol.c (_initialize_py_symbol): New function.
(gdbpy_initialize_symbols): Move code to _initialize_py_symbol.
* python/py-symtab.c (_initialize_py_symtab): New function.
(gdbpy_initialize_symtabs): Move code to _initialize_py_symtab.
* python/py-type.c (_initialize_py_type): New function.
(gdbpy_initialize_types): Move code to _initialize_py_type.
* python/py-unwind.c (_initialize_py_unwind): New function.
(gdbpy_initialize_unwind): Move code to _initialize_py_unwind.
* python/python.c (_initialize_python): Move call to
do_start_initialization to gdbpy_finish_initialization.
(gdbpy_finish_initialization): Add call to
do_start_initialization.
In order for our SIGINT handling to work correctly with Python we
require that SIGINT be set to SIG_DFL during Python's initialisation.
Currently this is the case, but, in a later commit I plan to delay the
initialisation of Python until after the point where GDB's own SIGINT
handler has been installed.
The consequence of this is that our SIGINT handling would become
broken.
In this commit I propose adding an RAII class that will ensure SIGINT
is set to SIG_DFL during the call to each extension languages
finish_initialization method.
At this point this change should have not effect.
gdb/ChangeLog:
* extension.c (struct scoped_default_signal): New struct.
(scoped_default_sigint): New typedef.
(finish_ext_lang_initialization): Make use of
scoped_default_sigint.
The argument to gdb_init is not used, remove it.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (captured_main_1): Don't pass argument to gdb_init.
* top.c (gdb_init): Remove unused argument, and add header
comment.
* top.h (gdb_init): Remove argument.
I'm seeing timeouts from gdb.rust/traits.exp when we attempt to print
things with "maint print objfiles".
This happens for two reasons:
1 - GDB does not explicitly split each entry into its own line, but rather
relies on the terminal's width to insert line breaks.
2 - When running the GDB testsuite, such width may be unlimited, which will
prevent GDB from inserting any line breaks.
As a result, the output may be too lengthy and will come in big lines. Tweak
the support library to match the patterns line-by-line, which gives us more
time to match things. Also fix GDB's output to print one entry per line,
regardless of the terminal width.
A similar approach was used in another testcase using the same command (commit
eaeaf44cfdc9a4096a0dd52fa0606f29d4bfd48e). With the new line breaks, we don't
need a particular pattern, so clean up that test as well.
gdb/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* psymtab.c (psymbol_functions::dump): Output newline.
* symmisc.c (dump_objfile): Likewise.
gdb/testsuite/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* gdb.base/maint.exp: Drop a pattern that is not needed.
* lib/gdb.exp (readnow): Match line-by-line.
For aarch64, the "info all-registers" output is very verbose. If you run
this test using read1, it will timeout before the command output is done being
read.
Read line-by-line so we don't run into timeouts.
gdb/testsuite/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* gdb.xml/tdesc-reload.exp: Pass -lbl.
Without any explicit dependencies specified, the observers attached
to the 'gdb::observers::new_objfile' observable are always notified
in the order in which they have been attached.
The new_objfile observer callback to auto-load scripts is attached in
'_initialize_auto_load'.
The new_objfile observer callback that propagates the new_objfile event
to the Python side is attached in 'gdbpy_initialize_inferior', which is
called via '_initialize_python'.
With '_initialize_python' happening before '_initialize_auto_load',
the consequence was that the new_objfile event was emitted on the Python
side before autoloaded scripts had been executed when a new objfile was
loaded.
As a result, trying to access the objfile's pretty printers (defined in
the autoloaded script) from a handler for the Python-side
'new_objfile' event would fail. Those would only be initialized later on
(when the 'auto_load_new_objfile' callback was called).
To make sure that the objfile passed to the Python event handler
is properly initialized (including its 'pretty_printers' member),
make sure that the 'auto_load_new_objfile' observer is notified
before the 'python_new_objfile' one that propagates the event
to the Python side.
To do this, make use of the mechanism to explicitly specify
dependencies between observers (introduced in a preparatory commit).
Add a corresponding testcase that involves a test library with an autoloaded
Python script and a handler for the Python 'new_objfile' event.
(The real world use case where I came across this issue was in an attempt
to extend handling for GDB pretty printers for dynamically loaded
objfiles in the Qt Creator IDE, s. [1] and [2] for more background.)
[1] https://bugreports.qt.io/browse/QTCREATORBUG-25339
[2] https://codereview.qt-project.org/c/qt-creator/qt-creator/+/333857/1
Tested on x86_64-linux (Debian testing).
gdb/ChangeLog:
* gdb/auto-load.c (_initialize_auto_load): 'Specify token
when attaching the 'auto_load_new_objfile' observer, so
other observers can specify it as a dependency.
* gdb/auto-load.h (struct token): Declare
'auto_load_new_objfile_observer_token' as token to be used
for the 'auto_load_new_objfile' observer.
* gdb/python/py-inferior.c (gdbpy_initialize_inferior): Make
'python_new_objfile' observer depend on 'auto_load_new_objfile'
observer, so it gets notified after the latter.
gdb/testsuite/ChangeLog:
* gdb.python/libpy-autoloaded-pretty-printers-in-newobjfile-event.so-gdb.py: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.cc: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.h: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-main.cc: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.py: New test.
Change-Id: I8275b3f4c3bec32e56dd7892f9a59d89544edf89
Previously, the observers attached to an observable were always notified
in the order in which they had been attached. That order is not easily
controlled, because observers are typically attached in _initialize_*
functions, which are called in an undefined order.
However, an observer may require that another observer attached only
later is called before itself is.
Therefore, extend the 'observable' class to allow explicitly specifying
dependencies when attaching observers, by adding the possibility to
specify tokens for observers that it depends on.
To make sure dependencies are notified before observers depending on
them, the vector holding the observers is sorted in a way that
dependencies come before observers depending on them. The current
implementation for sorting uses the depth-first search algorithm for
topological sorting as described at [1].
Extend the observable unit tests to cover this case as well. Check that
this works for a few different orders in which the observers are
attached.
This newly introduced mechanism to explicitly specify dependencies will
be used in a follow-up commit.
[1] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Tested on x86_64-linux (Debian testing).
gdb/ChangeLog:
* unittests/observable-selftests.c (dependency_test_counters):
New.
(observer_token0, observer_token1, observer_token2,
observer_token3, observer_token4, observer_token5): New.
(struct dependency_observer_data): New struct.
(observer_dependency_test_callback): New function.
(test_observers): New.
(run_dependency_test): New function.
(test_dependency): New.
(_initialize_observer_selftest): Register dependency test.
gdbsupport/ChangeLog:
* observable.h (class observable): Extend to allow specifying
dependencies between observers, keep vector holding observers
sorted so that dependencies are notified before observers
depending on them.
Change-Id: I5399def1eeb69ca99e28c9f1fdf321d78b530bdb
PR gdb/27743 points out a gdb crash when expanding partial symtabs,
where one of the compilation units uses DW_TAG_imported_unit.
This crash happens for gdb 10, but not git trunk. This patch pulls
over the new test case only.
gdb/testsuite/ChangeLog
2021-04-26 Tom Tromey <tromey@adacore.com>
PR gdb/27743:
* gdb.dwarf2/imported-unit-bp.exp: New file.
* gdb.dwarf2/imported-unit-bp-main.c: New file.
* gdb.dwarf2/imported-unit-bp-alt.c: New file.
Bug 27773 shows that passing a filename in a non-existent directory to
the "dump binary" command leads to a gdb crash. This is because the
gdb_fopen_cloexec in dump_binary_file fails (returns nullptr) and the
return value is not checked. Fix that by erroring out if
gdb_fopen_cloexec fails.
gdb/ChangeLog:
PR gdb/27773
* cli/cli-dump.c (dump_binary_file): Check result of
gdb_fopen_cloexec.
gdb/testsuite/ChangeLog:
PR gdb/27773
* gdb.base/dump.exp: Test dump to non-existent dir.
Change-Id: Iea89a3bf9e6b9dcc31142faa5ae17bc855759328
The test checks for a particular ARCH level, but it needs to check for
ARCH levels from a minimum and upwards.
gdb/testsuite/ChangeLog:
2021-04-26 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-dbreg-contents.c (set_watchpoint): Fix arch level
comparison.
On sparc build failed as:
```
gdb/sparc-linux-nat.c: In member function
'virtual void sparc_linux_nat_target::fetch_registers(regcache*, int)':
gdb/sparc-linux-nat.c:36:37:
error: cannot convert 'regcache*' to 'process_stratum_target*'
36 | { sparc_fetch_inferior_registers (regcache, regnum); }
| ^~~~~~~~
| |
| regcache*
```
The fix adopts gdb/sparc-nat.h API change in d1e93af64a6
("gdb: set current thread in sparc_{fetch,collect}_inferior_registers").
gdb/ChangeLog:
* sparc-linux-nat.c (sparc_linux_nat_target): fix sparc build
by passing `process_stratum_target*` parameter.
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.
