This rewrites the existing variant part code to follow the new model
implemented in the previous patch. The old variant part code is
removed.
This only affects Rust for the moment. I tested this using various
version of the Rust compiler, including one that emits old-style enum
debuginfo, exercising the quirks code.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (struct variant_field): Rewrite.
(struct variant_part_builder): New.
(struct nextfield): Remove "variant" field. Add "offset".
(struct field_info): Add "current_variant_part" and
"variant_parts".
(alloc_discriminant_info): Remove.
(alloc_rust_variant): New function.
(quirk_rust_enum): Update.
(dwarf2_add_field): Set "offset" member. Don't handle
DW_TAG_variant_part.
(offset_map_type): New typedef.
(convert_variant_range, create_one_variant)
(create_one_variant_part, create_variant_parts)
(add_variant_property): New functions.
(dwarf2_attach_fields_to_type): Call add_variant_property.
(read_structure_type): Don't handle DW_TAG_variant_part.
(handle_variant_part, handle_variant): New functions.
(handle_struct_member_die): Use them.
(process_structure_scope): Don't handle variant parts.
* gdbtypes.h (TYPE_FLAG_DISCRIMINATED_UNION): Remove.
(struct discriminant_info): Remove.
(enum dynamic_prop_node_kind) <DYN_PROP_DISCRIMINATED>: Remove.
(struct main_type) <flag_discriminated_union>: Remove.
* rust-lang.c (rust_enum_p, rust_empty_enum_p): Rewrite.
(rust_enum_variant): Return int. Remove "contents". Rewrite.
(rust_print_enum, rust_print_struct_def, rust_evaluate_subexp):
Update.
* valops.c (value_union_variant): Remove.
* value.h (value_union_variant): Don't declare.
When evaluating a DWARF expression, the dynamic type resolution code
will pass in a buffer of bytes via the property_addr_info. However,
the DWARF expression evaluator will then proceed to read memory from
the inferior, even when the request could be filled from this buffer.
This, in turn, is a problem in some cases; and specifically when
trying to handle the Ada scenario of extracting a variable-length
value from a packed array. Here, the ordinary DWARF expression cannot
be directly evaluated, because the data may appear at some arbitrary
bit offset. So, it is unpacked into a staging area and then the
expression is evaluated -- using an address of 0.
This patch fixes the problem by arranging for the DWARF evaluator, in
this case, to prefer passed-in memory when possible. The type of the
buffer in the property_addr_info is changed to an array_view so that
bounds checking can be done.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_discrete_type_high_bound, ada_discrete_type_low)
(ada_value_primitive_packed_val): Update.
* ada-valprint.c (ada_value_print_1): Update.
* dwarf2/loc.c (evaluate_for_locexpr_baton): New struct.
(dwarf2_locexpr_baton_eval): Take a property_addr_info rather than
just an address. Use evaluate_for_locexpr_baton.
(dwarf2_evaluate_property): Update.
* dwarf2/loc.h (struct property_addr_info) <valaddr>: Now an
array_view.
* findvar.c (default_read_var_value): Update.
* gdbtypes.c (compute_variant_fields_inner)
(resolve_dynamic_type_internal): Update.
(resolve_dynamic_type): Change type of valaddr parameter.
* gdbtypes.h (resolve_dynamic_type): Update.
* valarith.c (value_subscripted_rvalue): Update.
* value.c (value_from_contents_and_address): Update.
Some DWARF expressions must be evaluated by first pushing the object
address onto the evaluation stack. This patch adds this ability.
This functionality is not used yet, but it will be used in a later
patch. This is split out for easier review and also because it
improved the patch series ordering.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add
"push_initial_value" parameter.
(dwarf2_evaluate_property): Likewise.
* dwarf2/loc.h (dwarf2_evaluate_property): Update.
This patch adds the infrastructure for the new variant part code. At
this point, nothing uses this code. This is done in a separate patch
to make it simpler to review.
I examined a few possible approaches to handling variant parts. In
particular, I considered having a DWARF variant part be a union
(similar to how the Rust code works now); and I considered having type
fields have a flag indicating that they are variants.
Having separate types seemed bad conceptually, because these variants
aren't truly separate -- they rely on the "parent" type. And,
changing how fields worked seemed excessively invasive.
So, in the end I thought the approach taken in this patch was both
simple to implement and understand, without losing generality. The
idea in this patch is that all the fields of a type with variant parts
will be stored in a single field array, just as if they'd all been
listed directly. Then, the variants are attached as a dynamic
property. These control which fields end up in the type that's
constructed during dynamic type resolution.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdbtypes.c (is_dynamic_type_internal): Check for variant parts.
(variant::matches, compute_variant_fields_recurse)
(compute_variant_fields_inner, compute_variant_fields): New
functions.
(resolve_dynamic_struct): Check for DYN_PROP_VARIANT_PARTS.
Use resolved_type after type is made.
(operator==): Add new cases.
* gdbtypes.h (TYPE_HAS_VARIANT_PARTS): New macro.
(struct discriminant_range, struct variant, struct variant_part):
New.
(union dynamic_prop_data) <variant_parts, original_type>: New
members.
(enum dynamic_prop_node_kind) <DYN_PROP_VARIANT_PARTS>: New constant.
(enum dynamic_prop_kind) <PROP_TYPE, PROP_VARIANT_PARTS>: New
constants.
* value.c (unpack_bits_as_long): Now public.
* value.h (unpack_bits_as_long): Declare.
I wanted to use the name "variant" to represent a DWARF variant, but
it turned out there was an existing structure of that name. This
renames the existing variant to "ppc_variant".
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* rs6000-tdep.c (struct ppc_variant): Rename from "variant".
(variants, find_variant_by_arch, rs6000_gdbarch_init): Update.
When running test-case gdb.base/readnever.exp without commit 96038148d0
"[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow", we
run into an error:
...
ERROR: (eof) GDB never initialized.
testcase gdb/testsuite/gdb.base/readnever.exp completed in 0 seconds
...
If we additionally run test-case gdb.base/realname-expand.exp, we get an
unresolved for the first test:
...
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...
Using -v we find out that the UNRESOLVED is due the error triggered in the
previous test-case:
...
(gdb) set basenames-may-differ on^M
(gdb) Error/Warning threshold exceeded: 1 0 (max. 1 3)
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...
So, the error count of one test spills into the next test, even though we do a
clean restart. That seems like a bad idea.
Fix this by resetting errcnt (as well as warncnt) in clean_restart, such that
we have:
...
Running src/gdb/testsuite/gdb.base/readnever.exp ...
ERROR: (eof) GDB never initialized.
Running src/gdb/testsuite/gdb.base/realname-expand.exp ...
PASS: gdb.base/realname-expand.exp: set basenames-may-differ on
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (clean_restart): Reset errcnt and warncnt.
The updated pending stop series introduced a regression in Windows
debugging. When stopped at a software breakpoint, we would adjust the
PC each time it was requested -- however, more than a single
adjustment is incorrect. This patch introduces a new flag that is
used to ensure the adjustment only happens a single time.
No similar change is needed in gdbserver, because it adjusts the PC in
a different way.
I still can't run the gdb test suite on Windows, but I can run the
internal AdaCore test suite there; and this fixes the regressions
there.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (struct windows_thread_info)
<pc_adjusted>: New member.
* windows-nat.c (windows_fetch_one_register): Check
pc_adjusted.
(windows_nat_target::get_windows_debug_event)
(windows_nat_target::wait): Set pc_adjusted.
When running test-case gdb.dwarf2/dwzbuildid.exp with target board
cc-with-gdb-index, we have:
...
Running src/gdb/testsuite/gdb.dwarf2/dwzbuildid.exp ...
gdb compile failed, warning: File "dwzbuildid5.o" has a different \
build-id, file skipped
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch
warning: File "dwzbuildid5.o" has a different build-id, file skipped
Error while writing index for `dwzbuildid-mismatch': could not find \
'.gnu_debugaltlink' file for dwzbuildid-mismatch
...
and likewise for target board cc-with-debug-names.
These are gdb-add-index warnings and errors due to the executable
dwzbuildid-mismatch having a build-id mismatch.
Be less verbose by adding "quiet" to the compile flags.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dwzbuildid.exp: Add quiet to dwzbuildid-mismatch compile
flags.
When running test-case gdb.dwarf2/dw2-error.exp with target board
cc-with-gdb-index, we get:
...
Running src/gdb/testsuite/gdb.dwarf2/dw2-error.exp ...
gdb compile failed, Dwarf Error: wrong version in compilation unit header \
(is 153, should be 2, 3, 4 or 5) [in module \
build/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/.tmp/dw2-error]
...
and similar for target board cc-with-debug-names.
Be less verbose by adding "quiet" to the compile flags.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-error.exp: Add quiet to compile flags.
When running test-case gdb.base/readnever.exp with target board readnow, and
without commit 96038148d0 "[gdb/testsuite] Skip gdb.base/readnever.exp with
target board readnow", we run into a bunch of errors, starting with:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
--readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re "$gdb_prompt $" {
verbose "Setting height to 0." 2
}
...
The illegal combination of --readnow and --readnever causes gdb to start,
print an error message and exit. There's a gdb_expect in default_gdb_start
that is supposed to detect the initial gdb prompt and handle related problems,
but since there's no eof case it succeeds, and default_gdb_start continues as
if the gdb prompt had been detected, causing the error above.
Fix this by adding an eof case to the gdb_expect, such that we have the more
accurate:
...
ERROR: (eof) GDB never initialized.
...
Further errors are triggered in clean_restart, because we're not testing for
gdb_start success. Fix this by detecting gdb_start failure, and bailing out.
Finally, we're running into further errors in gdb.base/readnever.exp because
we're not testing for clean_restart success. Fix this by making clean_restart
return -1 upon error, and testing for this.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (default_gdb_start): Handle eof.
(clean_restart): Detect and handle gdb_start failure. Return -1 upon
failure.
* gdb.base/readnever.exp: Handle clean_restart failure.
When running test-case gdb.dwarf2/gdb-index.exp cleanly by issuing this
command:
...
$ rm -Rf build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index
...
before running, it passes both with native and target board
cc-with-gdb-index.
But when we run the test-case first with native and then with
cc-with-gdb-index without intermediate cleanup, we get instead:
...
Running src/gdb/testsuite/gdb.dwarf2/gdb-index.exp ...
gdb compile failed, cc-with-tweaks.sh: Index file \
build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index/gdb-index.gdb-index \
exists, won't clobber.
=== gdb Summary ===
# of untested testcases 1
...
What happens is that the native run produces a file
build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index/gdb-index.gdb-index, which
causes gdb/contrib/cc-with-tweaks.sh to hit this code:
...
index_file="${output_file}.gdb-index"
if [ "$want_index" = true ] && [ -f "$index_file" ]
then
echo "$myname: Index file $index_file exists, won't clobber." >&2
exit 1
fi
...
The gdb-add-index script has a problem that it uses temp files alongside the
executable, filed as PR25843.
The code in cc-with-tweaks.sh attempts to detect the case that creating such a
temp file would overwrite an pre-existing file. It however does this only for
a single file, while gdb-add-index uses more temporary files:
- <exec>.gdb-index
- <exec>.debug_names
- <exec>.debug_str
- <exec>.debug_str.merge
- <exec>.debug_str.err
Fix this by working around PR25843 in a more generic way:
- move the executable into a temp directory
- execute gdb-add-index, allowing it to create any temp file alongside the
executable in the temp directory
- move the executable back to the original location
Tested on x86_64-linux, with target board cc-with-debug-index.
gdb/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh: Remove <exec>.gdb-index file handling.
Run gdb-add-index inside temp dir.
There were some Windows timeouts after the last merge. Debugging
showed that these were caused by an infinite loop in
is_linked_with_cygwin_dll when reading C:\Windows\SysWOW64\win32u.dll.
This patch fixes the problem by ensuring that the loop always makes
progress.
gdb/ChangeLog
2020-04-23 Tom Tromey <tromey@adacore.com>
* windows-tdep.c (is_linked_with_cygwin_dll): Always update "iter"
in loop.
There has been some breakage for aarch64-linux, arm-linux and s390-linux in
terms of inline frame unwinding. There may be other targets, but these are
the ones i'm aware of.
The following testcases started to show numerous failures and trigger internal
errors in GDB after commit 1009d92fc6,
"Find tailcall frames before inline frames".
gdb.opt/inline-break.exp
gdb.opt/inline-cmds.exp
gdb.python/py-frame-inline.exp
gdb.reverse/insn-reverse.exp
The internal errors were of this kind:
binutils-gdb/gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.
After a lengthy investigation to try and find the cause of these assertions,
it seems we're dealing with some fragile/poorly documented code to handle inline
frames and we are attempting to unwind from this fragile section of code.
Before commit 1009d92fc6, the tailcall sniffer
was invoked from dwarf2_frame_prev_register. By the time we invoke the
dwarf2_frame_prev_register function, we've probably already calculated the
frame id (via compute_frame_id).
After said commit, the call to dwarf2_tailcall_sniffer_first was moved to
dwarf2_frame_cache. This is very early in a frame creation process, and
we're still calculating the frame ID (so compute_frame_id is in the call
stack).
This would be fine for regular frames, but the above testcases all deal
with some inline frames.
The particularity of inline frames is that their frame ID's depend on
the previous frame's ID, and the previous frame's ID relies in the inline
frame's registers. So it is a bit of a messy situation.
We have comments in various parts of the code warning about some of these
particularities.
In the case of dwarf2_tailcall_sniffer_first, we attempt to unwind the PC,
which goes through various functions until we eventually invoke
frame_unwind_got_register. This function will eventually attempt to create
a lazy value for a particular register, and this lazy value will require
a valid frame ID. Since the inline frame doesn't have a valid frame ID
yet (remember we're still calculating the previous frame's ID so we can tell
what the inline frame ID is) we will call compute_frame_id for the inline
frame (level 0).
We'll eventually hit the assertion above, inside get_frame_id:
--
/* If we haven't computed the frame id yet, then it must be that
this is the current frame. Compute it now, and stash the
result. The IDs of other frames are computed as soon as
they're created, in order to detect cycles. See
get_prev_frame_if_no_cycle. */
gdb_assert (fi->level == 0);
--
It seems to me we shouldn't have reached this assertion without having the
inline frame ID already calculated. In fact, it seems we even start recursing
a bit when we invoke get_prev_frame_always within inline_frame_this_id. But
a check makes us quit the recursion and proceed to compute the id.
Here's the call stack for context:
#0 get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2109
RECURSION - #1 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124
#2 0x0000aaaaaae95768 in inline_frame_this_id (this_frame=0xaaaaab85a670, this_cache=0xaaaaab85a688, this_id=0xaaaaab85a6d0)
at ../../../repos/binutils-gdb/gdb/inline-frame.c:165
#3 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:550
#4 0x0000aaaaaae19318 in get_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:582
#5 0x0000aaaaaae13480 in value_of_register_lazy (frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/findvar.c:296
#6 0x0000aaaaaae16c00 in frame_unwind_got_register (frame=0xaaaaab85a730, regnum=30, new_regnum=30) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:268
#7 0x0000aaaaaad52604 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=30)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1296
#8 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1229
#9 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1320
#10 0x0000aaaaaab76574 in aarch64_dwarf2_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32)
at ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:1114
#11 0x0000aaaaaad52724 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1316
#12 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1229
#13 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1320
#14 0x0000aaaaaae16a84 in default_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:223
#15 0x0000aaaaaae32124 in gdbarch_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/gdbarch.c:3074
#16 0x0000aaaaaad4f15c in dwarf2_tailcall_sniffer_first (this_frame=0xaaaaab85a730, tailcall_cachep=0xaaaaab85a830, entry_cfa_sp_offsetp=0x0)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame-tailcall.c:388
#17 0x0000aaaaaad520c0 in dwarf2_frame_cache (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1190
#18 0x0000aaaaaad52204 in dwarf2_frame_this_id (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, this_id=0xaaaaab85a790)
at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1218
#19 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame.c:550
#20 0x0000aaaaaae1c958 in get_prev_frame_if_no_cycle (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:1927
#21 0x0000aaaaaae1cc44 in get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2006
FIRST CALL - #22 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124
#23 0x0000aaaaaae18f68 in skip_artificial_frames (frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:495
#24 0x0000aaaaaae193e8 in get_stack_frame_id (next_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:596
#25 0x0000aaaaaae87a54 in process_event_stop_test (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6857
#26 0x0000aaaaaae86bdc in handle_signal_stop (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6381
#27 0x0000aaaaaae84fd0 in handle_inferior_event (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:5578
#28 0x0000aaaaaae81588 in fetch_inferior_event (client_data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:4020
#29 0x0000aaaaaae5f7fc in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at ../../../repos/binutils-gdb/gdb/inf-loop.c:43
#30 0x0000aaaaaae8d768 in infrun_async_inferior_event_handler (data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:9377
#31 0x0000aaaaaabff970 in check_async_event_handlers () at ../../../repos/binutils-gdb/gdb/async-event.c:291
#32 0x0000aaaaab27cbec in gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:194
#33 0x0000aaaaaaef1894 in start_event_loop () at ../../../repos/binutils-gdb/gdb/main.c:356
#34 0x0000aaaaaaef1a04 in captured_command_loop () at ../../../repos/binutils-gdb/gdb/main.c:416
#35 0x0000aaaaaaef3338 in captured_main (data=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1254
#36 0x0000aaaaaaef33a0 in gdb_main (args=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1269
#37 0x0000aaaaaab6e0dc in main (argc=6, argv=0xfffffffff348) at ../../../repos/binutils-gdb/gdb/gdb.c:32
The following patch addresses this by using a function that unwinds the PC
from the next (inline) frame directly as opposed to creating a lazy value
that is bound to the next frame's ID (still not computed).
gdb/ChangeLog:
2020-04-23 Luis Machado <luis.machado@linaro.org>
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Use
get_frame_register instead of gdbarch_unwind_pc.
This is a follow-up patch on "[PATCH][gdb/symtab] Prefer def over decl
(inter-CU case)" (
https://sourceware.org/pipermail/gdb-patches/2020-April/167489.html ).
Consider the test-case from that patch. It contains a decl and def of var a
in different CUs, and tests whether var a can be printed using the def, even
if the decl is found first.
However, the test-case does this in a contextless environment, so if we add to
the test-case like this to set the context to the CU containing main:
...
gdb_test "p a" { = \{1, 2\}}
+
+if ![runto_main] then {
+ fail "can't run to main"
+ return 0
+}
+
+gdb_test "p a" { = \{1, 2\}}
...
then the second test fails, because the decl is found in the context.
Fix this by preferring defs over decls in lookup_global_symbol.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* symtab.c (lookup_global_symbol): Prefer def over decl.
gdb/testsuite/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* gdb.base/decl-before-def.exp: Run to main and print a again.
When running test-case gdb.threads/tls.exp with target board -readnow, we
have:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while with native we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...
The difference in behaviour can be explained as follows. Without -readnow, we
have two a_thread_locals, the def and the decl, each in a different CU:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot read `a_thread_local' without registers
int a_thread_local; computed at runtime
int a_thread_local; unresolved
...
and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
int a_thread_local; unresolved
int a_thread_local; computed at runtime
...
Fix the FAIL by preferring the def over the decl (something we already do
intra-CU since the fix for PR24971, commit 93e55f0a03 "[gdb/symtab] Prefer var
def over decl").
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
PR symtab/25807
* block.c (best_symbol, better_symbol): Promote to external.
* block.h (best_symbol, better_symbol): Declare.
* symtab.c (lookup_symbol_in_objfile_symtabs): Prefer def over
decl.
gdb/testsuite/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* gdb.base/decl-before-def-decl.c: New test.
* gdb.base/decl-before-def-def.c: New test.
* gdb.base/decl-before-def.exp: New file.
PR ada/25837 points out a crash in the gdb testsuite when .debug_names
is used. You can reproduce like:
runtest --target_board=cc-with-debug-names \
gdb.ada/big_packed_array.exp
The bug was introduced by commit e0802d599 ("Avoid copying in
lookup_name_info"). The problem is that the return type of
language_lookup_name changed, but in a way that didn't cause existing
callers to trigger a compilation error. Previously, it returned a
"const string &", but after it returned a "const char *". This caused
a string to be created in dw2_expand_symtabs_matching_symbol, but one
that had too short of a lifetime; so eventually the matcher cache
would wind up with invalid data.
This patch fixes the problem by updating the callers to use the new
type.
Tested on x86-64 Fedora 30.
gdb/ChangeLog
2020-04-23 Tom Tromey <tromey@adacore.com>
PR ada/25837:
* dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Store a
"const char *", not a "const std::string &".
<name_and_matcher::operator==>: Update.
* unittests/lookup_name_info-selftests.c: Change type of
"result".
The last caller of iterate_over_inferiors is darwin-nat.c. This patch
removes the calls from this file, and then remove
iterate_over_inferiors.
In general I think "external iteration" is to be preferred in gdb, the
main benefit being that the code is easier to read.
I rebuilt this on Darwin. I seem to only have access to Darwin
systems where gdb does not yet work :-(, so I can't run the test
suite.
gdb/ChangeLog
2020-04-23 Tom Tromey <tom@tromey.com>
* inferior.h (iterate_over_inferiors): Don't declare.
* inferior.c (iterate_over_inferiors): Remove.
* darwin-nat.c (find_inferior_task_it, find_inferior_pid_it):
Remove.
(darwin_find_inferior_by_task, darwin_find_inferior_by_pid): Don't
use iterate_over_inferiors.
(darwin_resume_inferior_it)
(struct resume_inferior_threads_param)
(darwin_resume_inferior_threads_it): Remove.
(darwin_nat_target::resume): Don't use iterate_over_inferiors.
Change-Id: Ib2fdf2c98e40f13156ff869ed3173d5f1fdae7ea
When running test-case gdb.base/readnever.exp with target board readnow, we
have:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
--readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp19 not open
...
Fix this by skipping the test when -readnow/--readnow is detected in
GDBFLAGS.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* gdb.base/readnever.exp: Skip if GDBFLAGS contain -readnow/--readnow.
When running test-case gdb.dwarf2/dw2-ranges-func.exp with target board
readnow, we have:
...
FAIL: gdb.dwarf2/dw2-ranges-func.exp: disassemble foo (pattern 2)
...
The function foo consists of two ranges:
...
<1><12f>: Abbrev Number: 7 (DW_TAG_subprogram)
<130> DW_AT_external : 1
<131> DW_AT_name : foo
<135> DW_AT_ranges : 0x40
...
which are listed here:
...
00000040 00000000004004c1 00000000004004dc
00000040 00000000004004ae 00000000004004ba
...
Normally the disassemble instruction lists both ranges, but with -readnow it
only lists the first.
This is due to function find_pc_partial_function, which only interacts with
partial symtabs, but not with expanded ones.
Fix this by using find_pc_sect_compunit_symtab in find_pc_partial_function.
Tested on x86_64, with native and target board readnow.
This fixes 19 FAILs for target board readnow, in test-cases
gdb.arch/amd64-entry-value.exp, gdb.base/multi-forks.exp,
gdb.dwarf2/dw2-ranges-func.exp and gdb.linespec/skip-two.exp.
gdb/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* blockframe.c (find_pc_partial_function): Use
find_pc_sect_compunit_symtab rather than
objfile->sf->qf->find_pc_sect_compunit_symtab.
While investigating PR25862 (an assertion failure with target board
cc-with-debug-names), I noticed that the .debug_aranges section in
gdb.mi/dw2-ref-missing-frame-func.c contains a hardcoded 0:
...
" .4byte 0 \n" // .Ldebug_info0 - Offset of Compilation Unit Info
...
So when looking for an address in the range 0x4004a7-0x4004bf, we should find
the CU at 0xc7:
...
Compilation Unit @ offset 0xc7:
Length: 0xba (32-bit)
Version: 2
Abbrev Offset: 0x64
Pointer Size: 4
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d3> DW_AT_high_pc : 0x4004bf
<d7> DW_AT_low_pc : 0x4004a7
<db> DW_AT_name : file1.txt
<e5> DW_AT_producer : GNU C 3.3.3
<f1> DW_AT_language : 1 (ANSI C)
...
but instead the .debug_aranges entry points us to the CU at 0x0:
...
Length: 28
Version: 2
Offset into .debug_info: 0x0
Pointer Size: 4
Segment Size: 0
Address Length
004004a7 00000018
00000000 00000000
...
Fix this by using a label to refer to the start of the CU, similar to how
that's done for gdb.dlang/watch-loc.c in the fix for PR24522:
...
" .4byte .Lcu1_begin\n" // .Ldebug_info0 - Offset of Compilation Unit Info
...
The label marks the start of the empty .debug_info section for
dw2-ref-missing-frame-func.c, which is supposed to merge with the .debug_info
section in dw2-ref-missing-frame.S, so in order for that to work, we need to
make sure dw2-ref-missing-frame-func.o comes before dw2-ref-missing-frame.o in
the link line.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
* gdb.mi/dw2-ref-missing-frame-func.c (.debug_aranges): Fix
debug_info_offset.
* gdb.mi/dw2-ref-missing-frame.exp: Make sure $objfuncfile comes
before $objsfile in the line line.
While investigating PR25862 (an assertion failure with target board
cc-with-debug-names), I noticed that the .debug_aranges section in
gdb.dlang/watch-loc.c contains a hardcoded 0x1000:
...
" .4byte _Dmain \n" // Address
" .4byte 0x1000 \n" // Length
...
Fix this by using the actual length of _Dmain, along the lines of how that
is done in gdb.mi/dw2-ref-missing-frame-func.c:
...
" .4byte _Dmain_end - _Dmain \n" // Length
...
such that the .debug_aranges entry:
...
Address Length
004004a7 0000000b
00000000 00000000
...
matches the addresses found in the corresponding CU:
...
<2><fd>: Abbrev Number: 6 (DW_TAG_subprogram)
<fe> DW_AT_name : _Dmain
<105> DW_AT_low_pc : 0x4004a7
<10d> DW_AT_high_pc : 0x4004b2
...
With this fix the assertion failure is no longer triggered for
gdb.dlang/watch-loc.exp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
* gdb.dlang/watch-loc.c (.debug_aranges): Fix _Dmain length.
Consider a test-case consisting of source file test.c:
...
extern int aaa;
int
main (void)
{
return 0;
}
...
and test-2.c:
...
int aaa = 33;
...
compiled with debug info only for test.c:
...
$ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g
...
When trying to print aaa, we get:
...
$ gdb -batch a.out -ex "print aaa"
'aaa' has unknown type; cast it to its declared type
...
but with -readnow we have:
...
$ gdb -readnow -batch a.out -ex "print aaa"
$1 = 33
...
In the -readnow case, the symbol for aaa in the full symtab has
LOC_UNRESOLVED, and the symbol type is combined with the minimal symbol
address, to read the value and print it without cast.
Without the -readnow, we create partial symbols, but the aaa decl is missing
from the partial symtabs, so we find it only in the minimal symbols, resulting
in the cast request. If the aaa decl would have been in the partial symtabs,
it would have been found, and the full symtab would have been expanded, after
which things would be as with -readnow.
The function add_partial_symbol has a comment on the LOC_UNRESOLVED +
minimal symbol addres construct at DW_TAG_variable handling:
...
else if (pdi->is_external)
{
/* Global Variable.
Don't enter into the minimal symbol tables as there is
a minimal symbol table entry from the ELF symbols already.
Enter into partial symbol table if it has a location
descriptor or a type.
If the location descriptor is missing, new_symbol will create
a LOC_UNRESOLVED symbol, the address of the variable will then
be determined from the minimal symbol table whenever the variable
is referenced.
...
but it's not triggered due to this test in scan_partial_symbols:
...
case DW_TAG_variable:
...
if (!pdi->is_declaration)
{
add_partial_symbol (pdi, cu);
}
...
Fix this in scan_partial_symbols by allowing external variable decls to be
added to the partial symtabs.
Build and reg-tested on x86_64-linux.
The patch caused this regression:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while without the patch we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...
However, without the patch but with -readnow we have the same FAIL as with the
patch (filed as PR25807). In other words, the patch has the effect that we
get the same result with and without -readnow.
This can be explained as follows. Without the patch, and without -readnow, we
have two a_thread_locals, the def and the decl:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot read `a_thread_local' without registers
int a_thread_local; computed at runtime
int a_thread_local; unresolved
...
while without the patch and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
int a_thread_local; unresolved
int a_thread_local; computed at runtime
...
With the patch we have the same order with and without -readnow, but just a
different one than before without -readnow.
Mark the "Cannot find thread-local variables on this target" variant a PR25807
kfail.
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* dwarf2/read.c (scan_partial_symbols): Allow external variable decls
in psymtabs.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* gdb.base/psym-external-decl-2.c: New test.
* gdb.base/psym-external-decl.c: New test.
* gdb.base/psym-external-decl.exp: New file.
* gdb.threads/tls.exp: Add PR25807 kfail.
When running test-case gdb.ada/dgopt.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects and gcc-8, gcc-9 or
gcc-10, and the fix for PR25700, we run into this regression:
...
(gdb) list x.adb:16, 16^M
No source file named x.adb.^M
(gdb) FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...
The reason for the failure is that without the fix for PR25700, we
have an unshared psymtab:
...
{ psymtab gdb.ada/dgopt/x.adb ((struct partial_symtab *) $hex)^M
readin no^M
fullname (null)^M
text addresses 0x0 -- 0x0^M
psymtabs_addrmap_supported yes^M
globals (none)^M
statics (none)^M
dependencies (none)^M
}^M
...
and a shared psymtab (with user field set):
...
{ psymtab gdb.ada/dgopt/x.adb ((struct partial_symtab *) $hex)^M
readin no^M
fullname (null)^M
text addresses 0x0 -- 0x0^M
psymtabs_addrmap_supported yes^M
globals (none)^M
statics (none)^M
user <artificial>@0x159a ((struct partial_symtab *) 0x37b57c0)^M
dependencies (none)^M
}^M
...
The fix for PR25700 removes the unshared psymtab.
Then when trying to find a psymtab matching x.adb in
psym_map_symtabs_matching_filename, we run into this continue for the shared
psymtab:
...
for (partial_symtab *pst : require_partial_symbols (objfile, true))
{
/* We can skip shared psymtabs here, because any file name will be
attached to the unshared psymtab. */
if (pst->user != NULL)
continue;
...
and consequently cannot find the file.
Fix this by not skipping the shared symtab in
psym_map_symtabs_matching_filename.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25801
* psymtab.c (psym_map_symtabs_matching_filename): Don't skip shared
symtabs.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25801
* gdb.dwarf2/imported-unit.exp: Test that we can get imported_unit.c
in "info source" output.
Consider the executable generated for test-case gdb.dwarf2/imported-unit.exp.
When loading the executable using various tracing:
...
$ gdb \
outputs/gdb.dwarf2/imported-unit/imported-unit \
-batch \
-iex "set verbose on" \
-iex "set debug symtab-create 1"
...
Created psymtab 0x213f380 for module <artificial>@0xc7.
Created psymtab 0x20e7b00 for module imported_unit.c.
Created psymtab 0x215da20 for module imported_unit.c.
Created psymtab 0x2133630 for module elf-init.c.
Created psymtab 0x215b910 for module ../sysdeps/x86_64/crtn.S.
...
we notice that there are two psymtabs generated for imported_unit.c.
This is due to the following: in dwarf2_build_psymtabs_hard we loop over CUs
and generate partial symtabs for those, and if we encounter an import of
another CU, we also generate a partial symtab for that one, unless already
created.
This works well with backward import references:
- the imported CU is read
- then the importing CU is read
- the import is encountered, but the imported CU is already read, so
we're done.
But with forward import references, we have instead:
- the importing CU is read
- the import is encountered, and the imported CU is read
- the imported CU is read once more
Fix this by skipping already created psymtabs in the loop in
dwarf2_build_psymtabs_hard.
Tested on x86_64-linux, with native and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.
This causes this regression with the target board:
...
FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...
which I consider a seperate PR, filed as PR25801 - "Filename of shared psymtab
is ignored".
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25700
* dwarf2/read.c (dwarf2_build_psymtabs_hard): Don't create psymtab for
CU if already created.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25700
* gdb.dwarf2/imported-unit.exp: Verify that there's only one partial
symtab for imported_unit.c.
Clang fails to compile the above file, with the following errors:
warning: control reaches end of non-void function [-Wreturn-type]
warning: too many arguments in call to 'func'
This prevents the following testcases from executing:
gdb.base/advance.exp
gdb.base/until-nodebug.exp
gdb/testsuite/ChangeLog:
* gdb.base/advance.c (func): New argument, to match call site.
(func2, func3): Add return statements.
In infrun.c's 'displaced_step_fixup', as part of the 'finish_step_over'
flow, switch to the eventing thread *before* calling
'displaced_step_restore', because down in the flow ptid-dependent
memory accesses are used via current_inferior() and current_top_target().
Without this patch, the problem is exposed with the scenario below:
$ gdb -q
(gdb) maint set target-non-stop on
(gdb) file a.out
Reading symbols from a.out...
(gdb) set remote exec-file a.out
(gdb) target extended-remote | gdbserver --once --multi -
...
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote ...)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file a.out
Reading symbols from a.out...
(gdb) set remote exec-file a.out
(gdb) run
...
Cannot access memory at address 0x555555555042
(gdb)
The problem is, down inside 'displaced_step_restore', GDB wants to
access the memory for inferior 2 because of an internal breakpoint.
However, the current inferior and inferior_ptid are out of sync.
While inferior_ptid correctly points to the process of inf 2 that was
just started, current_inferior points to inf 1. Then, the attempt to
access the memory fails, because target_has_execution results in false
since inf 1 was not started. I was not able to simplify the failing
scenario, but it shows the problem.
After this patch, we get
... same steps above...
(gdb) run
...
[Inferior 2 (process 28652) exited normally]
(gdb)
Regression-tested on X86_64 Linux with `make check`s default board file
and also `--target_board=native-extended-gdbserver`. In fact, the bug
fixed by this patch was exposed when using the native-extended-gdbserver
board file.
gdb/ChangeLog:
2020-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (displaced_step_fixup): Switch to the event_thread
before calling displaced_step_restore, not after.
gdb/testsuite/ChangeLog:
2020-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.multi/run-only-second-inf.c: New file.
* gdb.multi/run-only-second-inf.exp: New file.
When there is more than one inferior, the "record btrace" command should
only apply to the current inferior.
gdb/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_enable_warn): Ignore thread if
its inferior is not recorded by us.
(record_btrace_target_open): Replace call to all_non_exited_threads ()
with call to current_inferior ()->non_exited_threads ().
(record_btrace_target::stop_recording): Likewise.
(record_btrace_target::close): Likewise.
(record_btrace_target::wait): Likewise.
(record_btrace_target::record_stop_replaying): Likewise.
gdb/testsuite/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/multi-inferior.c: New test.
* gdb.btrace/multi-inferior.exp: New file.
GDB silently ignores attempts to enable branch tracing on a thread that is
already recorded. This shouldn't happen as recording is enabled exactly
once:
- when the btrace record target is opened for existing threads
- when a new thread is added while the btrace record target is pushed
GDB also silently ignores if recording is disabled on threads that were not
recorded. This shouldn't happen, either, since when stopping recording,
we only disable recording on threads that were recorded.
GDB further silently ignores if recording was not enabled by the
corresponding target method. Also this shouldn't happen since the target
is supposed to already throw an error if recording cannot be enabled.
This new error in btrace_enable catches cases where the target silently
failed to enable recording.
Throw an error in those cases.
This allows us to detect an actual issue more easily. It will be
addressed in the next patch.
gdb/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* btrace.c (btrace_enable): Throw an error on double enables and
when enabling recording fails.
(btrace_disable): Throw an error if the thread is not recorded.
In the record-btrace target, while replaying, we can only provide the PC
register. The btrace state is stored in the thread_info. So, when trying
to determine whether we are currently replaying, GDB calls
find_thread_ptid() to obtain the thread_info. It also asserts that we do
have a thread_info.
For new threads, libthread-db may fetch registers before the thread is
known to GDB. In this case, find_thread_ptid() returns nullptr and the
assertion fails.
Forward the fetch_registers request to the target beneath in that case.
gdb/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_target::fetch_registers): Forward
request if we do not have a thread_info.
gdb/testsuite/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/enable-new-thread.c: New test.
* gdb.btrace/enable-new-thread.exp: New file.
Consider the test-case from this patch, compiled with pthread support:
...
$ gcc gdb/testsuite/gdb.threads/killed-outside.c -lpthread -g
...
After running to all_started, we can print pid:
...
$ gdb a.out -ex "b all_started" -ex run -ex "delete 1" -ex "p pid"
...
Reading symbols from a.out...
Breakpoint 1 at 0x40072b: file killed-outside.c, line 29.
Starting program: /data/gdb_versions/devel/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77fc700 (LWP 3155)]
Thread 1 "a.out" hit Breakpoint 1, all_started () at killed-outside.c:29
29 }
$1 = 3151
(gdb)
...
If we then kill the inferior using an external SIGKILL:
...
(gdb) shell kill -9 3151
...
and subsequently continue:
...
(gdb) c
Continuing.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
<repeat>
...
gdb hangs repeating the same warning. Typing control-C no longer helps,
and we have to kill gdb.
This is a regression since commit 873657b9e8 "Preserve selected thread in
all-stop w/ background execution". The commit adds a
scoped_restore_current_thread typed variable restore_thread to
fetch_inferior_event, and the hang is caused by the constructor throwing an
exception.
Fix this by catching the exception in the constructor.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-21 Tom de Vries <tdevries@suse.de>
PR gdb/25471
* thread.c
(scoped_restore_current_thread::scoped_restore_current_thread): Catch
exception in get_frame_id.
gdb/testsuite/ChangeLog:
2020-04-21 Tom de Vries <tdevries@suse.de>
PR gdb/25471
* gdb.threads/killed-outside.c: New test.
* gdb.threads/killed-outside.exp: New file.
There was an existing jit-protocol.h defining common symbols needed for
JIT-supporting application, however, it was only used by few tests.
Others redeclared the same symbols.
This unifies all tests to use jit-protocol.h
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-attach-pie.c: Use jit-protocol.h.
* gdb.base/jit-elf-main.c: Use jit-protocol.h.
* gdb.base/jit-reader-host.c: Use jit-protocol.h.
* gdb.base/jit-reader-simple-jit.c: Use jit-protocol.h.
* gdb.base/jit-protocol.h: Update definitions to match all usage
contexts.
Reorganizes how JIT related test files to be more clear what are related
to JIT reader system tests and what use JIT from ELF objfiles. Those two
approaches are quite different in GDB implementation and require very
different test setup. Keeping distinction clear at the file name level
makes it easier to maintain the testsuite.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base: Rename all jit related test and source files.
Fixes jit-reader test failures on systems that have more registers than
expected by the current condition.
On Intel i9-7920X the following extra registers are printed:
k0 0x0 0
k1 0x0 0
k2 0x0 0
k3 0x0 0
k4 0x0 0
k5 0x0 0
k6 0x0 0
k7 0x0 0
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-reader.exp: Relax register output check.
I recently learned that move constructors generally should be marked
"noexcept". This ensures that standard containers will move objects
when possible, rather than copy them.
This patch fixes the cases I could find. Note that implicitly-defined
or defaulted move constructors will automatically do what you'd
expect; that is, they are noexcept if all the members have noexcept
move constructors.
While doing this, I noticed a couple of odd cases where the move
constructor seemed to assume that the object being constructed could
have state requiring destruction. I've fixed these as well. See
completion_result and scoped_mmap.
gdb/ChangeLog
2020-04-20 Tom Tromey <tromey@adacore.com>
* python/python.c (struct gdbpy_event): Mark move constructor as
noexcept.
* python/py-tui.c (class gdbpy_tui_window_maker): Mark move
constructor as noexcept.
* completer.h (struct completion_result): Mark move constructor as
noexcept.
* completer.c (completion_result::completion_result): Use
initialization style. Don't call reset_match_list.
gdbsupport/ChangeLog
2020-04-20 Tom Tromey <tromey@adacore.com>
* scoped_mmap.h (scoped_mmap): Mark move constructor as noexcept.
Use initialization style. Don't call destroy.
* scoped_fd.h (class scoped_fd): Mark move constructor as
noexcept.
* gdb_ref_ptr.h (class ref_ptr): Mark move constructor as
noexcept.
This commit updates gdb.base/nested-subp[1-3].exp to determine
whether whether nested functions are supported using the function
support_nested_function_tests.
gdb/testsuite/ChangeLog:
* gdb.base/nested-subp1.exp: Use support_nested_function_tests.
* gdb.base/nested-subp2.exp: Likewise.
* gdb.base/nested-subp3.exp: Likewise.
Clang does not support nested functions, and there are no plans to
change this. This commit disables the three nested function tests
when using clang.
gdb/testsuite/ChangeLog:
* gdb.base/nested-subp1.exp: Disable test when using clang.
* gdb.base/nested-subp2.exp: Likewise.
* gdb.base/nested-subp3.exp: Likewise.
Clang fails to compile the above file, with the following error:
warning: using directive refers to implicitly-defined namespace 'std'
This prevents the following testcase from executing:
gdb.cp/exception.exp
Clang fails to compile the above file, with the following error:
warning: using the result of an assignment as a condition without
parentheses [-Wparentheses]
This prevents the following testcase from executing:
gdb.trace/tspeed.exp
Clang fails to compile the above file, with the following error:
warning: while loop has empty body [-Wempty-body]
This prevents the following testcases from executing:
gdb.base/jit.exp
gdb.base/jit-so.exp
When I removed init_w32_command_list, I weirdly neglected to see if it
was called anywhere else. This patch restores the function, which is
called from windows-nat.c. Sorry about the breakage.
Is it possible to have a windows-native gdb that isn't also using
windows-tdep?
Anyway, I'm checking this in.
gdb/ChangeLog
2020-04-18 Tom Tromey <tom@tromey.com>
* windows-tdep.c (init_w32_command_list)
(w32_prefix_command_valid): Restore.
(_initialize_windows_tdep): Call init_w32_command_list.
Add a fallback definition of PTRACE_ATTACH that is an alias of
PT_ATTACH. Change the 4th argument of ptrace(2) to 0 as it is
compatible with void * (Linux) and int (NetBSD) arguments.
Include <sys/types.h> for <sys/ptrace.h>.
gdb/testsuite/ChangeLog:
* gdb.base/attach-twice.c: Include "sys/types.h".
(PTRACE_ATTACH): Add fallback definition.
(main): Pass `0' to the 4th argument of `ptrace'.
Currently there are many prefix commands that do nothing but call
either help_list or cmd_show_list. I happened to notice that one such
call, for "set print type", used the wrong command list parameter,
causing incorrect output.
Rather than fix this bug in isolation, I decided to eliminate this
possibility by adding two new ways to add prefix commands, which
simply route the call to help_list or cmd_show_list, as appropriate.
This makes it impossible for a mismatch to occur.
In some cases, a bit of output was removed; however, I don't think
this output in general was very useful. It seemed redundant with
what's already printed by help_list. A representative example is this
hunk, removed from ada-lang.c:
- printf_unfiltered (_(\
-"\"set ada\" must be followed by the name of a setting.\n"));
This simplified the CLI style set/show commands quite a bit, and
allowed the deletion of a macro.
This also cleans up some unusual code in windows-tdep.c.
Tested on x86-64 Fedora 30. Note that I have no way to build the
go32-nat.c change.
gdb/ChangeLog
2020-04-17 Tom Tromey <tromey@adacore.com>
* auto-load.c (show_auto_load_cmd): Remove.
(auto_load_show_cmdlist_get): Use add_show_prefix_cmd.
* arc-tdep.c (_initialize_arc_tdep): Use add_show_prefix_cmd.
(maintenance_print_arc_command): Remove.
* tui/tui-win.c (tui_command): Remove.
(tui_get_cmd_list): Use add_basic_prefix_cmd.
* tui/tui-layout.c (tui_layout_command): Remove.
(_initialize_tui_layout): Use add_basic_prefix_cmd.
* python/python.c (user_set_python, user_show_python): Remove.
(_initialize_python): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* guile/guile.c (set_guile_command, show_guile_command): Remove.
(install_gdb_commands): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(info_guile_command): Remove.
* dwarf2/read.c (set_dwarf_cmd, show_dwarf_cmd): Remove.
(_initialize_dwarf2_read): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-style.h (class cli_style_option) <add_setshow_commands>:
Remove do_set and do_show parameters.
* cli/cli-style.c (set_style, show_style): Remove.
(_initialize_cli_style): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(cli_style_option::add_setshow_commands): Remove do_set and
do_show parameters.
(cli_style_option::add_setshow_commands): Use
add_basic_prefix_cmd, add_show_prefix_cmd.
(STYLE_ADD_SETSHOW_COMMANDS): Remove macro.
(set_style_name): Remove.
* cli/cli-dump.c (dump_command, append_command): Remove.
(srec_dump_command, ihex_dump_command, verilog_dump_command)
(tekhex_dump_command, binary_dump_command)
(binary_append_command): Remove.
(_initialize_cli_dump): Use add_basic_prefix_cmd.
* windows-tdep.c (w32_prefix_command_valid): Remove global.
(init_w32_command_list): Remove; move into ...
(_initialize_windows_tdep): ... here. Use add_basic_prefix_cmd.
* valprint.c (set_print, show_print, set_print_raw)
(show_print_raw): Remove.
(_initialize_valprint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* typeprint.c (set_print_type, show_print_type): Remove.
(_initialize_typeprint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* record.c (set_record_command, show_record_command): Remove.
(_initialize_record): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-cmds.c (_initialize_cli_cmds): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(info_command, show_command, set_debug, show_debug): Remove.
* top.h (set_history, show_history): Don't declare.
* top.c (set_history, show_history): Remove.
* target-descriptions.c (set_tdesc_cmd, show_tdesc_cmd)
(unset_tdesc_cmd): Remove.
(_initialize_target_descriptions): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* symtab.c (info_module_command): Remove.
(_initialize_symtab): Use add_basic_prefix_cmd.
* symfile.c (overlay_command): Remove.
(_initialize_symfile): Use add_basic_prefix_cmd.
* sparc64-tdep.c (info_adi_command): Remove.
(_initialize_sparc64_adi_tdep): Use add_basic_prefix_cmd.
* sh-tdep.c (show_sh_command, set_sh_command): Remove.
(_initialize_sh_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* serial.c (serial_set_cmd, serial_show_cmd): Remove.
(_initialize_serial): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* ser-tcp.c (set_tcp_cmd, show_tcp_cmd): Remove.
(_initialize_ser_tcp): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* rs6000-tdep.c (set_powerpc_command, show_powerpc_command)
(_initialize_rs6000_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* riscv-tdep.c (show_riscv_command, set_riscv_command)
(show_debug_riscv_command, set_debug_riscv_command): Remove.
(_initialize_riscv_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* remote.c (remote_command, set_remote_cmd): Remove.
(_initialize_remote): Use add_basic_prefix_cmd.
* record-full.c (set_record_full_command)
(show_record_full_command): Remove.
(_initialize_record_full): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* record-btrace.c (cmd_set_record_btrace)
(cmd_show_record_btrace, cmd_set_record_btrace_bts)
(cmd_show_record_btrace_bts, cmd_set_record_btrace_pt)
(cmd_show_record_btrace_pt): Remove.
(_initialize_record_btrace): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* ravenscar-thread.c (set_ravenscar_command)
(show_ravenscar_command): Remove.
(_initialize_ravenscar): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* mips-tdep.c (show_mips_command, set_mips_command)
(_initialize_mips_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* maint.c (maintenance_command, maintenance_info_command)
(maintenance_check_command, maintenance_print_command)
(maintenance_set_cmd, maintenance_show_cmd): Remove.
(_initialize_maint_cmds): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(show_per_command_cmd): Remove.
* maint-test-settings.c (maintenance_set_test_settings_cmd):
Remove.
(maintenance_show_test_settings_cmd): Remove.
(_initialize_maint_test_settings): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* maint-test-options.c (maintenance_test_options_command):
Remove.
(_initialize_maint_test_options): Use add_basic_prefix_cmd.
* macrocmd.c (macro_command): Remove
(_initialize_macrocmd): Use add_basic_prefix_cmd.
* language.c (set_check, show_check): Remove.
(_initialize_language): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* infcmd.c (unset_command): Remove.
(_initialize_infcmd): Use add_basic_prefix_cmd.
* i386-tdep.c (set_mpx_cmd, show_mpx_cmd): Remove.
(_initialize_i386_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* go32-nat.c (go32_info_dos_command): Remove.
(_initialize_go32_nat): Use add_basic_prefix_cmd.
* cli/cli-decode.c (do_prefix_cmd, add_basic_prefix_cmd)
(do_show_prefix_cmd, add_show_prefix_cmd): New functions.
* frame.c (set_backtrace_cmd, show_backtrace_cmd): Remove.
(_initialize_frame): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* dcache.c (set_dcache_command, show_dcache_command): Remove.
(_initialize_dcache): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cp-support.c (maint_cplus_command): Remove.
(_initialize_cp_support): Use add_basic_prefix_cmd.
* btrace.c (maint_btrace_cmd, maint_btrace_set_cmd)
(maint_btrace_show_cmd, maint_btrace_pt_set_cmd)
(maint_btrace_pt_show_cmd, _initialize_btrace): Use
add_basic_prefix_cmd, add_show_prefix_cmd.
* breakpoint.c (save_command): Remove.
(_initialize_breakpoint): Use add_basic_prefix_cmd.
* arm-tdep.c (set_arm_command, show_arm_command): Remove.
(_initialize_arm_tdep): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* ada-lang.c (maint_set_ada_cmd, maint_show_ada_cmd)
(set_ada_command, show_ada_command): Remove.
(_initialize_ada_language): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* command.h (add_basic_prefix_cmd, add_show_prefix_cmd): Declare.
gdb/testsuite/ChangeLog
2020-04-17 Tom Tromey <tromey@adacore.com>
* gdb.cp/maint.exp (test_help): Simplify multiple_help_body.
Update tests.
* gdb.btrace/cpu.exp: Update tests.
* gdb.base/maint.exp: Update tests.
* gdb.base/default.exp: Update tests.
* gdb.base/completion.exp: Update tests.
The only two potential users (NetBSD, OpenBSD) use svr4_auxv_parse.
gdb/ChangeLog:
* nbsd-nat.c (inf_ptrace_target::auxv_parse): Remove.
* nbsd-nat.h (inf_ptrace_target::auxv_parse): Likewise.
When a warning is displayed, it isn't clear to the user which file is
the cause of the warning. Add the filename in there. Remove the
"Failed to parse .idata section" part, since the .idata section is
always mentioned one way or another anyway, so it just contributes to
make the message longer than it needs to be.
gdb/ChangeLog:
* windows-tdep.c (is_linked_with_cygwin_dll): Add filename to
warning messages.
When loading the file C:\Windows\SysWOW64\msvcrt.dll, taken from a
Windows 10 system, into GDB, we get the following warning:
warning: Failed to parse .idata section: name's virtual address (0x0) is outside .idata section's range [0xb82b8, 0xb97f0[.
This uncovers an issue with how we parse the import table, part of the
.idata section. Right now, we assume that the import table is located
at the beginning of the section. That was the case in everything I had
tried so far, but this file is an example where that's not true.
We need to compute the offset of the import table within the .idata
section, and start there, instead of at the beginning of the .idata
section. Using the file mentioned above, this is the values we have to
work with:
A) bfd_section_vma (idata_section) 101b8000
B) Import table's virtual address b82b8
C) Image base 10100000
The virtual address that BFD returns us for the section has the image
base applied, so we need to subtract it first. The offset of the table
in the section is therefore:
B - (A - C)
This patch implements that.
gdb/ChangeLog:
* windows-tdep.c (is_linked_with_cygwin_dll): Consider case where
import table is not at beginning of .idata section.
Currently, while the program_space's ctor adds the new pspace to the
pspaces list, the destructor doesn't remove the pspace from the pspace
list. Instead, you're supposed to use delete_program_space, to both
remove the pspace from the list, and deleting the pspace.
This patch eliminates delete_program_space, and makes the pspace dtor
remove the deleted pspace from the pspace list itself, i.e., makes the
dtor do the mirror opposite of the ctor.
I found this helps with a following patch that will allocate a mock
program_space on the stack. It's easier to just let the regular dtor
remove the mock pspace from the pspace list than arrange to call
delete_program_space instead of the pspace dtor in that situation.
While at it, move the ctor/dtor intro comments to the header file, and
make the ctor explicit.
gdb/ChangeLog:
2020-04-16 Pedro Alves <palves@redhat.com>
* inferior.c (delete_inferior): Use delete operator directly
instead of delete_program_space.
* progspace.c (add_program_space): New, factored out from
program_space::program_space.
(remove_program_space): New, factored out from
delete_program_space.
(program_space::program_space): Remove intro comment. Rewrite.
(program_space::~program_space): Remove intro comment. Call
remove_program_space.
(delete_program_space): Delete.
* progspace.h (program_space::program_space): Make explicit. Move
intro comment here, adjusted.
(program_space::~program_space): Move intro comment here,
adjusted.
(delete_program_space): Remove.
Simon pointed out that the windows-nat sharing series broke the Cygwin
build. This patch fixes the problem, by moving the Cygwin-specific
code to a new handler function. This approach is taken because this
code calls find_pc_partial_function, which isn't available in
gdbserver.
gdb/ChangeLog
2020-04-16 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_access_violation): New
function.
* nat/windows-nat.h (handle_access_violation): Declare.
* nat/windows-nat.c (handle_exception): Move Cygwin code to
windows-nat.c. Call handle_access_violation.
gdbserver/ChangeLog
2020-04-16 Tom Tromey <tromey@adacore.com>
* win32-low.cc (windows_nat::handle_access_violation): New
function.
Consider the test-case added in this patch, with resulting dwarf:
...
Compilation Unit @ offset 0xc7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x64
Pointer Size: 8
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<d3> DW_AT_language : 2 (non-ANSI C)
<d4> DW_AT_name : imported_unit.c
<1><e4>: Abbrev Number: 3 (DW_TAG_base_type)
<e5> DW_AT_byte_size : 4
<e6> DW_AT_encoding : 5 (signed)
<e7> DW_AT_name : int
<1><eb>: Abbrev Number: 4 (DW_TAG_subprogram)
<ec> DW_AT_name : main
<f1> DW_AT_type : <0xe4>
<f5> DW_AT_external : 1
<1><f6>: Abbrev Number: 0
Compilation Unit @ offset 0xf7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x85
Pointer Size: 8
<0><102>: Abbrev Number: 2 (DW_TAG_compile_unit)
<103> DW_AT_language : 2 (non-ANSI C)
<104> DW_AT_name : <artificial>
<1><111>: Abbrev Number: 3 (DW_TAG_subprogram)
<112> DW_AT_abstract_origin: <0xeb>
<116> DW_AT_low_pc : 0x4004a7
<11e> DW_AT_high_pc : 0x4004b2
<1><126>: Abbrev Number: 0
...
When run with target board cc-with-gdb-index, we run into:
...
(gdb) break main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1 at 0x4004ab
(gdb) PASS: gdb.dwarf2/imported-unit-runto-main.exp: setting breakpoint at main
run
Starting program: /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/imported-unit-runto-main/imported-unit-runto-main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1, warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
0x00000000004004ab in main ()
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
(gdb) FAIL: gdb.dwarf2/imported-unit-runto-main.exp: running to main in runto
...
Looking at the .gdb_index section contents using objdump --dwarf=gdb_index, we
have:
...
CU table:
[ 0] 0x0 - 0x2d
[ 1] 0x2e - 0xa4
[ 2] 0xa5 - 0xc6
[ 3] 0xf7 - 0x126
[ 4] 0x127 - 0x2de
[ 5] 0x2df - 0x300
Address table:
00000000004004a7 00000000004004b2 4
Symbol table:
[489] main: 4 [global, function]
...
We see that both the main symbol, and main address range map to CU 4, which has
offset range 0x127 - 0x2de, while main actually is contained in CU 3 at offset
range 0xf7 - 0x126.
This is caused by this continue in write_gdbindex, which triggers for the PU:
...
/* CU of a shared file from 'dwz -m' may be unused by this main file.
It may be referenced from a local scope but in such case it does not
need to be present in .gdb_index. */
if (psymtab == NULL)
continue;
...
The continue causes the PU to be skipped in the CU table (we can see that the
PU offset range 0xc7-0xf6 is missing) but the references are not taking that
into account.
I've tried fixing this in the optimal way, by updating the references, but ran
into trouble when follow_die_offset tries to find the CU for the inter-CU
ref. Because the PU is missing from the CU table,
dwarf2_find_containing_comp_unit bisects to the wrong CU.
Fix this by not skipping the PU in the CU table.
Build and reg-tested on x86_64-linux, with native and target boards
cc-with-gdb-index, cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* dwarf2/index-write.c (write_gdbindex): Generate CU table entries for
CUs without psymtab.
gdb/testsuite/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* gdb.dwarf2/gdb-add-index.exp (add_gdb_index): Move ...
(ensure_gdb_index): and factor out and move ...
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): ... here.
* gdb.dwarf2/imported-unit-runto-main.exp: New file.
This commit fixes a compilation warning/error when building GDB
with Python 3.9:
g++ -x c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -DDNF_DEBUGINFO_INSTALL -I. -I../../gdb -I../../gdb/config -DLOCALEDIR="\"/usr/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/../include/opcode -I../bfd -I../../gdb/../bfd -I../../gdb/../include -I../libdecnumber -I../../gdb/../libdecnumber -I../../gdb/../gnulib/import -I../gnulib/import -DTUI=1 -I/usr/include/guile/2.0 -pthread -I/usr/include/python3.9 -I/usr/include/python3.9 -I../../gdb/.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wformat -Wformat-nonliteral -Wno-unused -Werror -c -o ser-tcp.o -MT ser-tcp.o -MMD -MP -MF ./.deps/ser-tcp.Tpo ../../gdb/ser-tcp.c
../../gdb/python/python.c: In function 'bool do_start_initialization()':
../../gdb/python/python.c:1621:23: error: 'void PyEval_InitThreads()' is deprecated [-Werror=deprecated-declarations]
1621 | PyEval_InitThreads ();
| ^
In file included from /usr/include/python3.9/Python.h:141,
from ../../gdb/python/python-internal.h:86,
from ../../gdb/python/python.c:92:
/usr/include/python3.9/ceval.h:132:37: note: declared here
132 | Py_DEPRECATED(3.9) PyAPI_FUNC(void) PyEval_InitThreads(void);
| ^~~~~~~~~~~~~~~~~~
Information about the deprecated function can be found here:
https://docs.python.org/3.9/whatsnew/3.9.html#deprecated
Specifically, with regard to PyEval_InitThreads(), it says:
The PyEval_InitThreads() and PyEval_ThreadsInitialized() functions
are now deprecated and will be removed in Python 3.11. Calling
PyEval_InitThreads() now does nothing. The GIL is initialized by
Py_Initialize() since Python 3.7. (Contributed by Victor Stinner
in bpo-39877.)
I chose to disable the call with a #if test using PY_VERSION_HEX.
There is precedent for use of PY_VERSION_HEX; it's used in two places
in python-internal.h. I noticed that under certain circumstances
python-internal.h defines PyEval_InitThreads to be nothing, which
accomplishes the same thing. I considered doing something similar for
this case, but decided against it because, at some point in the future,
the presence of PyEval_InitThreads() without some explanation will be
confusing to a reader who won't be able to find PyEval_InitThreads in
the current (future for us) Python API. IMO, use of the #if along
with an accompanying comment seemed more straightforward.
gdb/ChangeLog:
* python/python.c (do_start_initialization): Don't call
PyEval_InitThreads for Python 3.9 and beyond.
Change-Id: I0679fc10b6b76761a99538568f13188c6d8014e0
With test-case gdb.base/maint-expand-symbols-header-file.exp and target board
cc-with-gdb-index, we have:
...
FAIL: gdb.base/maint-expand-symbols-header-file.exp: \
verify no symtabs are expanded
...
By default, with partial symbols, we find the main function in the partial
symbols, and derive the initial language setting from that, without expanding
any psymtab.
But that doesn't work with the indices, because the indices don't store the
language with the symbols. So instead, the main psymtab is expanded to get
the language of main, which causes the FAIL.
Fix this by manually setting the language.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
* gdb.base/maint-expand-symbols-header-file.exp: Set language before
loading exec.
While debugging a bug on Windows, I noticed that windows-nat.c is not
sending its debugging output to gdb_stdlog. This is unfortunate
because it means that "set logging debugredirect" doesn't work
properly.
This patch fixes the problem by changing windows-nat.c to use
debug_printf.
Note that get_windows_debug_event also writes one debugging message
unconditionally. It isn't clear to me if this really ought to use
DEBUG_EVENTS or not, since it seems like perhaps it is intended to
note an unexpected event occurring. So, I didn't change this.
I'm checking this in.
gdb/ChangeLog
2020-04-15 Tom Tromey <tromey@adacore.com>
* windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM)
(DEBUG_EXCEPT): Use debug_printf.
Commit:
commit 724fd9ba43
Date: Mon Jan 27 17:37:20 2020 +0000
gdb: Restructure the completion_tracker class
caused the completion hash table to become corrupted if the table ever
needed to grow beyond its original size of 200 elements.
The hash table stores completion_tracker::completion_hash_entry
objects, but hashes them based on their name, which is only one field
of the object.
When possibly inserting a new element we compute the hash with
htab_hash_string of the new elements name, and then lookup matching
elements using htab_find_slot_with_hash. If there's not matching
element we create a completion_hash_entry object within the hash
table.
However, when we allocate the hash we pass htab_hash_string to
htab_create_alloc as the hash function, and this is not OK. This
means that when the hash table needs to grow, existing elements within
the hash are re-hashed by passing the completion_hash_entry pointer to
htab_hash_string, which obviously does not do what we expect.
The solution is to create a new hash function that takes a pointer to
a completion_hash_entry, and then calls htab_hash_string on the name
of the entry only.
This regression was spotted when running the gdb.base/completion.exp
test on the aarch64 target.
gdb/ChangeLog:
* completer.c (class completion_tracker::completion_hash_entry)
<hash_name>: New member function.
(completion_tracker::discard_completions): New callback to hash a
completion_hash_entry, pass this to htab_create_alloc.
gdb/testsuite/ChangeLog:
* gdb.base/many-completions.exp: New file.
It seems Cygwin's realpath() can fail on certain DLLs (apparently some
AV software prevent it working on it's DLLs; See [1], [2]). Warn rather
than stopping with an error if that occurs.
Based on an original patch from Tim Chick.
[1] https://cygwin.com/ml/cygwin/2014-08/msg00401.html
[2] https://cygwin.com/ml/cygwin/2015-11/msg00353.html
gdb/ChangeLog:
2016-01-20 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (windows_make_so): Warn rather than stopping with
an error if realpath() fails.
Building gdb-9.1 on a system that has an older version of makeinfo
(4.8) shows the following warnings:
-----------------
make[4]: Entering directory '/home/tester/gdb-9.1/build/gdb/doc'
makeinfo --split-size=5000000 --split-size=5000000 -I
../../../gdb/doc/../../readline/readline/doc -I ../../../gdb/doc/../mi
-I ../../../gdb/doc \
-o gdb.info ../../../gdb/doc/gdb.texinfo
../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character ] in @var.
../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character [ in @var.
../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character ] in @var.
../../../gdb/doc//python.texi:3297: warning: `.' or `,' must follow
@xref, not `A'.
make[4]: Leaving directory '/home/tester/gdb-9.1/build/gdb/doc'
-----------------
These are thrown by expressions like `@var{[host]}`, intended to
produce `[HOST]`.
In that context this should instead be changed to `[@var{host}]`, which
has the same effect but without the warnings.
As for the warning in `python.texi`, there's period missing at the end
of one `@xref{}` clause. Added.
gdb/doc/ChangeLog:
2020-04-15 Artur Shepilko <nomadbyte@gmail.com>
* gdb.texinfo: Transform @var{[host]} to [@var{host}]; this
clears makeinfo warnings.
* python.texi: Add a missing period trailing an @xref{} clause;
this clears a makeinfo warning.
Output based on FreeBSD with the following changes:
- "utime+stime, children" merged from "utime, children" and
"stime, children".
- "Minor faults, children", "Major faults, children",
"Virtual memory size" removed as not available in a direct
equivalent.
No new values missing or skipped in FreeBSD are printed, although
there is a long list of potential candiates.
gdb/ChangeLog:
* nbsd-nat.c (nbsd_pid_to_kinfo_proc2): New.
(nbsd_nat_target::info_proc): Add do_status.
[ The test-case requires commit c1a66c0629 "[gdb] Expand symbolless symtabs
using maint expand-symtabs". ]
Consider the debug info for the test-case included in this patch. It consists
of a PU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<1><d3>: Abbrev Number: 0
...
imported by a CU:
...
<0><df>: Abbrev Number: 2 (DW_TAG_compile_unit)
<e0> DW_AT_language : 2 (non-ANSI C)
<e1> DW_AT_stmt_list : 0xe9
<1><e5>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e6> DW_AT_import : <0xd2> [Abbrev Number: 2]
<1><ea>: Abbrev Number: 0
...
and the CU has a dw2-symtab-includes.h file in the .debug_line file name
table:
...
The Directory Table (offset 0x101):
1 /data/gdb_versions/devel/src/gdb/testsuite/gdb.dwarf2
The File Name Table (offset 0x138):
Entry Dir Time Size Name
1 1 0 0 dw2-symtab-includes.h
...
After expanding all symtabs, we can see the CU listed in the user field of the
PU, and vice-versa the PU listed in the includes of the CU:
...
$ gdb.sh -batch \
-iex "set language c" \
outputs/gdb.dwarf2/dw2-symtab-includes/dw2-symtab-includes \
-ex "maint expand-symtabs" \
-ex "maint info symtabs"
...
{ ((struct compunit_symtab *) 0x394dd60)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x394dea0)
user ((struct compunit_symtab *) 0x394dba0)
}
{ ((struct compunit_symtab *) 0x394dba0)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x394dd10)
user ((struct compunit_symtab *) (null))
( includes
((struct compunit_symtab *) 0x394dd60)
)
}
...
But if we instead only expand the symtab for the dw2-symtab-includes.h file,
the includes and user links are gone:
...
$ gdb -batch \
-iex "set language c" \
outputs/gdb.dwarf2/dw2-symtab-includes/dw2-symtab-includes \
-ex "maint expand-symtabs dw2-symtab-includes.h" \
-ex "maint info symtabs"
...
{ ((struct compunit_symtab *) 0x2728210)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x2728350)
user ((struct compunit_symtab *) (null))
}
{ ((struct compunit_symtab *) 0x2728050)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x27281c0)
user ((struct compunit_symtab *) (null))
}
...
The includes are calculated by process_cu_includes in gdb/dwarf2/read.c.
In the case of expanding all symtabs:
- the CU partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_psymtab::read_symtab
- dwarf2_psymtab::read_symtab calls dwarf2_psymtab::expand_psymtab
- dwarf2_psymtab::read_symtab calls process_cu_includes, and we have the
includes
In the case of expanding the symtab for dw2-symtab-includes.h:
- the dw2-symtab-includes.h partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_include_psymtab::read_symtab
- dwarf2_include_psymtab::read_symtab calls
dwarf2_include_psymtab::expand_psymtab
- dwarf2_include_psymtab::expand_psymtab calls
partial_symtab::expand_dependencies
- partial_symtab::expand_dependencies calls dwarf2_psymtab::expand_psymtab
for the CU partial symtab
- the CU partial symtab is expanded using dwarf2_psymtab::expand_psymtab
- process_cu_includes is never called
Fix this by making sure in dwarf2_include_psymtab::read_symtab that
read_symtab is called for the CU partial symtab.
Tested on x86_64-linux, with native, and target board cc-with-dwz and
cc-with-dwz-m.
In addition, tested test-case with target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/ChangeLog:
2020-04-14 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/25718
* psympriv.h (struct partial_symtab::read_symtab)
(struct partial_symtab::expand_psymtab)
(struct partial_symtab::read_dependencies): Update comments.
* dwarf2/read.c (struct dwarf2_include_psymtab::read_symtab): Call
read_symtab for includer.
(struct dwarf2_include_psymtab::expand_psymtab): Assert false.
(struct dwarf2_include_psymtab::readin_p): Call readin_p () for includer.
(struct dwarf2_include_psymtab::m_readin): Remove.
(struct dwarf2_include_psymtab::includer): New member function.
(dwarf2_psymtab::expand_psymtab): Assert !readin.
gdb/testsuite/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25718
* gdb.dwarf2/dw2-symtab-includes.exp: New file.
Consider this test-case, consisting of header file hello.h:
...
inline static const char*
foo (void)
{
return "foo";
}
...
and source file hello.c:
...
int
main (void)
{
printf ("hello: %s\n", foo ());
return 0;
}
...
compiled with -g:
...
$ gcc hello.c -g
...
When trying to expand the partial symtab for hello.h:
...
$ gdb -batch \
-iex "set language c" \
a.out \
-ex "maint expand-symtabs hello.h" \
-ex "maint info psymtabs"
...
we in fact find that the partial symtab for hello.h (and corresponding
includer partial symtab hello.c) have not been expanded:
...
{ psymtab hello.h ((struct partial_symtab *) 0x27cf070)
readin no
...
{ psymtab hello.c ((struct partial_symtab *) 0x2cf09e0)
readin no
...
This is due to the recursively_search_psymtabs call in
psym_expand_symtabs_matching:
...
if (recursively_search_psymtabs (ps, objfile, domain,
lookup_name, symbol_matcher))
...
which always returns false for symbolless partial symtabs.
The same problem occurs with CUs where the dwarf is generated by gas
--gdwarf-2 for a foo.S: if we read such a test-case with -readnow, we'll have
a symbolless symtab for foo.S. But if we read the test-case with partial
symtabs, and expand those using "maint expand-symtabs", the foo.S psymtab
remains unexpanded.
Fix this by passing a NULL symbol_matcher and lookup_name to
expand_symtabs_matching in maintenance_expand_symtabs, and skipping the call
to recursively_search_psymtabs if symbol_matcher == NULL and
lookup_name == NULL.
Build and tested on x86_64-linux, with native.
In addition, tested test-case with target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25720
* symmisc.c (maintenance_expand_symtabs): Call expand_symtabs_matching
with NULL symbol_matcher and lookup_name.
* psymtab.c (psym_expand_symtabs_matching): Handle NULL symbol_matcher
and lookup_name.
* dwarf2/read.c (dw2_expand_symtabs_matching)
(dw2_debug_names_expand_symtabs_matching): Same.
* symfile.h (struct quick_symbol_functions::expand_symtabs_matching):
Make lookup_name a pointer. Update comment.
* symtab.c (global_symbol_searcher::expand_symtabs): Handle
lookup_name being a pointer.
* symfile.c (expand_symtabs_matching): Same.
* symfile-debug.c (debug_qf_expand_symtabs_matching): Same.
* linespec.c (iterate_over_all_matching_symtabs): Same.
gdb/testsuite/ChangeLog:
2020-04-14 Tom de Vries <tdevries@suse.de>
PR symtab/25720
* gdb.base/maint-expand-symbols-header-file.c: New test.
* gdb.base/maint-expand-symbols-header-file.exp: New file.
* gdb.base/maint-expand-symbols-header-file.h: New test.
Every time I write a test making use of the DWARF assembler I end up
copying in the function get_func_info. Duplicating code is bad, so
lets put this function into lib/dwarf.exp and remove all of the
duplicates.
There should be no changes in the testsuite behaviour after this
commit.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-many-frames.exp (get_func_info): Delete.
* gdb.dwarf2/dw2-inline-small-func.exp: Pass options to
get_func_info.
(get_func_info): Delete.
* gdb.dwarf2/dw2-is-stmt-2.exp (get_func_info): Delete.
* gdb.dwarf2/dw2-is-stmt.exp (get_func_info): Delete.
* lib/dwarf.exp (get_func_info): New function.
This patch splits out some gdb-specific code from event-loop, into new
files async-event.[ch]. Strictly speaking this code could perhaps be
put into gdbsupport/, but because gdbserver does not currently use it,
it seemed better, for size reasons, to split it out.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* tui/tui-win.c: Include async-event.h.
* remote.c: Include async-event.h.
* remote-notif.c: Include async-event.h.
* record-full.c: Include async-event.h.
* record-btrace.c: Include async-event.h.
* infrun.c: Include async-event.h.
* event-top.c: Include async-event.h.
* event-loop.h: Move some declarations to async-event.h.
* event-loop.c: Don't include ser-event.h or top.h. Move some
code to async-event.c.
* async-event.h: New file.
* async-event.c: New file.
* Makefile.in (COMMON_SFILES): Add async-event.c.
(HFILES_NO_SRCDIR): Add async-event.h.
Code in gdbsupport can't call gdb_flush, so this introduces a new
"flush_streams" function that must be supplied by the client.
Note that the similar gdb_flush_out_err exists, but it isn't defined
in quite the same way, so it wasn't clear to me whether the two could
be merged.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* utils.c (flush_streams): New function.
* event-loop.c (gdb_wait_for_event): Call flush_streams.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* errors.h (flush_streams): Declare.
Change event-loop.c to avoid printf_unfiltered in favor of warning.
warning is aleady available to code in gdbsupport/.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.c (handle_file_event): Use warning, not
printf_unfiltered.
Include <chrono> in event-loop.c, because it is used there. Currently
it is included indirectly, but after the subsequent patches this will
no longer be the case.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.c: Include <chrono>.
This moves gdb_select.h to gdbsupport/, so it can be used by other
code there.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* gdb_select.h: Move to ../gdbsupport/.
* event-loop.c: Update include path.
* top.c: Update include path.
* ser-base.c: Update include path.
* ui-file.c: Update include path.
* ser-tcp.c: Update include path.
* guile/scm-ports.c: Update include path.
* posix-hdep.c: Update include path.
* ser-unix.c: Update include path.
* gdb_usleep.c: Update include path.
* mingw-hdep.c: Update include path.
* inflow.c: Update include path.
* infrun.c: Update include path.
* event-top.c: Update include path.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* gdb_select.h: Move from ../gdb/.
gdb_select.h and the event loop require some configure checks, so this
moves the needed checks to common.m4 and updates the configure
scripts.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Remove checks that are now in GDB_AC_COMMON.
gdbserver/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* config.in: Rebuild.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* config.in, configure: Rebuild.
* common.m4 (GDB_AC_COMMON): Check for poll.h, sys/poll.h,
sys/select.h, and poll.
A subsequent patch is going to move event-loop.c to gdbsupport. In a
review of an earlier version of this series, Pedro pointed out that
the resulting code would be cleaner if start_event_loop were not
shared -- because gdb and gdbserver have some different needs here --
and so this moves start_event_loop to main.c. Because the only caller
is there, it is also now static.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* event-loop.h (start_event_loop): Don't declare.
* event-loop.c (start_event_loop): Move...
* main.c (start_event_loop): ...here. Now static.
When running test-case gdb.ada/catch_ex.exp using system gnatmake, gnatmake is
invoked like this:
...
Executing on host: \
gnatmake foo.adb -gnata -f -Isrc/gdb/testsuite/gdb.ada/catch_ex -g -lm \
-o outputs/gdb.ada/catch_ex/foo
...
When I try to use a more recent gnatmake, by mocking up a combined build:
...
$ ls -la build/gcc/
lrwxrwxrwx gfortran -> /usr/bin/gfortran-10
lrwxrwxrwx gnatbind -> /usr/bin/gnatbind-10
lrwxrwxrwx gnatlink -> /usr/bin/gnatlink-10
lrwxrwxrwx gnatmake -> /usr/bin/gnatmake-10
lrwxrwxrwx xg++ -> /usr/bin/g++-10
lrwxrwxrwx xgcc -> /usr/bin/gcc-10
...
gnatmake is invoked like this:
...
Executing on host: \
/data/gdb_versions/devel/build/gcc/gnatmake \
-I/data/gdb_versions/devel/build/gcc/ada/rts \
--GCC=/data/gdb_versions/devel/build/gcc/xgcc \
--GNATBIND=/data/gdb_versions/devel/build/gcc/gnatbind \
--GNATLINK=/data/gdb_versions/devel/build/gcc/gnatlink \
-cargs -B/data/gdb_versions/devel/build/gcc \
-largs --GCC=/data/gdb_versions/devel/build/gcc/xgcc \
-B/data/gdb_versions/devel/build/gcc \
-margs foo.adb -gnata -f -Isrc/gdb/testsuite/gdb.ada/catch_ex -g -lm \
-o outputs/gdb.ada/catch_ex/foo
...
This is set up by this bit in find_gnatmake in
/usr/share/dejagnu/libgloss.exp:
...
if {![is_remote host]} {
set file [lookfor_file $tool_root_dir gnatmake]
if { $file == "" } {
set file [lookfor_file $tool_root_dir gcc/gnatmake]
}
if { $file != "" } {
set root [file dirname $file]
set CC "$file -I$root/ada/rts --GCC=$root/xgcc \
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink \
-cargs -B$root \
-largs --GCC=$root/xgcc -B$root -margs"
} else {
...
However, when running test-case gdb.ada/catch_ex_std.exp using the mockup
combined build, we get:
...
Executing on host: \
/data/gdb_versions/devel/build/gcc/gnatlink foo \
-Wl,-rpath,\$ORIGIN -Wl,-lsome_package
b~foo.adb:26:79: "SS_Stack" not declared in "Secondary_Stack"^M
b~foo.adb:26:89: incorrect constraint for this kind of type^M
b~foo.adb:121:56: "Runtime_Default_Sec_Stack_Size" not declared in "Parameters"^M
FAIL: gdb.ada/catch_ex_std.exp: gnatlink foo
...
The problem is caused by the fact that the test uses gnatlink directly
rather than using gnatmake. The invoked gnatlink (which is gnatlink-10) calls
gcc-7, which are incompatible (see gcc PR86211). This problem doesn't occur
with gnatmake because there the gcc to use is passed as an argument to
gnatlink.
Fix this by adding the -largs bit from find_gnatmake in find_ada_tool, for the
case that $tool == gnatlink.
Tested on x86_64-linux, with system gcc, and gcc-10.
gdb/testsuite/ChangeLog:
2020-04-13 Tom de Vries <tdevries@suse.de>
* lib/ada.exp (find_ada_tool): Pass --GCC and -B to gnatlink, similar
to what find_gnatmake does.
Add nbsd_pid_to_cwd() to query the program current directory.
gdb/ChangeLog:
* nbsd-nat.c (nbsd_pid_to_cwd): Add.
(nbsd_nat_target::info_proc): Add do_cwd.
Define nbsd_nat_target::find_memory_regions and
nbsd_nat_target::info_proc. info_proc handles as of now only
the "mappings" command.
Define a local static function kinfo_get_vmmap() that reads
the process memory layout of a specified process.
kinfo_get_vmmap() wraps the sysctl(3) call.
nbsd-tdep.c defines now utility functions for printing the
process memory layout:
* nbsd_info_proc_mappings_header()
* nbsd_vm_map_entry_flags()
* nbsd_info_proc_mappings_entry()
gdb/ChangeLog:
* nbsd-nat.c; Include "nbsd-tdep.h" and "gdbarch.h".
* nbsd-nat.c (nbsd_nat_target::find_memory_regions)
(nbsd_nat_target::info_proc): New functions.
* nbsd-nat.c (kinfo_get_vmmap): New function.
* nbsd-nat.c (nbsd_nat_target::info_proc) Use
nbsd_info_proc_mappings_header and nbsd_info_proc_mappings_entry.
* nbsd-tdep.c (nbsd_info_proc_mappings_header)
(nbsd_info_proc_mappings_entry, nbsd_vm_map_entry_flags): New
functions.
* nbsd-tdep.c (KINFO_VME_PROT_READ, KINFO_VME_PROT_WRITE)
(KINFO_VME_PROT_EXEC, KINFO_VME_FLAG_COW)
(KINFO_VME_FLAG_NEEDS_COPY, KINFO_VME_FLAG_NOCOREDUMP)
(KINFO_VME_FLAG_PAGEABLE, KINFO_VME_FLAG_GROWS_UP)
(KINFO_VME_FLAG_GROWS_DOWN): New.
gdb version 9.1, built with clang 8.0.0 on Ubuntu 18.04 (x86_64);
--enable-ubsan (for clang's undefined behavior sanitizer)
Executing command; `maint selftest copy_bitwise` bombs in runtime error:
../../gdb/utils.c:3432:28: runtime error: left shift of negative value -1
Closer look reveals the offending shift: `(~0 << nbits)`, apparently 0
is treated as signed int, resulting in negative complement. Explicitly
stating it unsigned 0U fixes it and the `copy_bitwise` test passes
ok.
Sometimes, get_msymbol_address can cause infinite recursion, leading
to a crash. This was reported previously here:
https://sourceware.org/pipermail/gdb-patches/2019-November/162154.html
A user on irc reported this as well, and with his help and the help of
a friend of his, we found that the problem occurred because, when
reloading a separate debug objfile, the objfile would lose the
OBJF_MAINLINE flag. This would cause some symbols from this separate
debug objfile to be marked "maybe_copied" -- but then
get_msymbol_address could find the same symbol and fail as reported.
This patch fixes the bug by preserving OBJF_MAINLINE.
No test case, unfortunately, because I could not successfully make
one.
gdb/ChangeLog
2020-04-10 Tom Tromey <tromey@adacore.com>
* symfile.c (symbol_file_add_separate): Preserve OBJF_MAINLINE.
get_symbol_address and get_msymbol_address call
lookup_minimal_symbol_linkage, which iterates over the separate debug
files of the objfile that is passed in.
This means that if these functions pass in a separate debug objfile,
then they are doing unnecessary work.
This patch avoids the extra work by skipping separate debug objfiles
in the loops.
gdb/ChangeLog
2020-04-10 Tom Tromey <tromey@adacore.com>
* symtab.c (get_symbol_address, get_msymbol_address): Skip
separate debug files.
The new code regarding pending stops only checks for EXCEPTION_BREAKPOINT,
but for WOW64 processes STATUS_WX86_BREAKPOINT is necessary as well.
Also, ignore_first_breakpoint is used now in nat/windows-nat.c as well,
but was not available there.
gdb/ChangeLog:
2020-04-10 Hannes Domani <ssbssa@yahoo.de>
* nat/windows-nat.c (STATUS_WX86_BREAKPOINT, STATUS_WX86_SINGLE_STEP):
Move to...
* nat/windows-nat.h (STATUS_WX86_BREAKPOINT, STATUS_WX86_SINGLE_STEP):
... here.
* windows-nat.c (windows_nat_target::get_windows_debug_event):
Check for STATUS_WX86_BREAKPOINT.
(windows_nat_target::wait): Same.
When running test-case gdb.base/style.exp with target board readnow, we run
into:
...
FAIL: gdb.base/style.exp: filename is styled when loading symbol file
...
The problem is that with -readnow, an extra "Expanding full symbols" message
is generated:
...
(gdb) file $file^M
Reading symbols from $file...^M
Expanding full symbols from $file...^M
(gdb) FAIL: gdb.base/style.exp: filename is styled when loading symbol file
...
and the test does not expect this message.
Fix this by expecting the additional message for -readnow.
gdb/testsuite/ChangeLog:
2020-04-10 Tom de Vries <tdevries@suse.de>
* gdb.base/style.exp: Expect "Expanding full symbols" message for
-readnow.
Consider the test-case gdb.base/async.exp. Using the executable, I run to
main, and land on a line advertised as line 26:
...
$ gdb outputs/gdb.base/async/async -ex start
Reading symbols from outputs/gdb.base/async/async...
Temporary breakpoint 1 at 0x4004e4: file gdb.base/async.c, line 26.
Starting program: outputs/gdb.base/async/async
Temporary breakpoint 1, main () at gdb.base/async.c:26
26 y = foo ();
...
But actually, the line turns out to be line 28:
...
$ cat -n gdb.base/async.c
...
26 y = 2;
27 z = 9;
28 y = foo ();
...
This is caused by the following: the python colorizer initializes the lexer
with default options (no second argument to get_lexer_for_filename):
...
def colorize(filename, contents):
# Don't want any errors.
try:
lexer = lexers.get_lexer_for_filename(filename)
formatter = formatters.TerminalFormatter()
return highlight(contents, lexer, formatter)
...
which include option stripnl=True, which strips leading and trailing newlines.
This causes the python colorizer to strip the two leading newlines of async.c.
Fix this by initializing the lexer with stripnl=False.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-10 Tom de Vries <tdevries@suse.de>
PR cli/25808
* python/lib/gdb/__init__.py: Initialize lexer with stripnl=False.
gdb/testsuite/ChangeLog:
2020-04-10 Tom de Vries <tdevries@suse.de>
PR cli/25808
* gdb.base/style.c: Add leading newlines.
* gdb.base/style.exp: Use gdb_get_line_number to get specific lines.
Check listing of main's one-line body.
This reverts the following commit partially:
commit 64dc2d4bd2
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Thu Mar 12 11:52:34 2020 +0100
Fix an undefined behavior in record_line
Additionally do not completely remove symbols
at the same PC than the end marker, instead
make them non-is-stmt breakpoints.
We keep the undefined behavoir fix,
but have to restore the original behavior
regarding deletion of the line entries.
2020-04-09 Bernd Edlinger <bernd.edlinger@hotmail.de>
revert partially:
2020-04-01 Bernd Edlinger <bernd.edlinger@hotmail.de>
* buildsym.c (record_line): Fix undefined behavior and preserve
lines at eof.
NetBSD and OpenBSD always use an int to store the type as
defined in the SVR4 psABI specifications rather than long
as assumed by the default parser.
Define svr4_auxv_parse() that shares code with default_auxv_parse().
Remove obsd_auxv_parse() and switch OpenBSD to svr4_auxv_parse().
Remove not fully accurate comment from obsd-tdep.c.
Use svr4_auxv_parse() on NetBSD.
gdb/ChangeLog:
* auxv.h (svr4_auxv_parse): New.
* auxv.c (default_auxv_parse): Split into default_auxv_parse
and generic_auxv_parse.
(svr4_auxv_parse): Add.
* obsd-tdep.c: Include "auxv.h".
(obsd_auxv_parse): Remove.
(obsd_init_abi): Remove comment.
(obsd_init_abi): Change set_gdbarch_auxv_parse passed argument
from `obsd_auxv_parse' to `svr4_auxv_parse'.
* nbsd-tdep.c: Include "auxv.h".
(nbsd_init_abi): Call set_gdbarch_auxv_parse.
Now that last_wait_event is entirely handled in nat/windows-nat.c, it
can be made static.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (last_wait_event): Don't declare.
(wait_for_debug_event): Update comment.
* nat/windows-nat.c (last_wait_event): Now static.
This moves the wait_for_debug_event helper function to
nat/windows-nat.c, and changes gdbserver to use it.
wait_for_debug_event is a wrapper for WaitForDebugEvent that also sets
last_wait_event when appropriate. This is needed to properly handle
queued stops.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (wait_for_debug_event): Move to
nat/windows-nat.c.
* nat/windows-nat.h (wait_for_debug_event): Declare.
* nat/windows-nat.c (wait_for_debug_event): Move from
windows-nat.c. No longer static.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (win32_kill, get_child_debug_event): Use
wait_for_debug_event.
This introduces a new "fetch_pending_stop" function and changes gdb to
use it. This function removes the first matching pending stop from
the list of such stops.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (get_windows_debug_event): Use
fetch_pending_stop.
* nat/windows-nat.h (fetch_pending_stop): Declare.
* nat/windows-nat.c (fetch_pending_stop): New function.
This adds a couple of functions to nat/windows-nat.c and changes gdb
and gdbserver to use them. One function checks the list of pending
stops for a match (not yet used by gdbserver, but will be in a
subsequent patch); and the other is a wrapper for ContinueDebugEvent
that always uses the last "real" stop event.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_continue): Use matching_pending_stop and
continue_last_debug_event.
* nat/windows-nat.h (matching_pending_stop)
(continue_last_debug_event): Declare.
* nat/windows-nat.c (DEBUG_EVENTS): New define.
(matching_pending_stop, continue_last_debug_event): New
functions.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (child_continue): Call continue_last_debug_event.
Both gdb and gdbserver have a "handle_exception" function, the bulk of
which is shared between the two implementations. This patch arranges
for the entire thing to be moved into nat/windows-nat.c, with the
differences handled by callbacks. This patch introduces one more
callback to make this possible.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (MS_VC_EXCEPTION): Move to nat/windows-nat.c.
(handle_exception_result): Move to nat/windows-nat.h.
(DEBUG_EXCEPTION_SIMPLE): Remove.
(windows_nat::handle_ms_vc_exception): New function.
(handle_exception): Move to nat/windows-nat.c.
(get_windows_debug_event): Update.
(STATUS_WX86_BREAKPOINT, STATUS_WX86_SINGLE_STEP): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_ms_vc_exception): Declare.
(handle_exception_result): Move from windows-nat.c.
(handle_exception): Declare.
* nat/windows-nat.c (MS_VC_EXCEPTION, handle_exception)
(STATUS_WX86_SINGLE_STEP, STATUS_WX86_BREAKPOINT): Move from
windows-nat.c.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (handle_exception): Remove.
(windows_nat::handle_ms_vc_exception): New function.
(get_child_debug_event): Add "continue_status" parameter.
Update.
(win32_wait): Update.
windows-nat.c has a few "count" globals that don't seem to be used.
Possibly they were used for debugging at some point, but they no
longer seem useful to me. Because they get in the way of some code
sharing, this patch removes them.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (exception_count, event_count): Remove.
(handle_exception, get_windows_debug_event)
(do_initial_windows_stuff): Update.
This changes nat/windows-nat.h to declare handle_load_dll and
handle_unload_dll. The embedding application is required to implement
these -- while the actual code was difficult to share due to some
other differences between the two programs, sharing the declaration
lets a subsequent patch share more code that uses these as callbacks.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll)
(windows_nat::handle_unload_dll): Rename. No longer static.
* nat/windows-nat.h (handle_load_dll, handle_unload_dll):
Declare.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (windows_nat::handle_load_dll): Rename from
handle_load_dll. No longer static.
(windows_nat::handle_unload_dll): Rename from handle_unload_dll.
No longer static.
If 'complaint' is used in a namespace context, it will fail because
'stop_whining' is only declared at the top level. This patch fixes
this problem in a simple way, by moving the declaration of
'stop_whining' out of the macro and to the top-level.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* complaints.h (stop_whining): Declare at top-level.
(complaint): Don't declare stop_whining.
This changes gdbserver's implementation of handle_output_debug_string
to have the same calling convention as that of gdb. This allows for
sharing some more code in a subsequent patch.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_output_debug_string):
Rename. No longer static.
* nat/windows-nat.h (handle_output_debug_string): Declare.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (handle_output_debug_string): Add parameter. Change
return type.
(win32_kill, get_child_debug_event): Update.
