| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This crash was detected when using GDB with the valgrind gdbserver.
To reproduce:
valgrind sleep 10000
In another window:
gdb
target remote | vgdb
p printf("make sleep print something\n")
=>
terminate called after throwing an instance of 'gdb_exception_error'
Aborted
The problem is that the valgrind gdbserver does not allow to change
registers when the inferior is blocked in a system call.
GDB then raises an exception. The exception causes the destructor
of
typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
infcall_suspend_state_up;
to be called. This destructor itself tries to restore the value of
the registers, and fails similarly. We must catch the exception in
the destructor to avoid crashing GDB.
If the destructor encounters a problem, no warning is produced if
there is an uncaught exception, as in this case, the user will already
be informed of a problem via this exception.
With this change, no crash anymore, and all the valgrind 3.15 tests
pass succesfully.
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.h (struct infcall_suspend_state_deleter):
Catch exception in destructor to avoid crash.
|
|
gdb no longer needs common/queue.h, so this removes it.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* common/queue.h: Remove.
|
|
event-loop.c does not need to include common/queue.h, so this removes
it.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* event-loop.c: Don't include "common/queue.h".
|
|
This changes remote_notif_state::notif_queue to be a std::list and
updates all the uses.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* remote.c (remote_target): Use delete.
* remote-notif.h: Include <list>, not "common/queue.h".
(notif_client_p): Remove typedef.
(remote_notif_state): Add constructor, destructor, initializer.
<notif_queue>: Now a std::list.
(remote_notif_state_xfree): Don't declare.
* remote-notif.c (remote_notif_process, handle_notification)
(remote_notif_state_allocate): Update.
(~remote_notif_state): Rename from remote_notif_state_xfree.
|
|
This changes gdbserver to use std::list rather than common/queue.h for
event notifications.
gdb/gdbserver/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* server.c (struct vstop_notif): Derive from notif_event.
<base>: Remove.
(queue_stop_reply): Update.
(remove_all_on_match_ptid): Change type. Rewrite.
(discard_queued_stop_replies): Rewrite.
(in_queued_stop_replies_ptid): Change type.
(in_queued_stop_replies): Rewrite.
(notif_stop): Update.
(queue_stop_reply_callback): Update.
(captured_main): Don't call initialize_notif.
(push_stop_notification): Update.
* notif.c (notif_write_event, handle_notif_ack)
(notif_event_enque, notif_push): Update.
(notif_event_xfree, initialize_notif): Remove.
* notif.h (struct notif_event): Include <list>, not
"common/queue.h".
(struct notif_server) <queue>: Now a std::list.
(notif_event_p): Remove typedef.
(initialize_notif): Don't declare.
(struct notif_event): Add virtual destructor.
|
|
This changes objfile::static_links to be an htab_up, so that ~objfile
no longer has to explicitly destroy it.
Tested by the buildbot.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* symfile.c (reread_symbols): Update.
* objfiles.c (objfile_register_static_link)
(objfile_lookup_static_link): Update
(~objfile) Don't delete static_links.
* objfiles.h (struct objfile) <static_links>: Now an htab_up.
|
|
This changes copy_name to return a std::string, updating all the
callers. In some cases, an extra copy was removed. This also
required a little bit of constification.
Tested by the buildbot.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* type-stack.h (struct type_stack) <insert>: Constify string.
* type-stack.c (type_stack::insert): Constify string.
* gdbtypes.h (lookup_template_type): Update.
(address_space_name_to_int): Update.
* gdbtypes.c (address_space_name_to_int): Make space_identifier
const.
(lookup_template_type): Make name const.
* c-exp.y: Update rules.
(lex_one_token, classify_name, classify_inner_name)
(c_print_token): Update.
* p-exp.y: Update rules.
(yylex): Update.
* f-exp.y: Update rules.
(yylex): Update.
* d-exp.y: Update rules.
(lex_one_token, classify_name, classify_inner_name): Update.
* parse.c (write_dollar_variable, copy_name): Return std::string.
* parser-defs.h (copy_name): Change return type.
* m2-exp.y: Update rules.
(yylex): Update.
* go-exp.y (lex_one_token): Update.
Update rules.
(classify_unsafe_function, classify_packaged_name)
(classify_name, yylex): Update.
|
|
Allow disabling source-highlight dependency autodetection even
it exists in the system. More details on problem of automatic
dependencies:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
Noticed by Jeroen Roovers in https://bugs.gentoo.org/680238
* configure.ac: add --enable-source-highlight switch.
* configure: Regenerate.
* top.c (print_gdb_version): plumb --enable-source-highlight
status to "show configuration".
gdb/ChangeLog
2019-04-19 Sergei Trofimovich <siarheit@google.com>
* configure.ac: add --enable-source-highlight switch.
* configure: Regenerate.
* top.c (print_gdb_version): plumb --enable-source-highlight
status to "show configuration".
|
|
ada-lang.c is a bit too eager trying to decode unions in the Ada style
-- looking for discriminants and such. This causes crashes when
printing a non-Ada union in Ada mode, something that can easily happen
when printing a value from history or certain registers on AArch64.
This patch fixes the bug by changing ada-lang.c to only apply special
Ada treatment to types coming from an Ada CU. This in turn required a
couple of surprising changes.
First, some of the Ada code was already using HAVE_GNAT_AUX_INFO to
decide whether a type had already been fixed -- such types had
INIT_CPLUS_SPECIFIC called on them. This patch changes these spots to
use the "none" identifier instead.
This then required changing value_rtti_type to avoid changing the
language-specific object attached to an Ada type, which seems like a
good change regardless.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_is_variant_part, ada_to_fixed_type_1):
Check ADA_TYPE_P.
(empty_record, ada_template_to_fixed_record_type_1)
(template_to_static_fixed_type)
(to_record_with_fixed_variant_part): Use INIT_NONE_SPECIFIC.
* cp-abi.c (value_rtti_type): Check HAVE_CPLUS_STRUCT.
* gdbtypes.h (INIT_NONE_SPECIFIC, ADA_TYPE_P): New
macros.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/ptype_union.c: New file.
* gdb.ada/ptype_union.exp: New file.
|
|
PR symtab/24423 points out that control characters in a source file
cause a hang in the "list" command, a regression introduced by the
styling changes.
This patch, from the PR, fixes the bug. I've included a minimal
change to the "list" test that exercises this code.
I recall that this bug was discussed on gdb-patches, and I thought
there was a patch there as well, but I was unable to find it.
gdb/ChangeLog
2019-04-19 Ilya Yu. Malakhov <malakhov@mcst.ru>
PR symtab/24423:
* source.c (print_source_lines_base): Advance "iter" when a
control character is seen.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
PR symtab/24423:
* gdb.base/list0.h (foo): Add a control-l character.
|
|
This crash was detected when using GDB with the valgrind gdbserver.
To reproduce:
valgrind sleep 10000
In another window:
gdb
target remote | vgdb
p printf("make sleep print something\n")
=>
terminate called after throwing an instance of 'gdb_exception_error'
Aborted
The problem is that the valgrind gdbserver does not allow to change
registers when the inferior is blocked in a system call.
GDB then raises an exception. The exception causes the destructor
of
typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
infcall_suspend_state_up;
to be called. This destructor itself tries to restore the value of
the registers, and fails similarly. We must catch the exception in
the destructor to avoid crashing GDB.
If the destructor encounters a problem, no warning is produced if
there is an uncaught exception, as in this case, the user will already
be informed of a problem via this exception.
With this change, no crash anymore, and all the valgrind 3.15 tests
pass succesfully.
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.h (struct infcall_suspend_state_deleter):
Catch exception in destructor to avoid crash.
|
|
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-cmds.c (_initialize_cli_cmds): Move "shell" "!" alias
close to the add_com "shell".
|
|
When running break-probes.exp with native-gdbserver, we run into:
...
FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
FAIL: gdb.base/break-probes.exp: call (int) foo(23)
...
due to the fact that we're trying to match:
...
Inferior loaded /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\
/break-probes/break-probes-solib.so
...
using pattern:
...
Inferior loaded $sysroot$binfile_lib
...
which expands into:
...
Inferior loaded //data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\
/break-probes/break-probes-solib.so
...
Fix by setting sysroot to "" in local-board.exp.
Tested on x86_64-linux with native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* boards/local-board.exp: Set sysroot to "".
|
|
It seemed to me that process_stratum_target::stratum ought to be
"final".
Tested by rebuilding, let me know what you think.
gdb/ChangeLog
2019-04-18 Tom Tromey <tromey@adacore.com>
* process-stratum-target.h (class process_stratum_target)
<stratum>: Add "final".
|
|
When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:
...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
void x86_linux_update_debug_registers(lwp_info*): \
Assertion `lwp_is_stopped (lwp)' failed.
...
The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent. During target_detach
we call linux_nat_target::detach, which:
#1 - stops all the threads
#2 - waits for all the threads to be stopped
#3 - detaches all the threads
However, during the second step we run into this code in
stop_wait_callback:
...
/* If this is a vfork parent, bail out, it is not going to report
any SIGSTOP until the vfork is done with. */
if (inf->vfork_child != NULL)
return 0;
...
and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:
...
gdb_assert (lwp_is_stopped (lwp));
...
The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit. There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.
The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.
The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.
Tested on x86_64-linux, using native and native-gdbserver.
gdb/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.
|
|
After commit 35add35 ("gdb: Fix failure in gdb.base/complex-parts.exp
for x86-32"), dwarf2_init_complex_target_type can crash if "tt" is
nullptr. This patch avoids the problem by checking for this case.
No test case because I don't know a good way to write one; it was
found by an internal AdaCore test case that apparently uses a 16 bit
floating point type.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Check "tt"
against nullptr before use.
gdb/ChangeLog
2019-04-17 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dwarf2_init_complex_target_type): Check "tt"
against nullptr before use.
|
|
All debug output needs to go via debug functions to ensure it writes to the
correct output stream.
gdb/ChangeLog:
* nat/linux-waitpid.c (linux_debug): Call debug_vprintf.
gdb/gdbserver/ChangeLog:
* ax.c (ax_vdebug): Call debug_printf.
* debug.c (debug_write): New function.
* debug.h (debug_write): New declaration.
* linux-low.c (sigchld_handler): Call debug_write.
|
|
Add command line option to send all debug output to a given file.
Always default back to stderr.
Add matching monitor command. Add documentation.
gdb/doc/ChangeLog:
* gdb.texinfo
(Other Command-Line Arguments for gdbserver): Add debug-file
option.
(Monitor Commands for gdbserver): Likewise.
(gdbserver man): Likewise.
gdb/gdbserver/ChangeLog:
* debug.c (debug_set_output): New function.
(debug_vprintf): Send output to debug_file.
(debug_flush): Likewise.
* debug.h (debug_set_output): New declaration.
* server.c (handle_monitor_command): Add debug-file option.
(captured_main): Likewise.
|
|
A comment in debug.h (written in 2014) states: "We declare debug format
variables here, and debug_threads but no other debug content variables
(e.g., not remote_debug) because while this file is not currently used by
IPA it may be some day, and IPA may have its own set of debug content
variables".
This has resulted in remote_debug being declared in many .c/.h files
throughout gdbserver.
It would be much simplier to define it one place. The most logical place to
define it is in debug.h, surrounded by #define guards. If IPA is changed,
then at that point the variable can be moved elsewhere.
gdb/gdbserver/ChangeLog:
* debug.c (remote_debug): Add definition.
* debug.h (remote_debug): Add declaration.
* hostio.c (remote_debug): Remove declaration.
* remote-utils.c (struct ui_file): Likewise.
(remote_debug): Likewise.
* remote-utils.h (remote_debug): Likewise,
* server.c (remote_debug): Remove definition.
|
|
Some testsuite cases (gdb.cp/nsalias.exp for example) construct dwarf2
debug info for fake functions to test that this debug info is handled
correctly.
We currently get an error trying to read from an invalid address while
creating breakpoints for these fake functions.
Other targets allow creating breakpoints on invalid addresses, and
only error when GDB actually tries to insert the breakpoints.
In order to make RISC-V behave in the same way as other targets, this
commit makes the failure to read memory during breakpoint creation
non-fatal, we then expect to see a failure when GDB tries to insert
the breakpoint, just like other targets.
Tested with a riscv64-linux native testsuite run.
gdb/ChangeLog:
* riscv-tdep.c (riscv_breakpoint_kind_from_pc): Hanndle case where
code read might fail, assume 4-byte breakpoint in that case.
|
|
The AMD64 System V ABI specifies that when a function has a return type
classified as MEMORY, the caller provides space for the value and passes
the address to this space as the first argument to the function (before
even the "this" pointer). The classification of MEMORY is applied to
struct that are sufficiently large, or ones with unaligned fields.
The expression evaluator uses call_function_by_hand to call functions,
and the hand-built frame has to push arguments in a way that matches the
ABI of the called function. call_function_by_hand supports ABI-based
struct returns, based on the value of gdbarch_return_value, however on
AMD64 the implementation of the classifier incorrectly assumed that all
non-POD types (implemented as "all types with a base class") should be
classified as MEMORY and use the struct return.
This ABI mismatch resulted in issues when calling a function that returns
a class of size <16 bytes which has a base class, including issues such
as the "this" pointer being incorrect (as it was passed as the second
argument rather than the first).
This is now fixed by checking for field alignment rather than POD-ness,
and a testsuite is added to test expression evaluation for AMD64.
gdb/ChangeLog:
* amd64-tdep.c (amd64_classify_aggregate): Use cp_pass_by_reference
rather than a hand-rolled POD check when checking for forced MEMORY
classification.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-eval.cc: New file.
* gdb.arch/amd64-eval.exp: New file.
|
|
When writing registers to the kernel, check if regcache VG has been changed. If
so then update the thread's vector length, then write back the registers.
When reading registers from the kernel, ensure regcache VG register is updated.
The regcache registers should already be of the correct length.
Remove all the checks that error if the vector length has changed.
gdb/ChangeLog:
* aarch64-linux-nat.c (store_sveregs_to_thread): Set vector length.
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_set_vq): New function.
(aarch64_sve_regs_copy_to_reg_buf): Remove VG checks.
(aarch64_sve_regs_copy_from_reg_buf): Likewise.
* nat/aarch64-sve-linux-ptrace.h (aarch64_sve_set_vq): New declaration.
|
|
Override the thread_architecture method, similar to SPU. If the vector
length has changed, then find the arch using info, making sure the vector
length is passed down to the init routine.
In the init routine, ensure the arch has the correct vector length.
Example output. Program is stopped in thread 2, just before it calls prctl
to change the vector length
(gdb) info threads
Id Target Id Frame
1 Thread 0xffffbf6f4000 (LWP 3188) "sve_change" 0x0000ffffbf6ae130 in pthread_join ()
* 2 Thread 0xffffbf55e200 (LWP 3189) "sve_change" thread1 (arg=0xfeedface) at sve_change_size.c:28
(gdb) print $vg
$1 = 8
(gdb) print $z0.s.u
$2 = {623191333, 623191333, 623191333, 623191333, 0 <repeats 12 times>}
(gdb) n
29 int ret = prctl(PR_SVE_SET_VL, vl/2);
(gdb) n
30 printf ("Changed: ret\n", ret);
(gdb) print $vg
$4 = 4
(gdb) print $z0.s.u
$5 = {623191333, 623191333, 623191333, 623191333, 0, 0, 0, 0}
(gdb) thr 1
[Switching to thread 1 (Thread 0xffffbf6f4000 (LWP 3181))]
(gdb) print $vg
$6 = 8
(gdb) print $z0.s.u
$7 = {623191333, 623191333, 623191333, 623191333, 0 <repeats 12 times>}
gdb/ChangeLog:
* aarch64-linux-nat.c
(aarch64_linux_nat_target::thread_architecture): Add override.
* aarch64-tdep.c (aarch64_gdbarch_init): Ensure different tdesc for
each VQ.
|
|
Move the lookup_by_info to the top of the function to avoid unnecessarily
creating a new feature when the gdbarch already exists.
Add some additional cleanups that have no functional effect.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_gdbarch_init): Move gdbarch lookup.
|
|
The x86-32 ABI specifies 96-bit long double, this was causing a
failure on the test gdb.base/complex-parts.exp.
The problem is that GDB tries to find a builtin floating point type of
the correct size in order to reuse the name of that type as the name
for the components of the complex type being built.
Previously GDB was only aware of floating point types sized 32, 64, or
128 bits. This patch teaches GDB how to handle 96 bit floating point
type.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Handle complex
target types of size 96-bits, add some additional comments, and
check that the builtin type we found was the correct size.
|
|
gdb/ChangeLog:
2019-04-12 Eli Zaretskii <eliz@gnu.org>
* utils.c (prompt_for_continue): Don't restore the styling at the
end, as applied_style has the wrong value. This fixes styling in
long lists of file names that are interrupted by the "Continue?"
prompt.
|
|
The local board file ensures that the sysroot is always set to load
files from the local filesystem.
Add a gdbserver test to explicitly test the sysroot set to both the
remote target and the local filesystem.
gdb/testsuite/ChangeLog:
* gdb.server/sysroot.c: New test.
* gdb.server/sysroot.exp: New file.
* lib/gdbserver-support.exp (gdb_target_cmd): Add additional text
matching param.
|
|
The language_defn structure has an la_magic field, this used to be
used as a basic check that the language_defn structure had the
expected layout - at least the end of the structure was where we
expected it to be.
This feature only really makes sense if we imagine GDB dynamically
loading language support from dynamic libraries, where a version
mismatch might cause problems.
However, in current GDB language support is statically built into GDB,
and since this commit:
commit 47e77640be31fc1a4eb3718f594ed5fd0faff065
Date: Thu Jul 20 18:28:01 2017 +0100
Make language_def O(1)
the existing (if pointless) check of the la_magic field was removed.
There now appears to be no use of the la_magic field, and I propose
that we delete it.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_defn): Remove use of LANG_MAGIC.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
* language.h (struct language_defn): Remove la_magic field.
(LANG_MAGIC): Delete.
* m2-lang.c (m2_language_defn): Remove use of LANG_MAGIC.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* rust-lang.c (rust_language_defn): Likewise.
|
|
Make use of the type_align function and remove riscv_type_alignment as
it is no longer needed. I tested this against a number of RV32 and
RV64 targets, and I also ran the tests with an assertion in place
checking that the old riscv_type_alignment function gives the same
answer as the common type_align function - it does, and all the tests
still pass.
gdb/ChangeLog:
* riscv-tdep.c (riscv_type_align): New function.
(riscv_type_alignment): Delete.
(riscv_arg_location): Use 'type_align'.
(riscv_gdbarch_init): Register riscv_type_align gdbarch function.
|
|
The current code in gdbtypes.c:type_align incorrectly returns 0 as the
alignment for a structure containing only static fields. After this
patch the correct value of 1 is returned. The gdb.base/align.exp test
is extended to cover this case.
gdb/ChangeLog:
* gdbtypes.c (type_align): A struct with no non-static fields also
has alignment of 1.
gdb/testsuite/ChangeLog:
* gdb.base/align.exp: Extend test to cover structures containing
only static fields.
|
|
This commit resolves a large number of failures in the test script
gdb.base/infcall-nested-structs.exp which were caused by GDB (for
RISC-V) incorrectly handling empty C++ structures when preparing
arguments for a dummy call, or collecting a return value.
The issue is further complicated in that there was a bug in GCC, such
that in some cases GCC would generate incorrect code when passing a
small structure that contained empty sub-structures. This was fixed
in GCC trunk on 5-March-2019, so in order to see the best results with
this patch you'll need a recent version of GCC.
Anything that used to work should continue to work after this patch,
regardless of GCC version being used.
The fix in this commit is that GDB now pays more attention to the
offset of fields within a structure when preparing arguments as in C++
an empty structure has a non-zero size, this is an example:
struct s1 { struct s2 { } empty; int f; };
We previously assumed that 'f' was at offset 0 inside type 's1',
however this is not the case in C++ as 's2' has size 1, and with
alignment 'f' is likely at some even bigger offset inside 's1'.
gdb/ChangeLog:
* riscv-tdep.c (riscv_call_arg_complex_float): Fix offset of first
component to 0.
(riscv_struct_info::riscv_struct_info): Initialise m_offsets
member.
(riscv_struct_info::analyse): New implementation using new
analyse_inner member function.
(riscv_struct_info::field_offset): New member function.
(riscv_struct_info::m_offsets): New member variable.
(riscv_struct_info::analyse_inner): New private member function,
takes the old implementation of riscv_struct_info::analyse but
extended to track field offsets.
(riscv_call_arg_struct): Update the struct folding special cases
to handle cases where empty C++ structs, which are non-zero
length, are found.
(riscv_arg_location): Initialise the length of each location, a
non-zero length now indicates the location is in use.
(riscv_push_dummy_call): Allow for the first location having a
non-zero offset when setting up arguments.
(riscv_return_value): Likewise, but for return values.
|
|
I noticed that the "msg" variable in internal_vproblem could be
"const". This seems like an improvement because it can wind up in
rodata.
Tested by rebuilding.
gdb/ChangeLog
2019-04-11 Tom Tromey <tromey@adacore.com>
* utils.c (internal_vproblem): Make "msg" const.
|
|
We can use CC_WITH_TWEAKS_FLAGS when cd-ing into the gdb build subdir and
invoking make check:
...
$ cd $objdir/gdb
$ make check \
RUNTESTFLAGS='--target_board=cc-with-tweaks' \
CC_WITH_TWEAKS_FLAGS='-z'
...
But when cd-ing into the top-level build dir and invoking make check-gdb
instead:
...
$ cd $objdir
$ make check-gdb \
RUNTESTFLAGS='--target_board=cc-with-tweaks' \
CC_WITH_TWEAKS_FLAGS='-z'
...
using CC_WITH_TWEAKS_FLAGS has no effect, because CC_WITH_TWEAKS_FLAGS is not
passed down from the top level Makefile.
Add cc-with-dwz.exp and cc-with-dwz-m.exp, that don't require
CC_WITH_TWEAKS_FLAGS to be set in the make invocation, allowing us to run these
test configurations from the toplevel build dir:
...
$ cd $objdir
$ make check-gdb \
RUNTESTFLAGS='--target_board=cc-with-dwz'
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-11 Tom de Vries <tdevries@suse.de>
* boards/cc-with-dwz-m.exp: New file.
* boards/cc-with-dwz.exp: New file.
* boards/cc-with-tweaks.exp: Note that check-gdb doesn't work.
|
|
A recent change made the AArch64 self tests resuse the saved regs
cache, rather than creating a new one. Ensure it is reset to default
values between tests.
Do this by splitting the reset functionality from trad_frame_alloc_saved_regs
into a new function.
Fixes selftest on AArch64.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_analyze_prologue_test): Reset saved regs.
* trad-frame.c (trad_frame_reset_saved_regs): New function.
(trad_frame_alloc_saved_regs): Call trad_frame_reset_saved_regs.
* trad-frame.h (trad_frame_reset_saved_regs): New declaration.
|
|
This commit fixes some failures in gdb.base/interrupt.exp
when debugging a 32-bit i386 linux inferior from an amd64 host.
When running the following test...
make check RUNTESTFLAGS="--target_board unix/-m32 interrupt.exp"
... without this commit, I see the following output:
FAIL: gdb.base/interrupt.exp: continue (the program exited)
FAIL: gdb.base/interrupt.exp: echo data
FAIL: gdb.base/interrupt.exp: Send Control-C, second time
FAIL: gdb.base/interrupt.exp: signal SIGINT (the program is no longer running)
ERROR: Undefined command "".
ERROR: GDB process no longer exists
=== gdb Summary ===
When the test is run with this commit in place, we see 12 passes
instead. This is the desired behavior.
Analysis:
On Linux, when a syscall is interrupted by a signal, the syscall
may return -ERESTARTSYS when a signal occurs. Doing so indicates that
the syscall is restartable. Then, depending on settings associated
with the signal handler, and after the signal handler is called, the
kernel can then either return -EINTR or can cause the syscall to be
restarted. In this discussion, we are concerned with the latter
case.
On i386, the kernel returns this status via the EAX register.
When debugging a 32-bit (i386) process from a 64-bit (amd64)
GDB, the debugger fetches 64-bit registers even though the
process being debugged is 32-bit. Since we're debugging a 32-bit
target, only 32 bits are being saved in the register cache.
Now, ideally, GDB would save all 64-bits in the regcache and
then would be able to restore those same values when it comes
time to continue the target. I've looked into doing this, but
it's not easy and I don't see many benefits to doing so. One
benefit, however, would be that EAX would appear as a negative
value for doing syscall restarts.
At the moment, GDB is setting the high 32 bits of RAX (and other
registers too) to 0. So, when GDB restores EAX just prior to
a syscall restart, the high 32 bits of RAX are zeroed, thus making
it look like a positive value. For this particular purpose, we
need to sign extend EAX so that RAX will appear as a negative
value when EAX is set to -ERESTARTSYS. This in turn will cause
the signal handling code in the kernel to recognize -ERESTARTSYS
which will in turn cause the syscall to be restarted.
This commit is based on work by Jan Kratochvil from 2009:
https://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
Jan's patch had the sign extension code in amd64-nat.c. Several
other native targets make use of this code, so it seemed better
to move the sign extension code to a linux specific file. I
also added similar code to gdbserver.
Another approach is to fix the problem in the kernel. Hui Zhu
tried to get a fix into the kernel back in 2014, but it was not
accepted. Discussion regarding this approach may be found here:
https://lore.kernel.org/patchwork/patch/457841/
Even if a fix were to be put into the kernel, we'd still need
some kind of fix in GDB in order to support older kernels.
Finally, I'll note that Fedora has been carrying a similar patch for
at least nine years. Other distributions, including RHEL and CentOS
have picked up this change and have been using it too.
gdb/ChangeLog:
* amd64-linux-nat.c (amd64_linux_collect_native_gregset): New
function.
(fill_gregset): Call amd64_linux_collect_native_gregset instead
of amd64_collect_native_gregset.
(amd64_linux_nat_target::store_registers): Likewise.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_fill_gregset): Sign extend EAX value
when using a 64-bit gdbserver.
|
|
This introduces a new iterator and range adapter for iteration over
the separate debug files of a given objfile. As in the current
approach, the requested objfile is returned first, followed by the
separate debug objfiles.
gdb/ChangeLog
2019-04-10 Tom Tromey <tom@tromey.com>
* symtab.c (lookup_global_symbol_from_objfile)
(lookup_symbol_in_objfile_from_linkage_name): Use the iterator.
* objfiles.h (class separate_debug_iterator): New.
(class separate_debug_range): New.
(struct objfile) <separate_debug_objfiles>: New method.
(objfile_separate_debug_iterate): Don't declare.
* objfiles.c (separate_debug_iterator::operator++): Rename from
objfile_separate_debug_iterate.
(objfile_relocate, objfile_rebase, objfile_has_symbols): Use the
iterator.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Use the
iterator.
|
|
While working on objfiles I noticed a typo in one comment, and another
comment that, as far as I can tell, has been obsolete for a very long
time.
gdb/ChangeLog
2019-04-10 Tom Tromey <tom@tromey.com>
* symfile.c (reread_symbols): Remove old comment.
* objfiles.c (free_all_objfiles): Fix a typo.
|
|
The "object_files" macro is sometimes used when iterating over
objfiles. This patch removes a few such uses in favor of the new
range adapter.
gdb/ChangeLog
2019-04-10 Tom Tromey <tom@tromey.com>
* ia64-tdep.c (ia64_get_dyn_info_list): Use foreach.
* minsyms.c (lookup_minimal_symbol): Use foreach.
(lookup_minimal_symbol_text, lookup_minimal_symbol_by_pc_name)
(lookup_minimal_symbol_solib_trampoline): Likewise.
* symfile.c (reread_symbols): Use foreach.
|
|
PR rust/24414 points out that the Rust lexer uses strtoul when lexing
an integer, and that this can give the wrong results in some
situations.
This patch changes it to use strtoulst, like most of the rest of gdb.
It also adds a self test.
Tested on x86-64 Fedora 29 using an i686 build.
gdb/ChangeLog
2019-04-09 Ivan Begert <ivanbegert@gmail.com>
Tom Tromey <tromey@adacore.com>
PR rust/24414:
* rust-exp.y (rust_parser::lex_number): Use strtoulst.
(rust_lex_int_test): Change "value" to be LONGEST.
(rust_lex_tests): Add test for long integer literal.
|
|
I noticed that find_thread_in_random duplicates the code in
find_thread_in_random, so this patch changes the latter to use the
former.
There are two other spots in gdb that do this, but to unify all of
them would require switching some code from using the "iterate over"
idiom to using iterators.
Another possible improvement is that find_thread_in_random could be
made single-pass using reservoir sampling.
Tested by the buildbot.
gdb/gdbserver/ChangeLog
2019-04-09 Tom Tromey <tromey@adacore.com>
* linux-low.c (select_event_lwp): Use find_thread_in_random.
|
|
I noticed a few spots where fake_pid_p is handled as an int, whereas
the field in struct inferior has type bool. This patch changes the
remaining places to use bool as well.
Tested by the buildbot.
gdb/ChangeLog
2019-04-09 Tom Tromey <tromey@adacore.com>
* remote.c (remote_target::remote_add_inferior): Change fake_pid_p
to bool.
(extended_remote_target::attach): Update.
(remote_target::remote_notice_new_inferior): Update.
(remote_target::add_current_inferior_and_thread): Update.
* inferior.c (exit_inferior_1): Use "false".
* corelow.c (add_to_thread_list): Make fake_pid_p bool.
|
|
|
|
When using the "start" command, GDB puts a temporary breakpoint on the
"main" symbol (we literally invoke the tbreak command). However, since
it does wild matching by default, it also puts a breakpoint on any C++
method or "main" function in a namespace. For example, when debugging
GDB, it creates a total of 24 locations:
(gdb) start
Temporary breakpoint 1 at 0x198c1e9: main. (24 locations)
as there are a bunch of methods called main in the selftests, such as
selftests::string_view::capacity_1::main()
If such method was called in the constructor of a global object, or a
function marked with the attribute "constructor", then we would stop at
the wrong place. Also, this causes a few extra symtabs (those that
contain the "wrong" mains) to be expanded for nothing.
The dummiest, most straightforward solution is to add -qualified when
invoking tbreak. With this patch, "start" creates a single-location
breakpoint, as expected.
I copied the start.exp test to start-cpp.exp and made it use a C++ test
file, which contains two main functions. The new test verifies that the
output of "start" is the output we get when we set a single-location
breakpoint.
gdb/ChangeLog:
* infcmd.c (run_command_1): Pass -qualified to tbreak when usind
the "start" command.
gdb/testsuite/ChangeLog:
* gdb.base/start-cpp.exp: New file.
* gdb.base/start-cpp.cc: New file.
|
|
This renaming was done to stay consistent with the naming of the new
gdb.InferiorThread.handle method. I had initially named it "thread_handle"
but Tom Tromey suggested just "handle".
The old name (thread_from_thread_handle) still works, but is marked as
deprecated in comments in the code as well as in the documentation.
I have some code which uses these functions. I very much like the
brevity of the new names.
gdb/doc/ChangeLog:
* python.texi (Inferiors In Python): Rename
Inferior.thread_from_thread_handle to Inferior.thread_from_handle.
Add note about the former being deprecated.
gdb/ChangeLog:
* python/py-inferior.c (infpy_thread_from_thread_handle):
Adjust comments to reflect renaming of thread_from_thread_handle
to thread_from_handle. Adjust keywords. Fix type error message.
(inferior_object_methods): Add thread_from_handle. Retain
thread_from_thread_handle, but mark it as deprecated.
testsuite/ChangeLog:
* gdb.python/py-thrhandle.exp: Adjust tests to call
thread_from_handle instead of thread_from_thread_handle.
|
|
gdb/doc/ChangeLog:
* python.texi (Threads In Python): Add description for method
InferiorThread.handle.
|
|
gdb/testsuite/ChangeLog:
* gdb.python/py-thrhandle.exp: Add tests for
gdb.InferiorThread.handle.
|
|
InferiorThread.handle() returns a python bytes object. We'd like to
be able to pass the output of this function, a thread handle, to
Inferior.thread_from_thread_handle(). Up to now,
thread_from_thread_handle() expects to receive a gdb.Value input.
This commit adds support to also allow a python buffer object to be
passed as the handle.
infpy_thread_from_thread_handle() calls find_thread_by_handle() which
has the obvious functionality. It used to pass the thread handle via
a struct value pointer. I've revised this interface to instead pass a
gdb::array_view<const gdb_byte> object. (Thanks to Tom Tromey for
suggesting this data structure over an earlier version which passed a
gdb_byte pointer and length.)
gdb/ChangeLog:
* gdbthread.h (find_thread_by_handle): Revise declaration.
* thread.c (find_thread_by_handle): Likewise. Adjust
implementation too.
* python/py-inferior.c (infpy_thread_from_thread_handle): Add
support for buffer objects as handles.
|
|
gdb/ChangeLog:
* python/py-infthread.c (thpy_thread_handle): New function.
(thread_object_methods): Register thpy_thread_handle.
|
|
This patch adds a thread_info_to_thread_handle method to the target_ops
struct. It also implements this functionality for remote targets and
linux native threads.
gdb/ChangeLog:
* gdbthread.h (thread_to_thread_handle): Declare.
* thread.c (gdbtypes.h): Include.
(thread_to_thread_handle): New function.
* target.h (struct target_ops): Add thread_info_to_thread_handle.
(target_thread_info_to_thread_handle): Declare.
* target.c (target_thread_info_to_thread_handle): New function.
* target-debug.h (target_debug_print_gdb_byte_vector): Define.
* target-delegates.c: Regenerate.
* linux-thread-db.c (class thread_db_target): Add method
thread_info_to_thread_handle.
(thread_db_target::thread_info_to_thread_handle): Define.
* remote.c (class remote_target): Add new method
thread_info_to_thread_handle.
(remote_target::thread_info_to_thread_handle): Define.
|
|
- Explicitly include <string> for std::string.
- Use std::make_shared to construct gdb_exception::message instead of
operator new, avoiding one heap allocation (2 instead of 3). Add
'const char *fmt, va_list ap' parameters to
gdb_exception{,error,quit}'s ctors, and do the std::make_shared in
the gdb_exception ctor.
- gdb_exception_error's constructor does not need to have an 'enum
return_reason' parameter, since it is always RETURN_ERROR, by
definition.
- Similarly, gdb_exception_quit's contructor does not need to have
'enum return_reason'/'enum errors' parameters.
- In the gdb_exception_{quit,_error} ctors that take a gdb_exception
as argument, assert that they're being passed a gdb_exception object
of the right 'reason'.
gdb/ChangeLog:
2019-04-08 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (throw_exception): Don't create
named object to throw; throw directly.
(throw_it): Likewise. Don't initialize gdb_exception::message
here, with new; pass FMT and AP to the ctor instead.
* common/common-exceptions.h: Include <string>.
(gdb_exception::gdb_exception(enum return_reason, enum errors,
const char *, va_list)): New ctor. Use std::make_shared.
(gdb_exception_error::gdb_exception_error(enum return_reason, enum
errors)): Delete.
(gdb_exception_error::gdb_exception_error(enum errors, const char
*, va_list)): New.
(gdb_exception_error::gdb_exception_error(const gdb_exception &)):
Add assertion.
(gdb_exception_quit::gdb_exception_quit(enum return_reason, enum
errors)): Delete.
(gdb_exception_quit::gdb_exception_quit(const char *, va_list)): New.
(gdb_exception_quit::gdb_exception_quit(const gdb_exception &)):
Add assertion.
|
