PR testsuite/12649
* gdb.mi/mi-dprintf.exp (mi_continue_dprintf) (mi 2nd dprintf): Replace
$mi_gdb_prompt expectation by mi_expect_stop.
(mi 1st dprintf, agent, mi 2nd dprintf, agent)
(mi info dprintf second time): Replace them by mi_send_resuming_command
and mi_expect_stop.
* tracepoint.c (TFILE_PID): Remove.
(tfile_open): Don't add thread and inferior.
(tfile_close): Don't set 'inferior_ptid'. Don't call
exit_inferior_silent.
(tfile_thread_alive): Remove.
(init_tfile_ops): Don't set field 'to_thread_alive' of
tfile_ops.
gdb/testsuite/
* gdb.trace/tfile.exp: Test inferior and thread.
This bit:
+ p1 = strchr (p, ':');
+ decode_address (&resume_info[i].step_range_end, p, p1 - p);
should not expect the ':' to be there. An action without a ptid is
valid:
"If an action is specified with no thread-id, then it is applied to any
threads that don't have a specific action specified"
This is handled further below:
if (p[0] == 0)
{
resume_info[i].thread = minus_one_ptid;
default_action = resume_info[i];
/* Note: we don't increment i here, we'll overwrite this entry
the next time through. */
}
else if (p[0] == ':')
A stub that doesn't support and report to gdb thread ids at all (like
metal metal targets) only will always only see a single default action
with no ptid.
Use unpack_varlen_hex instead of decode_address. The former doesn't
need to be told where the hex number ends, and it actually returns
that info instead, which we can use for validation.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2013-05-24 Pedro Alves <palves@redhat.com>
* server.c (handle_v_cont) <vCont;r>: Use unpack_varlen_hex
instead of strchr/decode_address. Error if the range isn't split
with a ','. Don't assume there's be a ':' in the action.
* gdb.base/range-stepping.exp: Skip the rest of tests if the
test fails.
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Return 0 if the test passes, otherwise return 1.
Building gdb with --host=i586-pc-msdosdjgpp ends up with:
i586-pc-msdosdjgpp-gcc -g -O2 -I../../src/gdb/config/djgpp -I. -I../../src/gdb -I../../src/gdb/common -I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/../include/opcode -I../../src/gdb/../opcodes/.. -I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../libdecnumber -I../../src/gdb/../libdecnumber -I./../intl -I../../src/gdb/gnulib/import -Ibuild-gnulib/import -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Werror -c -o filestuff.o -MT filestuff.o -MMD -MP -MF .deps/filestuff.Tpo ../../src/gdb/common/filestuff.c
../../src/gdb/common/filestuff.c:38:24: fatal error: sys/socket.h: No such file or directory
There are no sockets on djgpp. This #ifdef's out the bits in the file
that use sockets, depending on whether winsock or sys/socket.h is
available.
As alternative approach, given ser-tcp.c, ser-pipe.c, etc. are split
into separate files, and which to use is selected by configure.ac:
dnl Figure out which of the many generic ser-*.c files the _host_ supports.
SER_HARDWIRE="ser-base.o ser-unix.o ser-pipe.o ser-tcp.o"
case ${host} in
*go32* ) SER_HARDWIRE=ser-go32.o ;;
*djgpp* ) SER_HARDWIRE=ser-go32.o ;;
*mingw32*) SER_HARDWIRE="ser-base.o ser-tcp.o ser-mingw.o" ;;
esac
AC_SUBST(SER_HARDWIRE)
... I considered splitting filestuff.c similarly. But I quickly gave
up on the idea, as it looked like a lot more complication over this
approach, for no real gain. Plus, there are uses of these functions
outside the ser*.c framework.
gdbserver's configure.ac is already checking for sys/socket.h.
gdb/
2013-05-23 Pedro Alves <palves@redhat.com>
* common/filestuff.c [USE_WIN32API]: Define HAVE_SOCKETS.
[HAVE_SYS_SOCKET_H]: Define HAVE_SOCKETS.
(socket_mark_cloexec, gdb_socketpair_cloexec, gdb_socket_cloexec):
Only define if HAVE_SOCKETS is defined.
* configure.ac: Check for sys/socket.h.
* config.in, configure: Regenerate.
Building gdb on GNU/Linux, for --host=i586-pc-msdosdjgpp, I get:
../../src/gdb/dwarf2read.c: In function 'create_dwp_hash_table':
../../src/gdb/dwarf2read.c:8626:7: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' [-Werror=format]
../../src/gdb/dwarf2read.c:8632:7: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' [-Werror=format]
../../src/gdb/dwarf2read.c: In function 'create_dwo_in_dwp':
../../src/gdb/dwarf2read.c:8754:6: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' [-Werror=format]
../../src/gdb/dwarf2read.c: In function 'open_and_init_dwp_file':
../../src/gdb/dwarf2read.c:9248:6: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Werror=format]
../../src/gdb/dwarf2read.c:9248:6: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format]
And:
$ grep uint32_t /usr/i586-pc-msdosdjgpp/sys-include/*
/usr/i586-pc-msdosdjgpp/sys-include/stdint.h:typedef unsigned long uint32_t;
As decided on the discussion at
<http://sourceware.org/ml/gdb-patches/2013-05/msg00788.html>, use
pulongest rather than PRIu32.
Tested on F17. Also confirmed GDB still builds OK with
--host=i686-w64-mingw32.
gdb/
2013-05-23 Pedro Alves <palves@redhat.com>
* dwarf2read.c (create_dwp_hash_table, create_dwo_in_dwp)
(open_and_init_dwp_file): Use %s/pulongest instead of %u for
printing uint32_t variables.
This adds tests to verify range stepping is used as expected, by
inspecting the RSP traffic, looking for vCont;s and vCont;r packets.
gdb/testsuite/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.base/range-stepping.c: New file.
* gdb.base/range-stepping.exp: New file.
* gdb.trace/range-stepping.c: New file.
* gdb.trace/range-stepping.exp: New file.
* lib/range-stepping-support.exp: New file.
This patch adds support for range stepping to GDBserver, teaching it
about vCont;r.
It'd be easy to enable this for all hardware single-step targets
without needing the linux_target_ops hook, however, at least PPC needs
special care, due to the fact that PPC atomic sequences can't be
hardware single-stepped through, a thing which GDBserver doesn't know
about. So this leaves the support limited to x86/x86_64.
gdb/
2013-05-23 Pedro Alves <palves@redhat.com>
* NEWS: Mention GDBserver range stepping support.
gdb/gdbserver/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* linux-low.c (lwp_in_step_range): New function.
(linux_wait_1): If the thread was range stepping and stopped
outside the stepping range, report the stop to GDB. Otherwise,
continue stepping. Add range stepping debug output.
(linux_set_resume_request): Copy the step range from the resume
request to the lwp.
(linux_supports_range_stepping): New.
(linux_target_ops) <supports_range_stepping>: Set to
linux_supports_range_stepping.
* linux-low.h (struct linux_target_ops)
<supports_range_stepping>: New field.
(struct lwp_info) <step_range_start, step_range_end>: New fields.
* linux-x86-low.c (x86_supports_range_stepping): New.
(the_low_target) <supports_range_stepping>: Set to
x86_supports_range_stepping.
* server.c (handle_v_cont): Handle 'r' action.
(handle_v_requests): Append ";r" if the target supports range
stepping.
* target.h (struct thread_resume) <step_range_start,
step_range_end>: New fields.
(struct target_ops) <supports_range_stepping>:
New field.
(target_supports_range_stepping): New macro.
This patch teaches GDB to take advantage of target-assisted range
stepping. It adds a new 'r ADDR1,ADDR2' action to vCont (vCont;r),
meaning, "step once, and keep stepping as long as the thread is in the
[ADDR1,ADDR2) range".
Rationale:
When user issues the "step" command on the following line of source,
a = b + c + d * e - a;
GDB single-steps every single instruction until the program reaches a
new different line. E.g., on x86_64, that line compiles to:
0x08048434 <+65>: mov 0x1c(%esp),%eax
0x08048438 <+69>: mov 0x30(%esp),%edx
0x0804843c <+73>: add %eax,%edx
0x0804843e <+75>: mov 0x18(%esp),%eax
0x08048442 <+79>: imul 0x2c(%esp),%eax
0x08048447 <+84>: add %edx,%eax
0x08048449 <+86>: sub 0x34(%esp),%eax
0x0804844d <+90>: mov %eax,0x34(%esp)
0x08048451 <+94>: mov 0x1c(%esp),%eax
and the following is the RSP traffic between GDB and GDBserver:
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:3c840408;thread:p2e13.2e13;core:1;
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:3e840408;thread:p2e13.2e13;core:2;
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:42840408;thread:p2e13.2e13;core:2;
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:47840408;thread:p2e13.2e13;core:0;
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:49840408;thread:p2e13.2e13;core:0;
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:4d840408;thread:p2e13.2e13;core:0;
--> vCont;s:p2e13.2e13;c
<-- T0505:68efffbf;04:30efffbf;08:51840408;thread:p2e13.2e13;core:0;
IOW, a lot of roundtrips between GDB and GDBserver.
If we add a new command to the RSP, meaning "keep stepping and don't
report a stop until the program goes out of the [0x08048434,
0x08048451) address range", then the RSP traffic can be reduced down
to:
--> vCont;r8048434,8048451:p2db0.2db0;c
<-- T0505:68efffbf;04:30efffbf;08:51840408;thread:p2db0.2db0;core:1;
As number of packets is reduced dramatically, the performance of
stepping source lines is much improved.
In case something is wrong with range stepping on the stub side, the
debug info or even gdb, this adds a "set/show range-stepping" command
to be able to turn range stepping off.
gdb/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_control_state) <may_range_step>: New
field.
* infcmd.c (step_once, until_next_command): Enable range stepping.
* infrun.c (displaced_step_prepare): Disable range stepping.
(resume): Disable range stepping if stepping over a breakpoint or
we have software watchpoints. If range stepping is enabled,
assert the thread is in the stepping range.
(clear_proceed_status_thread): Clear may_range_step.
(handle_inferior_event): Disable range stepping as soon as we know
the thread that hit the event. Re-enable it whenever we're going
to step with a step range.
* remote.c (struct vCont_action_support) <r>: New field.
(use_range_stepping): New global.
(remote_vcont_probe): Handle 'r' action.
(append_resumption): Append an 'r' action if the thread may range
step.
(show_range_stepping): New function.
(set_range_stepping): New function.
(_initialize_remote): Call add_setshow_boolean_cmd to register the
'set range-stepping' and 'show range-stepping' commands.
* NEWS: Mention range stepping, the new vCont;r action, and the
new "set/show range-stepping" commands.
gdb/doc/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.texinfo (Packets): Document 'vCont;r'.
(Continuing and Stepping): Document target-assisted range
stepping, and the 'set range-stepping' and 'show range-stepping'
commands.
Convert the 'support_vCont_t' int field to a struct, in preparation
for adding more fields to it.
gdb/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* remote.c (struct vCont_action_support): New struct.
(struct remote_state) <support_vCont_t>: Remove field.
<vCont_actions_support>: New field.
(remote_vcont_probe, remote_stop_ns): Update.
This adds a function for doing within-thread's-stepping-range checks,
and converts a couple spots to use it. Following patches will add
more uses.
gdb/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdbthread.h (pc_in_thread_step_range): New declaration.
* thread.c (pc_in_thread_step_range): New function.
* infrun.c (handle_inferior_event): Use it.
gdb/doc/ChangeLog:
* gdb.texinfo (Installed System-wide Configuration Scripts):
Add subsection describing the scripts now available under
the data-dir's system-gdbbinit subdirectory.
* NEWS: Add entry announcing the availability of system-wide
configuration scripts for ElinOS and Wind River Linux.
'func_name' from find_frame_funname.
(ada_unhandled_exception_name_addr_from_raise): Add cleanups
for func_name from find_frame_funname.
* python/py-frame.c (frapy_name): Add explicit free of
'name' from find_frame_funname.
* stack.c (find_frame_funname): Add comment explaining that
funcp must be freed by the caller.
Return copy of symbol names instead of pointers.
(print_frame): Add a cleanup for 'funname' from
find_frame_funname.
* stack.h (find_frame_funname): Remove "const" from
'funname' parameter.
* c-valprint.c (c_value_print): Use value_addr for
references. Convert back to reference type with value_ref.
gdb/testsuite
* gdb.cp/class2.cc (main): New local 'aref'.
* gdb.cp/class2.exp: Check printing of 'aref'.
* ui-out.c: Create typedef ui_out_level_p and define vector
operations for that type.
(struct ui_out): Use a vector instead of an array.
(current_level): Return level from a vector.
(push_level): Create a level in a vector.
(pop_level): Delete a level in a vector.
(ui_out_new): Create initial level zero level, and store in a
vector.
(ui_out_destroy): Add vector cleanup.
The ARI complains with:
> gdb/python/python-internal.h:177: code: editCase function: Function name starts lower case but has uppercased letters.
gdb/python/python-internal.h:177:gdb_Py_DECREF (void *op)
gdb_Py_DECREF is just wrapping a python macro that happens to be mixed case.
gdb/
2013-05-22 Pedro Alves <palves@redhat.com>
* python/python-internal.h (gdb_Py_DECREF): Tag with
"ARI: editCase function".
* symtab.h (Symbol::is_cxx_vtable): New function.
* target-reloc.h (relocate_section): Check for vtable symbol.
* testsuite/Makefile.am (missing_key_func.sh): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/missing_key_func.cc: New test source.
* testsuite/missing_key_func.sh: New test script.
* object.cc (Sized_relobj_file::get_symbol_location_info): Set
type of enclosing symbol.
(Relocate_info::location): Check symbol type when describing symbol.
* object.h (Symbol_location_info): Remove unused line_number;
add enclosing_symbol_type.
* testsuite/debug_msg.sh: Adjust expected output.
The only difference between Py_DECREF and Py_XDECREF is that the latter allows passing
in a NULL object, while the former prohibits it. Given that, it's natural to expect
the same from py_decref vs py_xdecref.
gdb/
2013-05-21 Pedro Alves <palves@redhat.com>
* python/py-prettyprint.c (apply_val_pretty_printer): Check
whether PRINTER is NULL before installing a Py_DECREF cleanup.
* python/py-utils.c (py_decref): Don't check for NULL before
calling Py_DECREF.
Wrap/redefine Py_DECREF ourselves, avoiding the need for uses to care
about extra braces due to the fact that Python only started wrapping Py_DECREF
in 'do {} while (0)' after 2.6.
gdb/
2013-05-21 Pedro Alves <palves@redhat.com>
* python/py-utils.c (py_decref): Remove extra braces.
(gdb_pymodule_addobject): Remove extra braces.
* python-internal.h (gdb_Py_DECREF): New static inline function.
(Py_DECREF): Redefine as calling gdb_Py_DECREF.
Code cleanup: constification.
* solib.c (solib_ops): Make return type and ops variable type const.
(set_solib_ops): Make the new_ops parameter and ops variable const.
(solib_find, solib_map_sections, clear_so, free_so, update_solib_list)
(solib_add, solib_keep_data_in_core, clear_solib)
(solib_create_inferior_hook, in_solib_dynsym_resolve_code)
(reload_shared_libraries, solib_global_lookup): Make the ops variable
const.
* solib.h (set_solib_ops): Make the new_ops parameter const.
