The ptid_t contructors, accessors and predicates are documented in
_three_ places, and each place uses a different wording.
E.g, the descriptions in the .c file of the new ptid_lwp_p, ptid_tid_p
weren't updated in the final revision like the descriptions in the .h
file were. Clearly, switching to a style that has a single central
description avoids such issues.
Worse, some of the existing descriptions are plain wrong, such as:
/* Attempt to find and return an existing ptid with the given PID, LWP,
and TID components. If none exists, create a new one and return
that. */
ptid_t ptid_build (int pid, long lwp, long tid);
The function does nothing that complicated. It's just a simple
constructor.
So this gets rid of all the unnecessary descriptions, leaving only the
ones near the function declarations in the header file, and
fixes/clarifies those that remain.
gdb/
2013-10-04 Pedro Alves <palves@redhat.com>
* common/ptid.c (null_ptid, minus_one_ptid, ptid_build)
(pid_to_ptid, ptid_get_pid, ptid_get_lwp, ptid_get_tid)
(ptid_equal, ptid_is_pid, ptid_lwp_p, ptid_tid_p): Replace
describing comments with references to ptid.h.
* common/ptid.h: Remove intro description of constructors,
accessors and predicates.
(struct ptid): Reformat.
(minus_one_ptid, ptid_build, pid_to_ptid, ptid_get_pid)
(ptid_get_lwp, ptid_get_tid, ptid_equal, ptid_is_pid): Change
describing comments.
This patch fixes a small typo after the BUILD_THREAD -> ptid_build
conversion.
gdb/ChangeLog:
* aix-thread.c (sync_threadlists): Add missing ')' in call
to ptid_build.
We're casting "addr" into "addr_ptr", but this variable is actually
a parameter with that very same type...
gdb/ChangeLog:
* aix-thread.c (ptrace32): Remove cast to addr_ptr.
gdb/ChangeLog:
* mi/mi-main.c (run_one_inferior): Add function description.
Make ARG a pointer to an integer whose value determines whether
we should "run" or "start" the program.
(mi_cmd_exec_run): Add handling of the "--start" option.
Reject all other command-line options.
* NEWS: Add entry for "-exec-run"'s new "--start" option.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Program Execution): Document "-exec-run"'s
new "--start" option.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-start.c, gdb.mi/mi-start.exp: New files.
This patch moves pending_event to remote_notif_state. All pending
events are destroyed in remote_notif_state_xfree. However,
discard_pending_stop_replies release pending event too, so the pending
event of stop notification is released twice, we need some refactor
here. We add a new function discard_pending_stop_replies_in_queue
which only discard events in stop_reply_queue, and let
remote_notif_state_xfree release pending event for all notif_client.
After this change, discard_pending_stop_replies is only attached to
ifnerior_exit observer, so the INF can't be NULL any more. The
NULL checking is removed too.
gdb:
2013-10-04 Yao Qi <yao@codesourcery.com>
* remote-notif.h (REMOTE_NOTIF_ID): New enum.
(struct notif_client) <pending_event>: Moved
to struct remote_notif_state.
<id>: New field.
(struct remote_notif_state) <pending_event>: New field.
(notif_event_xfree): Declare.
* remote-notif.c (handle_notification): Adjust.
(notif_event_xfree): New function.
(do_notif_event_xfree): Call notif_event_xfree.
(remote_notif_state_xfree): Call notif_event_xfree to free
each element in field pending_event.
* remote.c (discard_pending_stop_replies): Remove declaration.
(discard_pending_stop_replies_in_queue): Declare.
(remote_close): Call discard_pending_stop_replies_in_queue
instead of discard_pending_stop_replies.
(remote_start_remote): Adjust.
(stop_reply_xfree): Call notif_event_xfree.
(notif_client_stop): Adjust initialization.
(remote_notif_remove_all): Rename it to ...
(remove_stop_reply_for_inferior): ... this. Update comments.
Don't check INF is NULL.
(discard_pending_stop_replies): Return early if notif_state is
NULL. Adjust. Don't check INF is NULL.
(remote_notif_get_pending_events): Adjust.
(discard_pending_stop_replies_in_queue): New function.
(remote_wait_ns): Likewise.
Hi,
This FIXME goes into my eyes, when I am about to modify something here,
/* Name is allocated by name_of_child. */
/* FIXME: xstrdup should not be here. */
This FIXME was introduced in the python pretty-pretter patches.
Python pretty-printing [6/6]
https://sourceware.org/ml/gdb-patches/2009-05/msg00467.html
create_child_with_value is called in two paths,
1. varobj_list_children -> create_child -> create_child_with_value,
2. install_dynamic_child -> install_dynamic_child -> varobj_add_child
-> create_child_with_value
In path #1, 'name' is allocated by name_of_child, as the original
comment said, we don't have to duplicate NAME in
create_child_with_value. In path #2, 'name' is got from
PyArg_ParseTuple, and we have to duplicate NAME.
This patch removes the call to xstrdup in create_child_with_value
and call xstrudp in update_dynamic_varobj_children (path #2).
gdb:
2013-10-04 Yao Qi <yao@codesourcery.com>
* varobj.c (create_child_with_value): Remove 'const' from the
type of parameter 'name'.
(varobj_add_child): Likewise.
(install_dynamic_child): Remove 'const' from the type of
parameter 'name'.
(varobj_add_child): Likewise.
(create_child_with_value): Likewise. Update comments. Don't
duplicate 'name'.
(update_dynamic_varobj_children): Duplicate 'name'
and pass it to install_dynamic_child.
* python/py-value.c (convert_value_from_python): Move PyInt_Check
conversion logic to occur after PyLong_Check. Comment on order
change significance.
* python/py-arch.c (archpy_disassemble): Comment on order of
conversion for integers and longs.
If enabling PTRACE_O_TRACEFORK fails, we never test for
PTRACE_O_TRACESYSGOOD support. Before PTRACE_O_TRACESYSGOOD is checked,
we have:
/* First, set the PTRACE_O_TRACEFORK option. If this fails, we
know for sure that it is not supported. */
ret = ptrace (PTRACE_SETOPTIONS, child_pid, (PTRACE_TYPE_ARG3) 0,
(PTRACE_TYPE_ARG4) PTRACE_O_TRACEFORK);
if (ret != 0)
{
ret = ptrace (PTRACE_KILL, child_pid, (PTRACE_TYPE_ARG3) 0,
(PTRACE_TYPE_ARG4) 0);
if (ret != 0)
{
warning (_("linux_check_ptrace_features: failed to kill child"));
return;
}
ret = my_waitpid (child_pid, &status, 0);
if (ret != child_pid)
warning (_("linux_check_ptrace_features: failed "
"to wait for killed child"));
else if (!WIFSIGNALED (status))
warning (_("linux_check_ptrace_features: unexpected "
"wait status 0x%x from killed child"), status);
return; <<<<<<<<<<<<<<<<<
}
Note that early return. If PTRACE_O_TRACEFORK isn't supported, we're
not checking PTRACE_O_TRACESYSGOOD. This didn't use to be a problem
before the unification of this whole detection business in
linux-ptrace.c. Before, the sysgood detection was completely
separate:
static void
linux_test_for_tracesysgood (int original_pid)
{
int ret;
sigset_t prev_mask;
/* We don't want those ptrace calls to be interrupted. */
block_child_signals (&prev_mask);
linux_supports_tracesysgood_flag = 0;
ret = ptrace (PTRACE_SETOPTIONS, original_pid, 0, PTRACE_O_TRACESYSGOOD);
if (ret != 0)
goto out;
linux_supports_tracesysgood_flag = 1;
out:
restore_child_signals_mask (&prev_mask);
}
So we need to get back the decoupling somehow. I think it's cleaner
to split the seperate feature detections to separate functions. This
patch does that. The new functions are named for their counterparts
that existed before this code was moved to linux-ptrace.c.
Note I've used forward declarations for the new functions to make the
patch clearer, as otherwise the patch would look like I'd be adding a
bunch of new code. A reorder can be done in a follow up patch.
Tested on x86_64 Fedora 17.
gdb/
2013-10-03 Pedro Alves <palves@redhat.com>
* common/linux-ptrace.c (linux_check_ptrace_features): Factor out
the PTRACE_O_TRACESYSGOOD and PTRACE_O_TRACEFORK to separate
functions. Always test for PTRACE_O_TRACESYSGOOD even if
PTRACE_O_TRACEFORK is not supported.
(linux_test_for_tracesysgood): New function.
(linux_test_for_tracefork): New function, factored out from
linux_check_ptrace_features, and also don't kill child_pid here.
Currently, in some scenarios, GDB prints <optimized out> when printing
outer frame registers. An <optimized out> register is a confusing
concept. What this really means is that the register is
call-clobbered, or IOW, not saved by the callee. This patch makes GDB
say that instead.
Before patch:
(gdb) p/x $rax $1 = <optimized out>
(gdb) info registers rax
rax <optimized out>
After patch:
(gdb) p/x $rax
$1 = <not saved>
(gdb) info registers rax
rax <not saved>
However, if for some reason the debug info describes a variable as
being in such a register (**), we still want to print <optimized out>
when printing the variable. IOW, <not saved> is reserved for
inspecting registers at the machine level. The patch uses
lval_register+optimized_out to encode the not saved registers, and
makes it so that optimized out variables always end up in
!lval_register values.
** See <https://sourceware.org/ml/gdb-patches/2012-08/msg00787.html>.
Current/recent enough GCC doesn't mark variables/arguments as being in
call-clobbered registers in the ranges corresponding to function
calls, while older GCCs did. Newer GCCs will just not say where the
variable is, so GDB will end up realizing the variable is optimized
out.
frame_unwind_got_optimized creates not_lval optimized out registers,
so by default, in most cases, we'll see <optimized out>.
value_of_register is the function eval.c uses for evaluating
OP_REGISTER (again, $pc, etc.), and related bits. It isn't used for
anything else. This function makes sure to return lval_register
values. The patch makes "info registers" and the MI equivalent use it
too. I think it just makes a lot of sense, as this makes it so that
when printing machine registers ($pc, etc.), we go through a central
function.
We're likely to need a different encoding at some point, if/when we
support partially saved registers. Even then, I think
value_of_register will still be the spot to tag the intention to print
machine register values differently.
value_from_register however may also return optimized out
lval_register values, so at a couple places where we're computing a
variable's location from a dwarf expression, we convert the resulting
value away from lval_register to a regular optimized out value.
Tested on x86_64 Fedora 17
gdb/
2013-10-02 Pedro Alves <palves@redhat.com>
* cp-valprint.c (cp_print_value_fields): Adjust calls to
val_print_optimized_out.
* jv-valprint.c (java_print_value_fields): Likewise.
* p-valprint.c (pascal_object_print_value_fields): Likewise.
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full)
<DWARF_VALUE_REGISTER>: If the register was not saved, return a
new optimized out value.
* findvar.c (address_from_register): Likewise.
* frame.c (put_frame_register): Tweak error string to say the
register was not saved, rather than optimized out.
* infcmd.c (default_print_one_register_info): Adjust call to
val_print_optimized_out. Use value_of_register instead of
get_frame_register_value.
* mi/mi-main.c (output_register): Use value_of_register instead of
get_frame_register_value.
* valprint.c (valprint_check_validity): Likewise.
(val_print_optimized_out): New value parameter. If the value is
lval_register, print <not saved> instead.
(value_check_printable, val_print_scalar_formatted): Adjust calls
to val_print_optimized_out.
* valprint.h (val_print_optimized_out): New value parameter.
* value.c (struct value) <optimized_out>: Extend comment.
(error_value_optimized_out): New function.
(require_not_optimized_out): Use it. Use a different string for
lval_register values.
* value.h (error_value_optimized_out): New declaration.
* NEWS: Mention <not saved>.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-reg-undefined.exp <pattern_rax_rbx_rcx_print,
pattern_rax_rbx_rcx_info>: Set to "<not saved>".
* gdb.mi/mi-reg-undefined.exp (opt_out_pattern): Delete.
(not_saved_pattern): New.
Replace use of the former with the latter.
gdb/doc/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Registers): Expand description of saved registers
in frames. Explain <not saved>.
Running catch-syscall.exp against a gdbserver that actually supports
it, we get:
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit at catch syscall with unused syscall (mlock) (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
The fail pattern is:
Catchpoint 2 (call to syscall exit_group), 0x000000323d4baa29 in _exit () from /lib64/libc.so.6
(gdb) PASS: gdb.base/catch-syscall.exp: program has called exit_group
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break exit
Breakpoint 3 at 0x323d438bf0
(gdb) continue
Continuing.
[Inferior 1 (process 21081) exited normally]
That "break exit" + "continue" comes from:
> # gdb_continue_to_end:
> # The case where the target uses stubs has to be handled specially. If a
> # stub is used, we set a breakpoint at exit because we cannot rely on
> # exit() behavior of a remote target.
> #
The native-gdbserver.exp board, used to test against gdbserver in
"target remote" mode, triggers that case ($use_gdb_stub is true). So
gdb_continue_to_end doesn't work for catch-syscall.exp as here we
catch the exit_group and continue from that, expecting to see a real
program exit. I was about to post a patch that changes
catch-syscall.exp to call a new function that just always does what
gdb_continue_to_end does in the !$use_gdb_stub case. But, since
GDBserver doesn't really need this, in the end I thought it better to
teach the testsuite that there are stubs that know how to report
program exits, by adding a new "exit_is_reliable" board variable that
then gdb_continue_to_end checks.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* README (Board Settings): Document "exit_is_reliable".
* lib/gdb.exp (gdb_continue_to_end): Check whether the board says
running to exit reliably reports program exits.
* boards/native-gdbserver.exp: Set exit_is_reliable in the board
info.
* boards/native-stdio-gdbserver.exp: Likewise.
If we make gdbserver gdb_continue_to_end actually expect a process
exit with GDBserver, we get many testsuite failures with the remote
stdio board:
-PASS: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step
+FAIL: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step (the program exited)
-PASS: gdb.base/break.exp: continue until exit at recursive next test
+FAIL: gdb.base/break.exp: continue until exit at recursive next test (the program exited)
-PASS: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through
+FAIL: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through (the program exited)
... etc. ...
This is what the log shows for all of them:
(gdb) continue
Continuing.
Child exited with status 0
GDBserver exiting
[Inferior 1 (process 22721) exited normally]
(gdb) FAIL: gdb.arch/amd64-disp-step.exp: continue until exit (the program exited)
The problem is the whole "Child exited ... GDBserver exiting" output,
that comes out of GDBserver, and that the testsuite is not expecting.
I pondered somehow making the testsuite adjust to this. But,
testsuite aside, I think GDBserver should not be outputting this at
all when GDB is connected through stdio. GDBserver will be printing
this in GDB's console, but the user can already tell from the regular
output that the inferior is gone.
Again, manually:
(gdb) tar remote | ./gdbserver/gdbserver - program
Remote debugging using | ./gdbserver/gdbserver - program
Process program created; pid = 22486
stdin/stdout redirected
Remote debugging using stdio
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x000000323d001530 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.
Child exited with status 1
^^^^^^^^^^^^^^^^^^^^^^^^^^
GDBserver exiting
^^^^^^^^^^^^^^^^^
[Inferior 1 (process 22486) exited with code 01]
(gdb)
Suppressing those two lines makes the output be exactly like when
debugging against a remote tcp gdbserver:
(gdb) c
Continuing.
[Inferior 1 (process 22914) exited with code 01]
(gdb)
2013-10-02 Pedro Alves <palves@redhat.com>
* server.c (process_serial_event): Don't output "GDBserver
exiting" if GDB is connected through stdio.
* target.c (mywait): Likewise, be silent if GDB is connected
through stdio.
This avoids duplicating the logic comparing two symbol_search
objects (in search_symbols_equal and compare_search_syms).
gdb/ChangeLog:
* symtab.c (search_symbols_equal): Delete.
(sort_search_symbols_remove_dups): Replace call to
search_symbols_equal by call to compare_search_syms,
adjusting as necessary.
* arm-wince-tdep.c: Remove inclusion of "solib.h" and
"solib-target.h". Include "windows-tdep.h".
(arm_wince_init_abi): Call windows_init_abi. Remove call to
set_solib_ops and set_gdbarch_has_dos_based_file_system.
* configure.tgt (arm*-wince-pe | arm*-*-mingw32ce*): Append
windows-tdep.o to gdb_target_obs.
* amd64-windows-tdep.c: Remove inclusion of "solib.h" and
"solib-target.h".
(amd64_windows_init_abi): Don't call set_solib_ops and
set_gdbarch_iterate_over_objfiles_in_search_order. Call
windows_init_abi instead.
* i386-cygwin-tdep.c: Remove inclusion of "solib.h" and
"solib-target.h".
(i386_cygwin_init_abi): Don't call set_solib_ops,
set_gdbarch_has_dos_based_file_system and
set_gdbarch_iterate_over_objfiles_in_search_order. Call
windows_init_abi instead.
* windows-tdep.c: Include "solib.h" and "solib-target.h".
(windows_init_abi): New function.
(windows_iterate_over_objfiles_in_search_order): Make it
static.
* windows-tdep.h (windows_init_abi): Declare.
(windows_iterate_over_objfiles_in_search_order): Remove
declaration.
The current implementation is forgetting to populate the thread list
when attaching to the process. This results in an incomplete list of
threads when debugging a threaded program.
Unfortunately, as the added comments hints, there appears to be
no way of getting the list of threads via ptrace, other than by
spawning the "ps" command, and parsing its output. Not great,
but it appears to be the best we can do.
gdb/gdbserver/ChangeLog:
* lynx-low.c (lynx_add_threads_after_attach): New function.
(lynx_attach): Remove call to add_thread. Add call to
lynx_add_threads_after_attach instead.
So far elinos.py was assuming that the whole ELinOS environment was
around to find the system libraries; if some environment variables
were missing, the script would just abort.
This was a bit extreme. It is possible to do better than that: to get
the core system libraries, one doesn't need to have a full environment
but just the path to the CDK. The path to kernel project is only
needed for the optional Xenomai libs.
gdb/ChangeLog:
* system-gdbinit/elinos.py (get_elinos_environment): Return an
incomplete dictionnary instead of None in case of missing
environment variables.
(elinos_init): in case of an incomplete environment, best
effort to load system libraries instead of abort.
When building the program with the shared GNAT runtime, the debugger
is unable to insert Ada exception catchpoints until that runtime
has been mapped to memory. In other words, we expect the user to start
the program first, before attempting to insert that catchpoint.
The detection mechanism that tries to provide some useful tips to
the user fails when the program itself contains a trampoline symbol
matching the symbol that the catchpoint is trying to use. This
results in the following error message:
(gdb) catch exception
Your Ada runtime appears to be missing some debugging information.
Cannot insert Ada exception catchpoint in this configuration.
Instead, we expected the following error message:
(gdb) catch exception
Unable to insert catchpoint. Try to start the program first.
gdb/ChangeLog:
* ada-lang.c (ada_has_this_exception_support): Ignore
mst_solib_trampoline minimal symbols.
* i386-darwin-nat.c (darwin_complete_target): Install methods for
hardware watchpoint.
(i386_darwin_dr_set): Support 32 and 64 bit states.
(i386_darwin_dr_get): Likewise.
(i386_darwin_dr_set_control): Make static.
(i386_darwin_dr_set_addr, i386_darwin_dr_get_addr)
(i386_darwin_dr_get_status, i386_darwin_dr_get_control): Likewise.
It is possible to have a build of glibc where SYS_perf_event_open is not
defined (because when the glibc was compiled, the syscall did not exist),
but have newer kernel headers installed so that linux/perf_event.h is
available. In this setup, you get a build failure:
./common/linux-btrace.c: In function 'kernel_supports_btrace':
./common/linux-btrace.c:316:23: error: 'SYS_perf_event_open' undeclared (first use in this function)
Update the ifdef check to also see if the syscall is available.
URL: https://bugs.gentoo.org/473522
Reported-by: William Throwe <wtt6@cornell.edu>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
