Building in C++ mode shows:
int write_inferior_memory (CORE_ADDR memaddr, const unsigned char *myaddr,
^
src/gdb/gdbserver/proc-service.c:93:64: error: invalid conversion from ‘int’ to ‘ps_err_e’ [-fpermissive]
return write_inferior_memory ((unsigned long) addr, buf, size);
^
It only works today by accident, write_inferior_memory does not return
a ps_err_e.
gdb/gdbserver/ChangeLog:
2015-08-27 Pedro Alves <palves@redhat.com>
* proc-service.c (ps_pdwrite): Return PS_ERR/PS_OK explicily.
This patch moves aarch64_linux_new_thread in GDB and GDBserver to
nat/aarch64-linux.c.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_new_thread): Move it to ...
* nat/aarch64-linux.c (aarch64_linux_new_thread): ... here.
* nat/aarch64-linux.h (aarch64_linux_new_thread): Declare.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_linux_new_thread): Remove.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_prepare_to_resume): Use
lwp_arch_private_info and ptid_of_lwp.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_linux_prepare_to_resume): Use
lwp_arch_private_info and ptid_of_lwp.
This patch addes argument pid in aarch64_get_debug_reg_state, so that
its interface is the same on both GDB and GDBserver.
gdb/gdbserver:
2015-018-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_get_debug_reg_state): Add argument pid.
Find proc_info by find_process_pid. All callers updated.
This patch makes function debug_reg_change_callback in GDB and GDBserver
look the same, so that the following patch can move them to
nat/aarch64-linux-hw-point.c.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (debug_reg_change_callback): Use
ptid_of_lwp to get ptid of lwp.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Use
ptid_of_lwp to get ptid of lwp.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (debug_reg_change_callback): Use
debug_printf.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Use
debug_printf.
This patch is to use phex in debug_reg_change_callback to make it
identical in GDB and GDBserver.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Use phex.
This patch makes more bits on aarch64 watchpoint between GDB and GDBserver
look similar.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_dr_update_callback_param) <pid>:
Remove.
(debug_reg_change_callback): Remove argument entry and add argument
lwp. Remove local variable thread. Don't print thread id in the
debugging output. Don't check whether pid of thread equals to pid.
(aarch64_notify_debug_reg_change): Don't set param.pid. Call
iterate_over_lwps instead find_inferior.
Ref: https://sourceware.org/ml/gdb-patches/2015-08/msg00675.html
If multiprocess extensions are off (because specific gdbserver port
doesn't support them), then when gdbserver doesn't have a thread
selected yet, and GDB sends Hg packet to select one, gdbserver
crashes. That's because extracting the desired thread id out of the
packet that GDB sent depends on the current thread to fill in the
missing process id ... Fix this by getting the process id from the
first (and only) process in the processes list instead.
The GNU/Linux port doesn't trip on this because it always runs with
multiprocess extensions enabled. To make it easier to catch such
regressions going forward, this commit also adds a new smoke test that
spawns gdbserver, connects to it and runs to main with the
multiprocess extensions force-disabled.
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* inferiors.c (get_first_process): New function.
* inferiors.h (get_first_process): New declaration.
* remote-utils.c (read_ptid): Default to the first process in the
list, instead of to the current thread's process.
gdb/testsuite/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* gdb.server/connect-without-multi-process.c: New file.
* gdb.server/connect-without-multi-process.exp: New file.
After the last gnulib import (Dec 2012), gnulib upstream started
replacing mingw's 'struct timeval' with a version with 64-bit time_t,
for POSIX compliance:
commit f8e84098084b3b53bc6943a5542af1f607ffd477
Author: Bruno Haible <bruno@clisp.org>
Date: Sat Jan 28 18:12:10 2012 +0100
sys_time: Override 'struct timeval' on some native Windows platforms.
See:
https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00372.html
However, that results in conflicts with native Winsock2's 'select':
select()'s argument
http://sourceforge.net/p/mingw-w64/mailman/message/29610438/
... and libiberty's timeval-utils.h timeval_add/timeval_sub, at the
least.
We don't really need the POSIX compliance, so this patch prepares us
to simply not use gnulib's 'struct timeval' replacement once a more
recent gnulib is imported, thus preserving the current behavior, by
adding a sys/time.h wrapper header that undefs gnulib's replacements,
and including that everywhere instead.
The SIZE -> OSIZE change is necessary because newer gnulib's
sys/time.h also includes windows.h/winsock2.h, which defines a
conflicting SIZE symbol.
Cross build-tested mingw-w64 32-bit and 64-bit.
Regtested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add common/gdb_sys_time.h.
* common/gdb_sys_time.h: New file.
* event-loop.c: Include gdb_sys_time.h instead of sys/time.h.
* gdb_select.h: Likewise.
* gdb_usleep.c: Likewise.
* maint.c: Likewise.
* mi/mi-main.c: Likewise.
* mi/mi-parse.h: Likewise.
* remote-fileio.c: Likewise.
* remote-m32r-sdi.c: Likewise.
* remote.c: Likewise.
* ser-base.c: Likewise.
* ser-pipe.c: Likewise.
* ser-tcp.c: Likewise.
* ser-unix.c: Likewise.
* symfile.c: Likewise.
* symfile.c: Likewise. Rename OSIZE to SIZE throughout.
* target-memory.c: Include gdb_sys_time.h instead of sys/time.h.
* utils.c: Likewise.
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* debug.c: Include gdb_sys_time.h instead of sys/time.h.
* event-loop.c: Likewise.
* remote-utils.c: Likewise.
* tracepoint.c: Likewise.
Ref: https://sourceware.org/ml/gdb-patches/2015-08/msg00675.html
gdbserver/spu-low.c: In function 'spu_request_interrupt':
gdbserver/spu-low.c:639: error: incompatible type for argument 1 of 'ptid_get_lwp'
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* spu-low.c (spu_request_interrupt): Use lwpid_of instead of
ptid_get_lwp.
In C++ mode:
src/gdb/gdbserver/ax.c: In function ‘eval_result_type gdb_eval_agent_expr(eval_agent_expr_context*, agent_expr*, ULONGEST*)’:
src/gdb/gdbserver/ax.c:1335:11: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive]
return 1;
^
"1" as an enum eval_result_type is expr_eval_empty_expression, but
clearly this wants to return expr_eval_unhandled_opcode.
gdb/gdbserver/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* ax.c (gdb_eval_agent_expr): Return expr_eval_unhandled_opcode
instead of literal 1.
Running that test in a loop, I found a gdbserver core dump with the
following back trace:
Core was generated by `../gdbserver/gdbserver --once --multi :2346'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
236 return inferior->regcache_data;
(gdb) up
#1 0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
31 regcache = (struct regcache *) inferior_regcache_data (thread);
(gdb) bt
#0 0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
#1 0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
#2 0x0000000000409271 in prepare_resume_reply (buf=0x20dd593 "", ptid=..., status=0x20edce0) at src/gdb/gdbserver/remote-utils.c:1147
#3 0x000000000040ab0a in vstop_notif_reply (event=0x20edcc0, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/server.c:183
#4 0x0000000000426b38 in notif_write_event (notif=0x66e6c0 <notif_stop>, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/notif.c:69
#5 0x0000000000426c55 in handle_notif_ack (own_buf=0x20dd590 "T05", packet_len=8) at src/gdb/gdbserver/notif.c:113
#6 0x000000000041118f in handle_v_requests (own_buf=0x20dd590 "T05", packet_len=8, new_packet_len=0x7fff742c77b8)
at src/gdb/gdbserver/server.c:2862
#7 0x0000000000413850 in process_serial_event () at src/gdb/gdbserver/server.c:4148
#8 0x0000000000413945 in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:4196
#9 0x000000000041a1ef in handle_file_event (event_file_desc=5) at src/gdb/gdbserver/event-loop.c:429
#10 0x00000000004199b6 in process_event () at src/gdb/gdbserver/event-loop.c:184
#11 0x000000000041a735 in start_event_loop () at src/gdb/gdbserver/event-loop.c:547
#12 0x00000000004123d2 in captured_main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3562
#13 0x000000000041252e in main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3631
Clearly this means that a thread pushed a stop reply in the event
queue, and then before GDB confused the event, the whole process died,
along with its thread. But the pending thread event was left
dangling. When GDB fetched that event, gdbserver looked up the
corresponding thread, but found NULL; not expecting this, gdbserver
crashes when it tries to read this thread's registers.
gdb/gdbserver/
2015-08-21 Pedro Alves <palves@redhat.com>
PR gdb/18749
* inferiors.c (remove_thread): Discard any pending stop reply for
this thread.
* server.c (remove_all_on_match_pid): Rename to ...
(remove_all_on_match_ptid): ... this. Work with a filter ptid
instead of a pid.
(discard_queued_stop_replies): Change parameter to a ptid. Now
extern.
(handle_v_kill, kill_inferior_callback)
(process_serial_event): Adjust.
(captured_main): Call initialize_notif before starting the
program, thus before threads are created.
* server.h (discard_queued_stop_replies): Declare.
In all-stop mode, if the current thread disappears while stopping all
threads, gdbserver calls set_desired_thread(0) ['0' means "I want the
continue thread"] which just picks the first thread in the list.
This looks like a dangerous thing to do. GDBserver continues
processing whatever it was doing, but to the wrong thread. If
debugging more than one process, we may even pick the wrong process.
Instead, GDBserver should detect the situation and bail out of
whatever is was doing.
The backends used to pay attention to the set 'cont_thread' (the Hc
thread, used in the old way to resume threads, before vCont), but all
such 'cont_thread' checks have been eliminated meanwhile. The
remaining implicit dependencies that I found on there being a selected
thread in the backends are in the Ctrl-C handling, which some backends
use as thread to send a signal to. Even that seems to me to be better
handled by always using the first thread in the list or by using the
signal_pid PID.
In order to make this a systematic approach, I'm making
set_desired_thread never fallback to a random thread, and instead end
up with current_thread == NULL, like already done in non-stop mode.
Then I updated all callers to handle the situation.
I stumbled on this while fixing other bugs exposed by
gdb.threads/fork-plus-threads.exp test. The problems I saw were fixed
in a different way, but in any case, I think the potential for
problems is more or less obvious, and the resulting code looks a bit
less magical to me.
Tested on x86-64 Fedora 20, w/ native-extended-gdbserver board.
gdb/gdbserver/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* linux-low.c (wait_for_sigstop): Always switch to no thread
selected if the previously current thread dies.
* lynx-low.c (lynx_request_interrupt): Use the first thread's
process instead of the current thread's.
* remote-utils.c (input_interrupt): Don't check if there's no
current thread.
* server.c (gdb_read_memory, gdb_write_memory): If setting the
current thread to the general thread fails, error out.
(handle_qxfer_auxv, handle_qxfer_libraries)
(handle_qxfer_libraries_svr4, handle_qxfer_siginfo)
(handle_qxfer_spu, handle_qxfer_statictrace, handle_qxfer_fdpic)
(handle_query): Check if there's a thread selected instead of
checking whether there's any thread in the thread list.
(handle_qxfer_threads, handle_qxfer_btrace)
(handle_qxfer_btrace_conf): Don't error out early if there's no
thread in the thread list.
(handle_v_cont, myresume): Don't set the current thread to the
continue thread.
(process_serial_event) <Hg handling>: Also set thread_id if the
previous general thread is still alive.
(process_serial_event) <g/G handling>: If setting the current
thread to the general thread fails, error out.
* spu-low.c (spu_resume, spu_request_interrupt): Use the first
thread's lwp instead of the current thread's.
* target.c (set_desired_thread): If the desired thread was not
found, leave the current thread pointing to NULL. Return an int
(boolean) indicating success.
* target.h (set_desired_thread): Change return type to int.
These changes allow debugging multithreaded NPTL xtensa applications.
2015-08-20 Max Filippov <jcmvbkbc@gmail.com>
gdb/gdbserver/
* configure.srv (xtensa*-*-linux*): Add srv_linux_thread_db=yes.
* linux-xtensa-low.c (arch/xtensa.h gdb_proc_service.h): New
#includes.
(ps_get_thread_area): New function.
2015-08-20 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* arch/xtensa.h: New file.
* xtensa-linux-nat.c (gdb_proc_service.h): New #include.
(ps_get_thread_area): New function.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Add call to
set_gdbarch_fetch_tls_load_module_address to enable TLS support.
* xtensa-tdep.c (osabi.h): New #include.
(xtensa_gdbarch_init): Call gdbarch_init_osabi to register
xtensa-specific hooks.
* xtensa-tdep.h (struct xtensa_elf_gregset_t): Add threadptr
member and move the structure to arch/xtensa.h.
While handling "vFile:pread:" packets, gdbserver would read the
number of bytes requested regardless of whether this would fit
into the reply packet. gdbserver would then return a packet's
worth of data and discard the remainder. When accessing large
binaries GDB (via BFD) routinely makes large "vFile:pread:"
requests, resulting in gdbserver allocating large unnecessary
buffers and reading some portions of the file many times over.
This commit causes gdbserver to limit the number of bytes to be
read to a sensible maximum prior to allocating buffers and reading
data.
gdb/gdbserver/ChangeLog:
* hostio.c (handle_pread): Do not attempt to read more data
than hostio_reply_with_data can fit in a packet.
On some older versions of GNU/Linux, gdbserver now fails to build
due to an undefined reference to NT_ARM_VFP. Same issue on Android,
where this macros is undefined until Android API level 21 (Android
5.0 "Lollipop").
This patch modifies linux-aarch32-low.c to define that macros when
not already defined.
gdb/gdbserver/ChangeLog:
* linux-aarch32-low.c (NT_ARM_VFP): Define if not already defined.
This tag allows debugging of MIPS position independent executables
and provides access to shared library information.
gdb/gdbserver/
* linux-low.c (get_r_debug): Handle DT_MIPS_RLD_MAP_REL.
gdb/
* solib-svr4.c (read_program_header): Add base_addr argument to
report the runtime address of the segment.
(find_program_interpreter): Update read_program_header call to pass
a NULL pointer for the new argument.
(scan_dyntag): Add ptr_addr argument to report the runtime address
of the tag payload.
(scan_dyntag_auxv): Likewise and use thew new base_addr argument of
read_program_header to get the base address of the dynamic segment.
(elf_locate_base): Update uses of scan_dyntag, scan_dyntag_auxv and
read_program_header.
(elf_locate_base): Scan for and handle DT_MIPS_RLD_MAP_REL.
Fixes another C++ -fpermissive error:
src/gdb/gdbserver/tracepoint.c:4535:21: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive]
expr_eval_result = ipa_expr_eval_result;
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* tracepoint.c (expr_eval_result): Now an int.
The regcache used to be hidden inside inferiors.c, but since the
tracepoints support that it's a first class object. This also fixes a
few implicit pointer conversion errors in C++ mode, caused by a few
places missing the explicit cast.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct regcache): Forward declare.
(struct thread_info) <regcache_data>: Now a struct regcache
pointer.
* inferiors.c (inferior_regcache_data)
(set_inferior_regcache_data): Now work with struct regcache
pointers.
* inferiors.h (struct regcache): Forward declare.
(inferior_regcache_data, set_inferior_regcache_data): Now work
with struct regcache pointers.
* regcache.c (get_thread_regcache, regcache_invalidate_thread)
(free_register_cache_thread): Remove struct regcache pointer
casts.
Running gdb.threads/process-dies-while-handling-bp.exp against
gdbserver sometimes FAILs because GDBserver drops the connection, but
the logs leave no clue on what the reason could be. Running manually
a few times, I saw the same:
$ ./gdbserver/gdbserver --multi :9999 testsuite/gdb.threads/process-dies-while-handling-bp
Process testsuite/gdb.threads/process-dies-while-handling-bp created; pid = 12766
Listening on port 9999
Remote debugging from host 127.0.0.1
Listening on port 9999
Child exited with status 0
Child exited with status 0
What happened is that an exception escaped and gdbserver reopened the
connection, which led to that second "Listening on port 9999" output.
The error was a failure to access registers from a now-dead thread.
The exception probably shouldn't have escaped here, but meanwhile,
this at least makes the issue less mysterious.
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* server.c (captured_main): On error, print the exception message
to stderr, and if run_once is set, throw a quit.
While hacking on the fix for PR threads/18600 (Threads left stopped
after fork+thread spawn), I once saw its test (fork-plus-threads.exp)
FAIL against gdbserver because move_out_of_jump_pad_callback has a
gdb_breakpoint_here call, and the caller isn't making sure the current
thread points to the right thread. In the case I saw, the current
thread pointed to the wrong process, so gdb_breakpoint_here returned
the wrong answer. Unfortunately I didn't save logs. Still, seems
obvious enough and it should fix a potential occasional racy FAIL.
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (move_out_of_jump_pad_callback): Temporarily switch
the current thread.
Running gdbserver --debug under Valgrind shows:
==4803== Invalid read of size 4
==4803== at 0x432B62: linux_write_memory (linux-low.c:5320)
==4803== by 0x4143F7: write_inferior_memory (target.c:83)
==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362)
==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460)
==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802)
==4803== by 0x4163F3: release_breakpoint (mem-break.c:842)
==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869)
==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891)
==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
==4803== by 0x4134E3: process_serial_event (server.c:4051)
==4803== by 0x4138E4: handle_serial_event (server.c:4196)
==4803== Address 0x4c6b930 is 0 bytes inside a block of size 1 alloc'd
==4803== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4803== by 0x4240C6: xmalloc (common-utils.c:43)
==4803== by 0x41439C: write_inferior_memory (target.c:80)
==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362)
==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460)
==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802)
==4803== by 0x4163F3: release_breakpoint (mem-break.c:842)
==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869)
==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891)
==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
==4803== by 0x4134E3: process_serial_event (server.c:4051)
==4803==
And:
==7272== Conditional jump or move depends on uninitialised value(s)
==7272== at 0x3615E48361: vfprintf (vfprintf.c:1634)
==7272== by 0x414E89: debug_vprintf (debug.c:60)
==7272== by 0x42800A: debug_printf (common-debug.c:35)
==7272== by 0x43937B: my_waitpid (linux-waitpid.c:149)
==7272== by 0x42D740: linux_wait_for_event_filtered (linux-low.c:2441)
==7272== by 0x42DADA: linux_wait_for_event (linux-low.c:2552)
==7272== by 0x42E165: linux_wait_1 (linux-low.c:2860)
==7272== by 0x42F5D8: linux_wait (linux-low.c:3453)
==7272== by 0x4144A4: mywait (target.c:107)
==7272== by 0x413969: handle_target_event (server.c:4214)
==7272== by 0x41A1A6: handle_file_event (event-loop.c:429)
==7272== by 0x41996D: process_event (event-loop.c:184)
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid
returned > 0.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_write_memory): Rewrite debug output to avoid
reading beyond the passed in buffer length.
This field was never set nor used. This patch removes it.
gdb/ChangeLog:
* common/agent.c (symbol_list) <required>: Remove.
gdb/gdbserver/ChangeLog:
* tracepoint.c (symbol_list) <required>: Remove.
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html
This adds a test that has a multithreaded program have several threads
continuously fork, while another thread continuously steps over a
breakpoint.
This exposes several intertwined issues, which this patch addresses:
- When we're stopping and suspending threads, some thread may fork,
and we missed setting its suspend count to 1, like we do when a new
clone/thread is detected. When we next unsuspend threads, the fork
child's suspend count goes below 0, which is bogus and fails an
assertion.
- If a step-over is cancelled because a signal arrives, but then gdb
is not interested in the signal, we pass the signal straight back
to the inferior. However, we miss that we need to re-increment the
suspend counts of all other threads that had been paused for the
step-over. As a result, other threads indefinitely end up stuck
stopped.
- If a detach request comes in just while gdbserver is handling a
step-over (in the test at hand, this is GDB detaching the fork
child), gdbserver internal errors in stabilize_thread's helpers,
which assert that all thread's suspend counts are 0 (otherwise we
wouldn't be able to move threads out of the jump pads). The
suspend counts aren't 0 while a step-over is in progress, because
all threads but the one stepping past the breakpoint must remain
paused until the step-over finishes and the breakpoint can be
reinserted.
- Occasionally, we see "BAD - reinserting but not stepping." being
output (from within linux_resume_one_lwp_throw). That was because
GDB pokes memory while gdbserver is busy with a step-over, and that
suspends threads, and then re-resumes them with proceed_one_lwp,
which missed another reason to tell linux_resume_one_lwp that the
thread should be set back to stepping.
- In a couple places, we were resuming threads that are meant to be
suspended. E.g., when a vCont;c/s request for thread B comes in
just while gdbserver is stepping thread A past a breakpoint. The
resume for thread B must be deferred until the step-over finishes.
- The test runs with both "set detach-on-fork" on and off. When off,
it exercises the case of GDB detaching the fork child explicitly.
When on, it exercises the case of gdb resuming the child
explicitly. In the "off" case, gdb seems to exponentially become
slower as new inferiors are created. This is _very_ noticeable as
with only 100 inferiors gdb is crawling already, which makes the
test take quite a bit to run. For that reason, I've disabled the
"off" variant for now.
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* target/waitstatus.h (enum target_stop_reason)
<TARGET_STOPPED_BY_SINGLE_STEP>: New value.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the fork child's suspend
count if stopping and suspending threads.
(check_stopped_by_breakpoint): If stopped by trace, set the LWP's
stop reason to TARGET_STOPPED_BY_SINGLE_STEP.
(linux_detach): Complete an ongoing step-over.
(lwp_suspended_inc, lwp_suspended_decr): New functions. Use
throughout.
(resume_stopped_resumed_lwps): Don't resume a suspended thread.
(linux_wait_1): If passing a signal to the inferior after
finishing a step-over, unsuspend and re-resume all lwps. If we
see a single-step event but the thread should be continuing, don't
pass the trap to gdb.
(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use
internal_error instead of gdb_assert.
(enqueue_pending_signal): New function.
(check_ptrace_stopped_lwp_gone): Add debug output.
(start_step_over): Use internal_error instead of gdb_assert.
(complete_ongoing_step_over): New function.
(linux_resume_one_thread): Don't resume a suspended thread.
(proceed_one_lwp): If the LWP is stepping over a breakpoint, reset
it stepping.
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.threads/forking-threads-plus-breakpoint.exp: New file.
* gdb.threads/forking-threads-plus-breakpoint.c: New file.
The tail end of linux_wait_1 isn't expecting that the select_event_lwp
machinery can pick a whole-process exit event to report to GDB. When
that happens, both gdb and gdbserver end up quite confused:
...
(gdb)
[Thread 24971.24971] #1 stopped.
0x0000003615a011f0 in ?? ()
c&
Continuing.
(gdb) [New Thread 24971.24981]
[New Thread 24983.24983]
[New Thread 24971.24982]
[Thread 24983.24983] #3 stopped.
0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130
130 pid = ARCH_FORK ();
[New Thread 24984.24984]
Error in re-setting breakpoint -16: PC register is not available
Error in re-setting breakpoint -17: PC register is not available
Error in re-setting breakpoint -18: PC register is not available
Error in re-setting breakpoint -19: PC register is not available
Error in re-setting breakpoint -24: PC register is not available
Error in re-setting breakpoint -25: PC register is not available
Error in re-setting breakpoint -26: PC register is not available
Error in re-setting breakpoint -27: PC register is not available
Error in re-setting breakpoint -28: PC register is not available
Error in re-setting breakpoint -29: PC register is not available
Error in re-setting breakpoint -30: PC register is not available
PC register is not available
(gdb)
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE.
(linux_thread_alive): Use lwp_is_marked_dead.
(extended_event_reported): Delete.
(linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE
instead of extended_event_reported.
(mark_lwp_dead): Don't set the 'dead' flag. Store the waitstatus
as well.
(lwp_is_marked_dead): New function.
(lwp_running): Use lwp_is_marked_dead.
* linux-low.h: Delete 'dead' field, and update 'waitstatus's
comment.
The "extended event with waitstatus" debug output is unreachable, as
it is guarded by "if (!report_to_gdb)". If extended_event_reported is
true, then so is report_to_gdb. Move it to where we print why we're
reporting an event to GDB.
Also, the debug output currently tries to print the wrong struct
target_waitstatus.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_wait_1): Move fork event output out of the
!report_to_gdb check. Pass event_child->waitstatus to
target_waitstatus_to_string instead of ourstatus.
We only support tracepoint for aarch64. Although arm program can run
on aarch64, GDBserver doesn't support tracepoint for it.
gdb/gdbserver:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_supports_tracepoints): Return 0
if current_thread is 32 bit.
In multi-arch debugging, if GDB sends Z0 packet, GDBserver should be
able to do several things below:
- choose the right breakpoint instruction to insert according to the
information available, such as 'kind' in Z0 packet and address,
- choose the right breakpoint instruction to check memory writes and
validate inserted memory breakpoint
- be aware of different breakpoint instructions in $ARCH_breakpoint_at.
unfortunately GDBserver can't do them now. Although x86 GDBserver
supports multi-arch, it doesn't need to support them above because
breakpoint instruction on i686 and x86_64 is the same. However,
breakpoint instructions on aarch64 and arm (arm mode, thumb1, and thumb2)
are different.
I tried to teach aarch64 GDBserver backend to be really
multi-arch-capable in the following ways,
- linux_low_target return the right breakpoint instruction according to
the 'kind' in Z0 packet, and insert_memory_breakpoint can do the right
thing.
- once breakpoint is inserted, the breakpoint data and length is recorded
in each breakpoint object, so that validate_breakpoint and
check_mem_write can get the right breakpoint instruction from each
breakpoint object, rather than from global variable breakpoint_data.
- linux_low_target needs another hook function for pc increment after
hitting a breakpoint.
- let set_breakpoint_at, which is widely used for tracepoint, use the
'default' breakpoint instruction. We can always use aarch64 breakpoint
instruction since arm doesn't support tracepoint yet.
looks it is not a small piece of work, so I decide to disable Z0 packet
on multi-arch, which means aarch64 GDBserver only supports Z0 packet
if it is started to debug only one process (extended protocol is not
used) and process target description is 64-bit.
gdb/gdbserver:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_supports_z_point_type): Return
0 for Z_PACKET_SW_BP if it may be used in multi-arch debugging.
* server.c (extended_protocol): Remove "static".
* server.h (extended_protocol): Declare it.
gdb/gdbserver:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_get_pc): Get PC register on
both aarch64 and aarch32.
(aarch64_set_pc): Likewise.
This patch teaches aarch64-linux GDBserver use 32-bit arm target
description and regs_info if the elf file is 32-bit.
gdb/gdbserver:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* configure.srv (case aarch64*-*-linux*): Append arm-with-neon.o
to srv_regobj and append arm-core.xml arm-vfpv3.xml and
arm-with-neon.xml to srv_xmlfiles.
* linux-aarch64-low.c: Include linux-aarch32-low.h.
(is_64bit_tdesc): New function.
(aarch64_linux_read_description): New function.
(aarch64_arch_setup): Call aarch64_linux_read_description.
(regs_info): Rename to regs_info_aarch64.
(aarch64_regs_info): Return right regs_info.
(initialize_low_arch): Call initialize_low_arch_aarch32.
This patch adds a new regs_info regs_info_aarch32 for aarch32, which
can be used by both aarch64 and arm backend.
gdb/gdbserver:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* configure.srv (srv_tgtobj): Add linux-aarch32-low.o.
* linux-aarch32-low.c: New file.
* linux-aarch32-low.h: New file.
* linux-arm-low.c (arm_fill_gregset): Move it to
linux-aarch32-low.c.
(arm_store_gregset): Likewise.
(arm_fill_vfpregset): Call arm_fill_vfpregset_num
(arm_store_vfpregset): Caa arm_store_vfpregset_num.
(arm_arch_setup): Check if PTRACE_GETREGSET works.
(regs_info): Rename to regs_info_arm.
(arm_regs_info): Return regs_info_aarch32 if
have_ptrace_getregset is 1 and target description is
arm_with_neon or arm_with_vfpv3.
(initialize_low_arch): Don't call init_registers_arm_with_neon.
Call initialize_low_arch_aarch32 instead.
This patch moves variable have_ptrace_getregset from linux-x86-low.c
to linux-low.c, so that arm can use it too.
gdb/gdbserver:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* linux-x86-low.c (have_ptrace_getregset): Move it to ...
* linux-low.c: ... here.
* linux-low.h (have_ptrace_getregset): Declare it.
Implicit void * -> function pointer conversion doesn't work in C++, so
in C++, we need to cast the result of dlsym. This adds a few typedefs
and macros that make this easy. GDBserver's version already had the
CHK macro, so I added it to GDB too.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/gdbserver/ChangeLog:
2015-08-04 Pedro Alves <palves@redhat.com>
* thread-db.c (struct thread_db): Use new typedefs.
(try_thread_db_load_1): Define local TDB_DLSYM macro and use it in
CHK calls.
(disable_thread_event_reporting): Cast result of dlsym to
destination function pointer type.
(thread_db_mourn): Use td_ta_delete_ftype.
gdb/ChangeLog:
2015-08-04 Pedro Alves <palves@redhat.com>
* nat/gdb_thread_db.h (td_init_ftype, td_ta_new_ftype)
(td_ta_map_lwp2thr_ftype, td_ta_thr_iter_ftype)
(td_ta_event_addr_ftype, td_ta_set_event_ftype)
(td_ta_clear_event_ftype, td_ta_event_getmsg_ftype)
(td_thr_validate_ftype, td_thr_get_info_ftype)
(td_thr_event_enable_ftype, td_thr_tls_get_addr_ftype)
(td_thr_tlsbase_ftype, td_symbol_list_ftype, td_ta_delete_ftype):
New typedefs.
* linux-thread-db.c (struct thread_db_info): Use new typedefs.
(try_thread_db_load_1): Define TDB_VERBOSE_DLSYM, TDB_DLSYM , CHK
local macros and use them instead of verbose_dlsym and dlsym
calls.
Running gdb.threads/fork-plus-threads.exp against gdbserver in
extended-remote mode, even though the test passes, we still see broken
behavior:
(gdb) PASS: gdb.threads/fork-plus-threads.exp: set detach-on-fork off
continue &
Continuing.
(gdb) PASS: gdb.threads/fork-plus-threads.exp: continue &
[New Thread 28092.28092]
[Thread 28092.28092] #2 stopped.
[New Thread 28094.28094]
[Inferior 2 (process 28092) exited normally]
[New Thread 28094.28105]
[New Thread 28094.28109]
...
[Thread 28174.28174] #18 stopped.
[New Thread 28185.28185]
[Inferior 10 (process 28174) exited normally]
[New Thread 28185.28196]
[Thread 28185.28185] #20 stopped.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
[Inferior 11 (process 28185) exited normally]
[Inferior 1 (process 28091) exited normally]
PASS: gdb.threads/fork-plus-threads.exp: reached breakpoint
info threads
No threads.
(gdb) PASS: gdb.threads/fork-plus-threads.exp: no threads left
info inferiors
Num Description Executable
* 1 <null> /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/fork-plus-threads
(gdb) PASS: gdb.threads/fork-plus-threads.exp: only inferior 1 left
All the "[Thread FOO] #NN stopped." above are bogus, as well as the
"Cannot remove breakpoints because program is no longer writable.",
which is a consequence.
The problem is that when we intercept a fork event, we should report
the event for the parent, only, and leave the child stopped, but not
report its stop event. GDB later decides whether to follow the parent
or the child. But because handle_extended_wait does not set the
child's last_status.kind to TARGET_WAITKIND_STOPPED, a
stop_all_threads/unstop_all_lwps sequence (e.g., from trying to access
memory) by mistake ends up queueing a SIGSTOP on the child, resuming
it, and then when that SIGSTOP is intercepted, because the LWP has
last_resume_kind set to resume_stop, gdbserver reports the stop to
GDB, as GDB_SIGNAL_0:
...
>>>> entering unstop_all_lwps
unstopping all lwps
proceed_one_lwp: lwp 1600
client wants LWP to remain 1600 stopped
proceed_one_lwp: lwp 1828
Client wants LWP 1828 to stop. Making sure it has a SIGSTOP pending
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending sigstop to lwp 1828
pc is 0x3615ebc7cc
Resuming lwp 1828 (continue, signal 0, stop expected)
continue from pc 0x3615ebc7cc
unstop_all_lwps done
sigchld_handler
<<<< exiting unstop_all_lwps
handling possible target event
>>>> entering linux_wait_1
linux_wait_1: [<all threads>]
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x1): status(137f), 1828
LWFE: waitpid(-1, ...) returned 1828, ERRNO-OK
LLW: waitpid 1828 received Stopped (signal) (stopped)
pc is 0x3615ebc7cc
Expected stop.
LLW: resume_stop SIGSTOP caught for LWP 1828.1828.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
linux_wait_1 ret = LWP 1828.1828, 1, 0
<<<< exiting linux_wait_1
Writing resume reply for LWP 1828.1828:1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tested on x86_64 Fedora 20, extended-remote.
gdb/gdbserver/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the child's last
reported status to TARGET_WAITKIND_STOPPED.
After previous patch, we don't need global variable arm_hwcap. This
patch is to remove it.
gdb/gdbserver:
2015-07-30 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (arm_hwcap): Remove it.
(arm_read_description): New local variable arm_hwcap. Don't
set arm_hwcap to zero.
arm_hwcap is a global variable, and we should avoid using it as much
as we can. Instead of checking arm_hwcap, we can check whether
regcache->tdesc is a certain kind of target description. This is
what this patch does.
gdb/gdbserver:
2015-07-30 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (arm_fill_wmmxregset): Don't use arm_hwcap.
Use regcache->tdesc instead.
(arm_store_wmmxregset): Likewise.
(arm_fill_vfpregset): Likewise.
(arm_store_vfpregset): Likewise.
In order to align with arm-linux-nat.c counterparts, we don't use
arm_num_regs and arm_regmap in functions arm_fill_gregset and
arm_store_gregset. Instead, we use register numbers. With this
patch applied, arm_fill_gregset and arm_store_gregset don't need
arm_num_regs and arm_regmap, and they will be moved to a separate
file shared for both arm and aarch64 in the following patch.
gdb/gdbserver:
2015-07-30 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c: Include arch/arm.h.
(arm_fill_gregset): Don't use arm_num_regs and arm_regmap.
(arm_store_gregset): Likewise.
Since Pedro's ptrace cleanups, the MIPS buildbot compilation fails.
Code in MIPS native uses ptrace with 3 arguments, where ptrace requires
4. When looking at the definition of ptrace in
/usr/include/sys/ptrace.h, it shows that it takes a variable number of
arguments. The wrapper macro in nat/gdb_ptrace.h takes a fixed number
of arguments (4). That would explain why it used to work and stopped.
I am pushing this as obvious, tell me if there is any problem.
I built-tested this with a MIPS toolchain (ct-ng), but I don't have any
setup to test it. At least it should put back the buildbot builder in a
better shape.
gdb/ChangeLog:
* mips-linux-nat.c (write_watchpoint_regs): Add NULL as ptrace's 4th
parameter.
(mips_linux_new_thread): Likewise.
* nat/mips-linux-watch.c (mips_linux_read_watch_registers): Likewise.
gdb/gdbserver/ChangeLog:
* linux-mips-low.c (mips_linux_prepare_to_resume): Add NULL as
ptrace's 4th parameter.
We don't use PTRACE_PEEKUSR/PTRACE_POKEUSR on aarch64-linux, so don't
need to set srv_linux_usrregs. This patch removes that line.
gdb/gdbserver:
2015-07-27 Yao Qi <yao.qi@linaro.org>
* configure.srv (case aarch64*-*-linux*): Don't set
srv_linux_usrregs.
Building in C++ mode issues ~40 warnings like this:
../../src/gdb/linux-nat.c: In function ‘int linux_handle_extended_wait(lwp_info*, int, int)’:
../../src/gdb/linux-nat.c:2016:51: warning: invalid conversion from ‘int’ to ‘__ptrace_request’ [-fpermissive]
ptrace (PTRACE_GETEVENTMSG, pid, 0, &new_pid);
The issue is that in glibc, ptrace's first parameter is an enum.
That's not a problem if we pick the PTRACE_XXX requests from
sys/ptrace.h, as those will be values of the corresponding enum.
However, we have fallback definitions for PTRACE_XXX symbols when the
system headers miss them (such as PTRACE_GETEVENTMSG above), and those
are plain integer constants. E.g., nat/linux-ptrace.h:
#define PTRACE_GETEVENTMSG 0x4201
One idea would be to fix this by defining those fallbacks like:
-#define PTRACE_GETEVENTMSG 0x4201
+#define PTRACE_GETEVENTMSG ((enum __ptrace_request) 0x4201)
However, while glibc's ptrace uses enum __ptrace_request for first
parameter:
extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
other libc's, like e.g., Android's bionic do not -- in that case, the
first parameter is int:
long ptrace(int request, pid_t pid, void * addr, void * data);
So the fix I came up is to make configure/ptrace.m4 also detect the
type of the ptrace's first parameter and defin PTRACE_TYPE_ARG1, as
already does the for parameters 3-4, and then simply wrap ptrace with
a macro that casts the first argument to the detected type. (I'm
leaving adding a nicer wrapper for when we drop building in C).
While this adds the wrapper, GNU/Linux files won't use it until the
next patch, which makes all native GNU/Linux files include
gdb_ptrace.h.
gdb/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* ptrace.m4 (ptrace tests): Test in C++ mode. Try with 'enum
__ptrace_request as first parameter type instead of int.
(PTRACE_TYPE_ARG1): Define.
* nat/gdb_ptrace.h [!PTRACE_TYPE_ARG5] (ptrace): Define as wrapper
that casts first argument to PTRACE_TYPE_ARG1.
* config.in: Regenerate.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2015-07-24 Pedro Alves <palves@redhat.com>
* config.in: Regenerate.
* configure: Regenerate.
