Commit graph

23803 commits

Author SHA1 Message Date
Marcin Kościelnicki
5f034a78b9 gdb: Add guess_tracepoint_registers hook to gdbarch.
When we're looking at a tracefile trace frame where registers are not
available, and the tracepoint has only one location, we supply
the location's address as the PC register.  However, this only works
if PC is not a pseudo register, and individual architectures may want
to guess more registers.  Add a gdbarch hook that will handle that.

gdb/ChangeLog:

	* arch-utils.c (default_guess_tracepoint_registers): New function.
	* arch-utils.h (default_guess_tracepoint_registers): New prototype.
	* gdbarch.c: Regenerate.
	* gdbarch.h: Regenerate.
	* gdbarch.sh: Add guess_tracepoint_registers hook.
	* tracefile.c (tracefile_fetch_registers): Use the new gdbarch hook.
2016-02-18 17:21:22 +01:00
Gary Benson
88178e828a Add missing cleanup in exec_file_locate_attach
exec_file_locate_attach allocates memory for full_exec_path (using
either exec_file_find, source_full_path_of or xstrdup) but this
memory is never freed.  This commit adds the necessary cleanup.

gdb/ChangeLog:

	* exec.c (exec_file_locate_attach): Add missing cleanup.
2016-02-17 16:47:11 +00:00
Don Breazeal
4041ed7780 PR remote/19496, internal err forking-threads-plus-bkpt
This patch fixes an internal error that occurs in
gdb.threads/forking-threads-plus-breakpoint.exp:

/blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the
current address space of thread Thread 3170.3170

In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170
because it had been overwritten in inferior_appeared, called as follows:

inferior_appeared
  remote_add_inferior
    remote_notice_new_inferior
      remote_update_thread_list

The cause of the problem was the following sequence of events:

* GDB knows only about the main thread

* the first fork event is reported to GDB, saved as pending_event

* qXfer:threads:read gets the threads from the remote.
  remove_new_fork_children id's the fork child from the pending event
  and removes it from the list reported to GDB.  All the rest of the
  threads, including the fork parent, are added to the GDB thread list.

* GDB stops all the threads.  All the stop events are pushed onto the
  stop reply queue behind the pending fork event.  The fork waitstatus
  is saved in the fork parent thread's pending status field
  thread_info.suspend.

* remote_wait_ns calls queued_stop_reply and process_stop_reply to
  remove the fork event from the front of the stop reply queue and save
  event information in the thread_info structure for the fork parent
  thread.  Unfortunately, none of the information saved in this way is
  the fork-specific information.

* A subsequent qXfer:threads:read packet gets the thread list including
  the fork parent and fork child.  remove_new_fork_children checks the
  thread list to see if there is a fork parent, doesn't find one, checks
  the stop reply queue for a pending fork event, doesn't find one, and
  allows the fork child thread to be reported to GDB before the fork
  event has been handled.  remote_update_thread_list calls
  remote_notice_new_thread and overwrites the current (main) thread in
  inferior_appeared.

So the fork event has been reported out of target_wait but it was left
pending on the infrun side (infrun.c:save_waitstatus).  IOW, the fork
event hasn't been processed by handle_inferior_event yet, so it hasn't
made it to tp->pending_follow yet.

The fix is to check thread_info.suspend along with the
thread_info.pending_follow in remote.c:remove_new_fork_children, to
prevent premature reporting of the fork child thread creation.

gdb/ChangeLog:

	PR remote/19496
	* remote.c (remove_new_fork_children): Check for pending
	fork status in thread_info.suspend.

gdb/testsuite/ChangeLog:

	PR remote/19496
	* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
	Remove kfail for PR remote/19496.
2016-02-16 08:56:06 -08:00
Yao Qi
b442c911ee Fix cleanup in arm_linux_software_single_step
I see the following error in testing aarch64 GDB debugging arm
program.

(gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2
continue
Continuing.
=================================================================
==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0
    #0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M
    #1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M
    #2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M
    #3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M
    #4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M
    #5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M
    #6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M
    #7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M
    #8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M
    #9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M
    #10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M
    #11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
    #12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M
    #13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
    #14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M
    #15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M
    #16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M
    #17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2)

looks we should discard cleanup if function
arm_linux_software_single_step returns early, or create cleanup when
it is needed.

gdb:

2016-02-16  Yao Qi  <yao.qi@linaro.org>

	* arm-linux-tdep.c (arm_linux_software_single_step): Assign
	'old_chain' later.
2016-02-16 13:53:35 +00:00
Yao Qi
553cb5270f Remove PC from syscall_next_pc
Method syscall_next_pc of struct arm_get_next_pcs_ops has an argument
PC, which is not necessary, because PC can be got from regcache in
'struct arm_get_next_pcs'.  This patch removes the PC argument of
syscall_next_pc.

gdb:

2016-02-16  Yao Qi  <yao.qi@linaro.org>

	* arch/arm-get-next-pcs.h (struct arm_get_next_pcs_ops)
	<syscall_next_pc>: Remove argument PC.  Callers updated.
	* arm-linux-tdep.c (arm_linux_get_next_pcs_syscall_next_pc):
	Remove argument PC.  Get pc from regcache_read_pc.
	* arm-tdep.c (arm_get_next_pcs_syscall_next_pc): Remove
	argument PC.

gdb/gdbserver:

2016-02-16  Yao Qi  <yao.qi@linaro.org>

	* linux-arm-low.c (get_next_pcs_syscall_next_pc): Remove argument
	PC.  Get pc from regcache_read_pc.
2016-02-16 13:47:17 +00:00
Yao Qi
0a0da55626 Don't print 0x for core_addr_to_string_nz
core_addr_to_string_nz returns string which has "0x" prefix, so don't
need to print "0x" again.  This patch is to remove the "0x".

gdb:

2016-02-15  Yao Qi  <yao.qi@linaro.org>

	* aarch64-tdep.c (aarch64_analyze_prologue): Remove "0x".
2016-02-15 10:05:56 +00:00
Yao Qi
01113bc1c5 [ARM] Software single step cross kernel helpers
GDB step cross kernel helpers only works if the kernel helpers are tail
called, which is the case how it is used in glibc.  See __aeabi_read_tp
in sysdeps/unix/sysv/linux/arm/aeabi_read_tp.S.  In __aeabi_read_tp,
branch/jump to the kernel helper is the last instruction, and the next
instruction address is in LR, which is in caller function.  GDB can
handle this correctly.  For example, glibc function __GI___ctype_init
calls __aeabi_read_tp

   0xb6e19b30 <__GI___ctype_init+4>:	ldr	r3, [pc, #80]	;
   0xb6e19b34 <__GI___ctype_init+8>:	bl	0xb6e0a6e0 <__aeabi_read_tp>
   0xb6e19b38 <__GI___ctype_init+12>:	ldr	r3, [pc, r3]

and __aeabi_read_tp calls kernel helper,

(gdb) disassemble __aeabi_read_tp
   0xb6fef5d0 <+0>:	mvn	r0, #61440	; 0xf000
   0xb6fef5d4 <+4>:	sub	pc, r0, #31

once GDB or GDBserver single step instruction on 0xb6fef5d4, LR is
0xb6e19b38, which is right address of next instruction to set breakpoint
on.

However, if the kernel helpers are not tail-called, the LR is still the
address in the caller function of kernel helper's caller, which isn't
the right address of next instruction to set breakpoint on.  For example,
we use kernel helper in main,

(gdb) disassemble main
....
   0x00008624 <+32>:    mov     r3, #4064       ; 0xfe0^M
   0x00008628 <+36>:    movt    r3, #65535      ; 0xffff^M
   0x0000862c <+40>:    blx     r3
   0x00008630 <+44>:    ldr     r3, [r11, #-8]

kernel helper is called on 0x0000862c and the expected next instruction
address is 0x00008630, but the LR now is the return address of main.
The problem here is LR may not have the right address because when we
single step the instruction, it isn't executed yet, so the LR isn't
updated.  This patch fix this problem by decoding instruction, if the
instruction updates LR (BL and BLX), the next instruction address is
PC + INSN_SIZE, otherwise, get the address of next instruction from LR.

gdb:

2016-02-12  Yao Qi  <yao.qi@linaro.org>

	* arch/arm-linux.c (arm_linux_get_next_pcs_fixup): Calculate
	nextpc according to instruction.

gdb/testsuite:

2016-02-12  Yao Qi  <yao.qi@linaro.org>

	* gdb.arch/arm-single-step-kernel-helper.c: New.
	* gdb.arch/arm-single-step-kernel-helper.exp: New.
2016-02-12 15:58:56 +00:00
Yao Qi
ed443b61e1 [ARM] Fixup PC in software single step
When I exercise GDBserver software single step, I see the following
error, which has been already handled by GDB properly.

In GDBserver log, we can see, GDBserver tries to single step instruction
on 0xb6e0a6e4, and destination address is 0xffff0fe0,

 stop pc is 0xb6e0a6e4
 Writing f001f0e7 to 0xffff0fe0 in process 7132
 Failed to insert breakpoint at 0xffff0fe0 (Input/output error).
 Failed to insert breakpoint at 0xffff0fe0 (-1).

(gdb) disassemble __aeabi_read_tp,+8
Dump of assembler code from 0xb6e0a6e0 to 0xb6e0a6e8:
   0xb6e0a6e0 <__aeabi_read_tp+0>:	mvn	r0, #61440	; 0xf000
   0xb6e0a6e4 <__aeabi_read_tp+4>:	sub	pc, r0, #31

however, it fails inserting breakpoint there.  This problem has already
fixed by GDB, see comments in arm-linux-tdep.c:arm_linux_software_single_step

      /* The Linux kernel offers some user-mode helpers in a high page.  We can
	 not read this page (as of 2.6.23), and even if we could then we
	 couldn't set breakpoints in it, and even if we could then the atomic
	 operations would fail when interrupted.  They are all called as
	 functions and return to the address in LR, so step to there
	 instead.  */

so we need to do the same thing in GDB side as well.  This patch adds
a new field fixup in arm_get_next_pcs_ops, so that we can fix up PC
for arm-linux target.  In this way, both GDB and GDBserver can single
step instructions going to kernel helpers.

gdb:

2016-02-12  Yao Qi  <yao.qi@linaro.org>

	* arch/arm-get-next-pcs.c (arm_get_next_pcs): Call
	self->ops->fixup if it isn't NULL.
	* arch/arm-get-next-pcs.h: Include gdb_vecs.h.
	(struct arm_get_next_pcs_ops) <fixup>: New field.
	* arch/arm-linux.c: Include common-regcache.h and
	arch/arm-get-next-pcs.h.
	(arm_linux_get_next_pcs_fixup): New function.
	* arch/arm-linux.h (arm_linux_get_next_pcs_fixup): Declare.
	* arm-linux-tdep.c (arm_linux_get_next_pcs_ops): Initialize
	it with arm_linux_get_next_pcs_fixup.
	(arm_linux_software_single_step): Move code to
	arm_linux_get_next_pcs_fixup.
	* arm-tdep.c (arm_get_next_pcs_ops): Initialize it.

gdb/gdbserver:

2016-02-12  Yao Qi  <yao.qi@linaro.org>

	* linux-arm-low.c (get_next_pcs_ops): Initialize it with
	arm_linux_get_next_pcs_fixup.
2016-02-12 15:58:52 +00:00
Marcin Kościelnicki
d21b5f15d9 gdb: Fix build failure in xml-tdesc.c without expat.
Introduced by 18d3cec54e.

gdb/ChangeLog:

	* xml-tdesc.c (target_fetch_description_xml) [!HAVE_LIBEXPAT]: Warn
	and return NULL.
2016-02-12 11:21:00 +01:00
Markus Metzger
33b4777ca1 btrace, frame: fix crash in get_frame_type
In skip_artificial_frames we repeatedly call get_prev_frame_always until we get
a non-inline and non-tailcall frame assuming that there must be such a frame
eventually.

For record targets, however, we may have a frame chain that consists only of
artificial frames.  This leads to a crash in get_frame_type when dereferencing a
NULL frame pointer.

Change skip_artificial_frames and skip_tailcall_frames to return NULL in such a
case and modify each caller to cope with a NULL return.

In frame_unwind_caller_pc and frame_unwind_caller_arch, we simply assert that
the returned value is not NULL.  Their caller was supposed to check
frame_unwind_caller_id before calling those functions.

In other cases, we thrown an error.

In infcmd further move the skip_tailcall_frames call to the forward-stepping
case since we don't need a frame for reverse execution and we don't want to fail
because of that.  Reverse-finish does make sense for a tailcall frame.

gdb/
	* frame.h (skip_tailcall_frames): Update comment.
	* frame.c (skip_artificial_frames, skip_tailcall_frames): Return NULL
	if only	artificial frames are found.  Update comment.
	(frame_unwind_caller_id): Handle NULL return.
	(frame_unwind_caller_pc, frame_unwind_caller_arch): Assert that
	skip_artificial_frames does not return NULL.
	(frame_pop): Add an error if only tailcall frames are found.
	* infcmd.c (finish_command): Move skip_tailcall_frames call into forward-
	execution case.  Add an error if only tailcall frames are found.

testsuite/
	* gdb.btrace/tailcall-only.exp: New.
	* gdb.btrace/tailcall-only.c: New.
	* gdb.btrace/x86_64-tailcall-only.S: New.
	* gdb.btrace/i686-tailcall-only.S: New.
2016-02-12 09:49:48 +01:00
Markus Metzger
a038fa3e14 stack: check frame_unwind_caller_id
Callers of frame_unwind_caller_* functions are supposed to check
frame_unwind_caller_id.

Add such a check to frame_info and treat an invalid caller ID as if the caller
PC were not available.

gdb/
	* stack.c (frame_info): Check frame_unwind_caller_id.
2016-02-12 09:46:31 +01:00
Markus Metzger
2f3ef606b9 frame: add skip_tailcall_frames
Add a new function skip_tailcall_frames to skip TAILCALL_FRAME frames.

gdb/
	* frame.h (skip_tailcall_frames): New.
	* frame.c (skip_tailcall_frames): New.
	(frame_pop): Call skip_tailcall_frames.
	* infcmd.c (finish_command): Call skip_tailcall_frames.
2016-02-12 09:44:42 +01:00
Pedro Alves
e352bf0a3c Support 'make check-parallel' in gdb's build dir
Currently, you can cd to the gdb/testsuite/ dir and use
make check-parallel, instead of using FORCE_PARALLEL:

 $ make -j8 check-parallel RUNTESTFLAGS="--target_board=native-gdbserver"
 $ make -j8 check RUNTESTFLAGS="--target_board=native-gdbserver" FORCE_PARALLEL=1

But you can't do that in the build/gdb/ dir:

 $ make check-parallel RUNTESTFLAGS="--target_board=native-gdbserver"
 make: *** No rule to make target `check-parallel'.  Stop.

I find check-parallel a bit more convenient, and more typo-proof, so
this patch makes it work from the gdb build dir too.

While documenting this in testsuite/README, I found that the parallel
testing mode would better be pulled out to its own section and
extended.

gdb/ChangeLog:
2016-02-11  Pedro Alves  <palves@redhat.com>

	* Makefile.in (check-parallel): New rule.

gdb/testsuite/ChangeLog:
2016-02-11  Pedro Alves  <palves@redhat.com>

	* README (Parallel testing): New section.
	(GDB_PARALLEL): Rewrite.
	(FORCE_PARALLEL): Document.
2016-02-11 19:36:39 +00:00
Simon Marchi
bec2ab5a15 arm-tdep.c: Remove unused variables
Just a little bit of cleanup.

gdb/ChangeLog:

	* arm-tdep.c (arm_skip_prologue): Remove unused variables.
	(arm_analyze_prologue): Likewise.
	(arm_scan_prologue): Likewise.
	(arm_m_exception_prev_register): Likewise.
	(arm_copy_block_xfer): Likewise.
	(thumb2_copy_block_xfer): Likewise.
	(arm_decode_miscellaneous): Likewise.
	(arm_decode_ld_st_word_ubyte): Likewise.
	(arm_decode_svc_copro): Likewise.
	(thumb2_decode_svc_copro): Likewise.
	(thumb_copy_16bit_ldr_literal): Likewise.
	(thumb_copy_pop_pc_16bit): Likewise.
	(decode_thumb_32bit_ld_mem_hints): Likewise.
	(arm_show_force_mode): Likewise.
	(_initialize_arm_tdep): Likewise.
	(arm_record_strx): Likewise.
	(arm_record_extension_space): Likewise.
	(arm_record_data_proc_misc_ld_str): Likewise.
	(arm_record_exreg_ld_st_insn): Likewise.
	(arm_record_vfp_data_proc_insn): Likewise.
	(arm_record_coproc_data_proc): Likewise.
	(thumb_record_misc): Likewise.
	(thumb_record_ldm_stm_swi): Likewise.
	(thumb2_record_ld_st_dual_ex_tbb): Likewise.
	(thumb2_record_ld_mem_hints): Likewise.
	(thumb2_record_lmul_lmla_div): Likewise.
	(thumb2_record_asimd_struct_ld_st): Likewise.
	(arm_process_record): Likewise.
2016-02-11 14:09:25 -05:00
Simon Marchi
2ba163c8d1 arm-tdep.c: Remove unused arm_displaced_step_copy_insn
This function is never used, since it is superseded by
arm_linux_displaced_step_copy_insn.

gdb/ChangeLog:

	* arm-tdep.c (arm_displaced_step_copy_insn): Remove.
	(ARM displaced stepping support): Remove reference to
	arm_displaced_step_copy_insn in comment.
	* arm-tdep.h (arm_displaced_step_copy_insn): Remove.
	* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Remove
	reference to arm_displaced_step_copy_insn in comment.
2016-02-11 14:08:53 -05:00
Simon Marchi
615234c107 arm-tdep.c: Change type of insn parameters
Almost obvious... change the type of some insn parameters, so that it
matches the rest of the code.

gdb/ChangeLog:

	* arm-tdep.c (thumb_copy_unmodified_16bit): Change type of insn.
	(thumb_copy_b): Likewise.
	(arm_decode_b_bl_ldmstm): Likewise.
	(thumb_copy_16bit_ldr_literal): Likewise.
	(thumb_copy_pop_pc_16bit): Likewise.
2016-02-11 13:21:32 -05:00
Antoine Tremblay
82e9becd8a Use the target architecture when encoding tracepoint actions
This patch uses the target architecture rather then the objfile
architecture when encoding tracepoint actions.

The target architecture may contain additional registers. E.g. ARM VFP
registers. This information is needed to allow their collection. Since we
can never know whether the registers numbers in the target match the
binary's we have to use tdesc here.

One note about combined debuggers / multi-inferior from Pedro Alves:

In the combined debugger case taking Cell as the practical example that
gdb supports currently:

In that case, the main target_gdbarch() will be powerpc, but you may have set a
tracepoint on _spu_ code, which has a different gdbarch.  so for that case,
target_gdbarch would be wrong.  I think that in that case, we'd need to
find __the_ target/tdesc gdbarch that is (bfd) compatible with the
objfile's gdbarch.

I think cell/spu gdbserver doesn't support tracepoints, so we can ignore
this for now.

The multi-inferior/process case is somewhat related, but its simpler.
each inferior has its own gdbarch.

That is, target_gdbarch depends on the current inferior selected.
In fact, that just returns inferior->gdbarch nowaways.

No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }

gdb/ChangeLog:

	* tracepoint.c (encode_actions_1): Use target_gdbarch () rather
	than loc->gdbarch.
2016-02-11 08:14:35 -05:00
Marcin Kościelnicki
5ac87a997f gdb.trace: Read XML target description from tfile.
gdb/ChangeLog:

	* tracefile-tfile.c (trace_tdesc): New static variable.
	(tfile_open): Clear trace_tdesc, call target_find_description.
	(tfile_interp_line): Recognize tdesc lines.
	(tfile_close): Clear trace_tdesc.
	(tfile_xfer_partial_features): New function.
	(tfile_xfer_partial): Call tfile_xfer_partial_features.
	(tfile_append_tdesc_line): New function.
2016-02-10 23:31:13 +01:00
Marcin Kościelnicki
18d3cec54e gdb.trace: Save XML target description in tfile.
gdb/ChangeLog:

	* ctf.c (ctf_write_tdesc): New function.
	(ctf_write_ops): Wire in ctf_write_tdesc.
	* tracefile-tfile.c (tfile_write_tdesc): New function.
	(tfile_write_ops): Wire in tfile_write_tdesc.
	* tracefile.c (trace_save): Call write_tdesc method.
	* tracefile.h (struct trace_file_write_ops): Add write_tdesc method.
	* xml-tdesc.c (target_fetch_description_xml): New function.
	* xml-tdesc.h: Add target_fetch_description_xml prototype.
2016-02-10 23:31:11 +01:00
Simon Marchi
550dc4e266 arm-tdep.c: Fix typo
unpriveleged -> unprivileged

gdb/ChangeLog:

	* arm-tdep.c (arm_copy_extra_ld_st): Fix "unpriveleged" typo.
	(arm_decode_dp_misc): Likewise.
2016-02-10 10:10:18 -05:00
Marcin Kościelnicki
62e5fd57bc gdb/x86: Implement ax_pseudo_register_collect hook.
Makes "collect $ymm15" action work.

gdb/ChangeLog:

	* amd64-tdep.c (amd64_ax_pseudo_register_collect): New function.
	(amd64_init_abi): Fill ax_pseudo_register_collect hook.
	* gdb/i386-tdep.c (i386_pseudo_register_read_into_value): Remove
	misleading comment.
	(i386_pseudo_register_write): Ditto.
	(i386_ax_pseudo_register_collect): New function.
	(i386_gdbarch_init): Fill ax_pseudo_register_collect hook.
	* i386-tdep.h: Add i386_ax_pseudo_register_collect prototype.
2016-02-10 15:30:31 +01:00
Marcin Kościelnicki
e909d859f5 gdb.trace: Use g packet order in tfile_fetch_registers.
tfile_fetch_registers currently wrongly fetches registers using
gdb order instead of g packet order.  On x86_64 with AVX, this causes
problems with ymm*h and orig_rax registers: gdb has ymm*h first, while
g packet has orig_rax first.

gdb/ChangeLog:

	* tracefile-tfile.c (tfile_fetch_registers): Use g packet order
	instead of gdb order.

gdb/doc/ChangeLog:

	* gdb.texinfo (Trace File Format): Remove misleading information
	about register block ordering.
2016-02-10 15:30:13 +01:00
Marcin Kościelnicki
473b99e572 gdb.trace: Fix off-by-one in tfile_fetch_registers.
This resulted in the last register being considered unavailable.
On plain x86_64 (without AVX), this happened to be orig_rax.

gdb/ChangeLog:

	* tracefile-tfile.c (tfile_fetch_registers): Fix off-by-one in bounds
	check.
2016-02-10 14:50:22 +01:00
Joel Brobecker
1233c0bae6 Update NEWS post GDB 7.11 branch creation.
gdb/ChangeLog:

	* NEWS: Create a new section for the next release branch.
	Rename the section of the current branch, now that it has
	been cut.
2016-02-10 07:28:01 +04:00
Joel Brobecker
d1dc094269 Bump version to 7.11.50.DATE-git.
Now that the GDB 7.11 branch has been created, we can
bump the version number.

gdb/ChangeLog:

	GDB 7.11 branch created (9ef9e6a6a0):
	* version.in: Bump version to 7.11.50.DATE-git.
2016-02-10 07:20:26 +04:00
Keith Seitz
9ef9e6a6a0 breakpoints/19546: Fix crash after updating breakpoints
One of the last checks update_breakpoints_after_exec does while looping
over the list of breakpoints is check that the breakpoint has a valid
location spec. It uses event_location_empty_p to check if the location spec
is "empty", and if it is, the breakpoint is deleted.

momentary_breakpoint types rely on setting the breakpoint structure's
location spec to NULL, thereby causing an update to delete the breakpoint.
However, event_location_empty_p assumed that locations were never NULL.
As a result, GDB would crash dereferencing a NULL pointer whenever
update_breakpoints_after_exec would encounter a momentary_breakpoint.

This patch creates a new wrapper/helper function which tests that the given
breakpoint's location spec is non-NULL and if it is not "empty"
or "unspecified."

gdb/ChangeLog

	PR breakpoints/19546
	* breakpoint.c (breakpoint_event_location_empty_p): New function.
	(update_breakpoints_after_exec, bkpt_re_set): Use this new function
	instead of event_location_empty_p.

gdb/testsuite/ChangeLog

	PR breakpoints/19546
	* gdb.base/infcall-exec.c: New file.
	* gdb.base/infcall-exec2.c: New file.
	* gdb.base/infcall-exec.exp: New file.
2016-02-09 16:04:45 -08:00
Keith Seitz
39a67dc4f7 Enable/update legacy linespecs in MI.
MI is currently using string_to_event_location to enable the use of legacy
linespecs, but using this function (until this patchset) had the (as yet
unnoticed) side effect of allowing both MI and CLI representation for
explicit locations.

This patch simply changes MI to use the same legacy linespec functions
that the python and guile interpreters use.  This eliminates the CLI syntax
for explicit locations (in MI).

gdb/ChangeLog

	* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use
	string_to_event_location_basic instead of string_to_event_location.
2016-02-09 14:31:04 -08:00
Keith Seitz
a96e36da2f Use string_to_event_location_basic in guile.
This patch, analogous to the previous python patch, implements proper
legacy linespec support in guile code using the newly introduced
string_to_event_location_basic.

gdb/ChangeLog

	* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip
	leading whitespace and use string_to_event_location_basic instead
	of new_linespec_location.

gdb/testsuite/ChangeLog

	* gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure.
	(toplevel): Call test_bkpt_address.
2016-02-09 14:29:21 -08:00
Keith Seitz
9f61929fd8 python/19506 -- gdb.Breakpoint address location regression
Now that "legacy" linespecs benefit from consolidated support in
string_to_event_location_basic, python's Breakpoint command should use this
function to turn strings into event locations.

As a result, this patch fixes python/19506. Before:

(gdb) python gdb.Breakpoint("*main")
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: Function "*main" not defined.
Error while executing Python code.

After:

(gdb) python gdb.Breakpoint("*main")
Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32.

gdb/ChangeLog

	PR python/19506
	* python/py-breakpoint.c (bppy_init): Use
	string_to_event_location_basic instead of new_linespec_location.

gdb/testsuite/ChangeLog

	PR python/19506
	* gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure.
	(toplevel): Call test_bkpt_address.
2016-02-09 14:27:50 -08:00
Keith Seitz
eeb1af437c Refactor string_to_event_location for legacy linespec support.
This patch refactors string_to_event_location, breaking it into two
separate functions:

1) string_to_event_location_basic
A "basic" string parser that implements support for "legacy" linespecs
(linespec, address, and probe locations).  This function is intended to
be used by any UI wishing/needing to support this legacy behavior.

2) string_to_event_location
This is now intended as a CLI-only function which adds explicit location
parsing in a CLI-appropriate manner (in the form of traditional option/value
pairs).

Together these patches serve to simplify string-to-event location parsing
for all existing non-CLI interfaces (MI, guile, and python).

gdb/ChangeLog

	* location.c (string_to_explicit_location): Note that "-p" is
	reserved for probe locations and return NULL for any input
	that starts with that.
	(string_to_event_location): Move "legacy" linespec code to ...
	(string_to_event_location_basic): ... here.
	* location.h (string_to_event_location): Update comment.
	(string_to_event_location_basic): New function.
2016-02-09 10:02:53 -08:00
Simon Marchi
1e94266c4d Modernize configure.ac's
Using AC_OUTPUT with arguments has been deprecated for some time in
autoconf, even in version 2.64, which we are using.  This change should
not affect functionality.

I also removed the "exit 0"'s, they shouldn't be necessary.

gdb/ChangeLog:

	* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
	to AC_OUTPUT.  Remove "exit 0" at the end.
	* configure: Regenerate.

gdb/testsuite/ChangeLog:

	* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
	to AC_OUTPUT.
	* configure: Regenerate.

gdb/gdbserver/ChangeLog:

	* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
	to AC_OUTPUT.
	* configure: Regenerate.
2016-02-09 09:01:58 -05:00
Pedro Alves
2a7f3dffce Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn't
PR19548 shows that we still have problems related to 13fd3ff343:

 [PR17431: following execs with "breakpoint always-inserted on"]
 https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html

The problem this time is that we currently update the global location
list and try to insert breakpoint locations after re-setting _each_
breakpoint in turn.

Say:

 - We have _more_ than one breakpoint set.  Let's assume 2.

 - There's a breakpoint with a pre-exec address that ends up being an
   unmapped address after the exec.

 - That breakpoint is NOT the first in the breakpoint list.

Then when handling an exec, and we re-set the first breakpoint in the
breakpoint list, we mistakently try to install the old pre-exec /
un-re-set locations of the other breakpoint, which fails:

 (gdb) continue
 Continuing.
 process 28295 is executing new program: (...)/execl-update-breakpoints2
 Error in re-setting breakpoint 1: Warning:
 Cannot insert breakpoint 2.
 Cannot access memory at address 0x1000764

 Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34
 34        len = strlen (argv[0]);
 (gdb)

Fix this by deferring the global location list update till after all
breakpoints are re-set.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/ChangeLog:
2016-02-09  Pedro Alves  <palves@redhat.com>

	PR breakpoints/19548
	* breakpoint.c (create_overlay_event_breakpoint): Don't update
	global location list here.
	(create_longjmp_master_breakpoint)
	(create_std_terminate_master_breakpoint)
	(create_exception_master_breakpoint, create_jit_event_breakpoint)
	(update_breakpoint_locations):
	(breakpoint_re_set): Update global location list after all
	breakpoints are re-set.

gdb/testsuite/ChangeLog:
2016-02-09  Pedro Alves  <palves@redhat.com>

	PR breakpoints/19548
	* gdb.base/execl-update-breakpoints.c (some_function): New
	function.
	(main): Call it.
	* gdb.base/execl-update-breakpoints.exp: Add a second breakpoint.
	Tighten expected GDB output.
2016-02-09 12:12:17 +00:00
Simon Marchi
5488790363 remote.c: Cleanup unused variables
I built remote.c with -Wunused, to check a function I was working on,
turns out there is a bunch of unused variables.

gdb/ChangeLog:

	* remote.c (remote_register_number_and_offset): Remove unused
	variable(s).
	(remote_thread_always_alive): Likewise.
	(remote_update_thread_list): Likewise.
	(process_initial_stop_replies): Likewise.
	(remote_start_remote): Likewise.
	(remote_check_symbols): Likewise.
	(discard_pending_stop_replies): Likewise.
	(process_stop_reply): Likewise.
	(putpkt_binary): Likewise.
	(getpkt): Likewise.
	(remote_add_target_side_condition): Likewise.
	(remote_insert_breakpoint): Likewise.
	(remote_supports_stopped_by_sw_breakpoint): Likewise.
	(remote_supports_stopped_by_hw_breakpoint): Likewise.
	(remote_xfer_partial): Likewise.
	(remote_read_btrace): Likewise.
	(remote_async_serial_handler): Likewise.
	(remote_thread_events): Likewise.
	(_initialize_remote): Likewise.
2016-02-08 12:57:08 -05:00
Simon Marchi
30914ca8c0 varobj: Cleanup dead code
This patch removes some dead code.

I noticed that varobj_delete was always called with dellist == NULL, so
I started removing that parameter.  That allows removing a good chunk of
the code in varobj_delete, making it almost trivial.  We can also remove
the resultp parameters in that whole trail.  In turn, this shows that
struct cpstack, cppush and cppop were only used fo that mechanism, so
they can be removed as well.

I also moved the function comment to the header file to comply with
today's guideline, even though the rest of the file does not respect it
(yet).

gdb/ChangeLog:

	* varobj.h (varobj_delete): Remove dellist parameter, update and
	move documentation here.
	* varobj.c (struct cpstack, cppush, cppop): Remove.
	(delete_variable): Remove resultp (first) parameter.
	(delete_variable_1): Likewise.
	(varobj_delete): Remove dellist parameter and unused code.
	(update_dynamic_varobj_children): Adjust varobj_delete call.
	(update_type_if_necessary): Likewise.
	(varobj_set_visualizer): Likewise.
	(varobj_update): Likewise.
	(value_of_root): Likewise.
	(varobj_invalidate_iter): Likewise.
	* mi/mi-cmd-var.c (mi_cmd_var_delete): Likewise.
2016-02-07 09:45:02 -05:00
Yao Qi
e42e5352d1 waiting_for_stop_reply around remote_fileio_request
Hi,
I see this error when GDB connects with qemu,

(gdb) n
....
Sending packet: $vCont;c#a8...Ack
Packet received: Ffstat,00000001,f6fff038
Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.

looks we don't set rs->waiting_for_stop_reply to zero
before handle fileio request,

 #10 0x00000000005edb64 in target_write (len=64, offset=4143968312, buf=0x7fffffffd570 "\375\377\377\377", annex=0x0, object=TARGET_OBJECT_MEMORY,
    ops=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1922
 #11 target_write_memory (memaddr=memaddr@entry=4143968312, myaddr=myaddr@entry=0x7fffffffd6a0 "", len=len@entry=64)
    at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1500
 #12 0x00000000004b2b41 in remote_fileio_func_fstat (buf=0x127b258 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1037
 #13 0x00000000004b1878 in do_remote_fileio_request (uiout=<optimised out>, buf_arg=buf_arg@entry=0x127b240)
    at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1204
 #14 0x00000000005b8c7c in catch_exceptions_with_msg (func_uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>,
    func_args=func_args@entry=0x127b240, gdberrmsg=gdberrmsg@entry=0x0, mask=mask@entry=RETURN_MASK_ALL)
    at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:187
 #15 0x00000000005b8dea in catch_exceptions (uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240,
    mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:167
 #16 0x00000000004b2fff in remote_fileio_request (buf=0x127b240 "Xf6fff038,0:", ctrlc_pending_p=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1255
 #17 0x0000000000496f12 in remote_wait_as (ptid=..., status=0x7fffffffdb20, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:6997

however, we did set rs->waiting_for_stop_reply to zero before Luis's
patch https://sourceware.org/ml/gdb-patches/2015-10/msg00336.html

In fact, Luis's patch v1
https://sourceware.org/ml/gdb-patches/2015-08/msg00809.html is about
setting rs->waiting_for_stop_reply back to one after
remote_fileio_request, which is correct.  However during the review, the
patch is changed and ends up with "not setting rs->waiting_for_stop_reply
to zero".

I manually test GDB, but I don't have a way to run regression tests.

gdb:

2016-02-04  Yao Qi  <yao.qi@linaro.org>

	* remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to
	0 before handling 'F' and set it back afterwards.
2016-02-04 15:09:09 +00:00
Simon Marchi
6456a18b71 ui-out.c: Remove unused enum
This is unused since 54eb231c4b, where
static arrays of ui_out_levels were replaced with vectors.

gdb/ChangeLog:

	* ui-out.c (MAX_UI_OUT_LEVELS): Remove.
2016-02-02 16:40:38 -05:00
Walfred Tedeschi
3f2f6cb5e8 Adaptation of siginfo fixup for the new bnd fields
New bnds fields will be always present for x86 architecture.
Fixup for compatibility layer 32bits has to be fixed.

It was added the nat_siginfo to serving as intermediate step
between kernel provided siginfo and the fix up routine.

When executing compat_siginfo_from_siginfo or
compat_x32_siginfo_from_siginfo first the buffer read from the kernel are
converted into the nat_signfo for homogenization, then the fields of
nat_siginfo are use to set the compat and compat_x32 siginfo fields.

In other to make this conversion independent of the system where gdb
is compiled the most complete version of the siginfo, named as native
siginfo, is used internally as an intermediate step.

Conversion using nat_siginfo is exemplified below:

compat_siginfo_from_siginfo or compat_x32_siginfo_from_siginfo:

buffer (from the kernel) -> nat_siginfo -> 32 / X32 siginfo
                      (memcpy)       (field by field)

siginfo_from_compat_x32_siginfo or siginfo_from_compat_siginfo:

32 / X32 siginfo -> nat_siginfo -> buffer (to the kernel)
          (field by field)    (memcpy)

Caveat: No support for MPX on x32.

2016-02-02  Walfred Tedeschi  <walfred.tedeschi@intel.com>

gdb/ChangeLog:

	* amd64-linux-siginfo.c (nat_siginfo_t, nat_sigval_t, nat_timeval):
	New types.
	(compat_siginfo): New bound fields added.
	(compat_x32_siginfo): New field added.
	(cpt_si_addr_lsb): New define.
	(compat_siginfo_from_siginfo): Use nat_siginfo.
	(siginfo_from_compat_siginfo): Use nat_siginfo.
	(compat_x32_siginfo_from_siginfo): Likewise.
	(siginfo_from_compat_x32_siginfo): Likewise.
2016-02-02 12:02:16 +01:00
Walfred Tedeschi
96b5c49fb1 Add bound related fields to the siginfo structure
Both Linux and glibc have introduced bound related fields in the
segmentation fault fields of the siginfo_t type. Add the new fields
to our x86's siginfo_t type too.

Kernel patch:
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=ee1b58d36aa1b5a79eaba11f5c3633c88231da83

Glibc patch:
d4358b51c2

2016-02-02  Walfred Tedeschi  <walfred.tedeschi@intel.com>

gdb/ChangeLog:

	* linux-tdep.c (linux_get_siginfo_type): Add the _addr_bnd
	structure to the siginfo if extra_fields contains
	LINUX_SIGINFO_FIELD_ADDR_BND.
2016-02-02 11:58:36 +01:00
Walfred Tedeschi
190b495d47 Use linux_get_siginfo_type_with_fields for x86
Use linux_get_siginfo_type_with_fields for adding bound fields on
segmentation fault for i386/amd64 siginfo.

2016-02-02  Walfred Tedeschi  <walfred.tedeschi@intel.com>

gdb/ChangeLog:

	* linux-tdep.h (linux_get_siginfo_type_with_fields): Make extern.
	* linux-tdep.c (linux_get_siginfo_type_with_fields): Make extern.
	* i386-linux-tdep.h (x86_linux_get_siginfo_type): New
	function.
	* amd64-linux-tdep.c (amd64_linux_init_abi_common): Add
	x86_linux_get_siginfo_type for the amd64 abi.
	* i386-linux-tdep.c (x86_linux_get_siginfo_type): New
	function.
	(i386_linux_init_abi): Add new function at the i386 ABI
	initialization.
2016-02-02 11:50:17 +01:00
Walfred Tedeschi
43564574f1 Preparation for new siginfo on Linux
First add new structure and function to allow architecture customization
for the siginfo structure.

2016-01-15  Walfred Tedeschi  <walfred.tedeschi@intel.com>

gdb/ChangeLog:

	* linux-tdep.h (linux_siginfo_extra_field_values): New enum values.
	(linux_siginfo_extra_fields): New enum type.
	* linux-tdep.c (linux_get_siginfo_type_with_fields): New function.
	(linux_get_siginfo_type): Use new function.
2016-02-02 11:46:28 +01:00
Walfred Tedeschi
93813b37c8 Merge gdb and gdbserver implementations for siginfo
Extract the compatible siginfo handling from amd64-linux-nat.c and
gdbserver/linux-x86-low to a new file nat/amd64-linux-siginfo.c.

2016-02-02  Walfred Tedeschi  <walfred.tedeschi@intel.com>

gdb/ChangeLog:

	* nat/amd64-linux-siginfo.c: New file.
	* nat/amd64-linux-siginfo.h: New file.
	* Makefile.in (HFILES_NO_SRCDIR): Add nat/amd64-linux-siginfo.h.
	(amd64-linux-siginfo.o): New rule.
	* config/i386/linux64.mh (NATDEPFILES): Add amd64-linux-siginfo.o.
	* amd64-linux-nat.c (nat/amd64-linux-siginfo.h): New include.
	(compat_siginfo_from_siginfo, siginfo_from_compat_siginfo)
	(compat_x32_siginfo_from_siginfo, siginfo_from_compat_x32_siginfo)
	(compat_timeval, compat_sigval, compat_x32_clock, cpt_si_pid)
	(cpt_si_uid, cpt_si_timerid, cpt_si_overrun, cpt_si_status)
	(cpt_si_utime, cpt_si_stime, cpt_si_ptr, cpt_si_addr, cpt_si_band)
	(cpt_si_fd, si_timerid, si_overrun): Move to nat/amd64-linux-siginfo.c.

gdb/gdbserver/ChangeLog:

	* configure.srv (x86_64-*-linux*): Add amd64-linux-siginfo.o
	to srv_tgtobj.
	(i[34567]86-*-linux*): Add amd64-linux-siginfo.o
	to srv_tgtobj.
	* linux-x86-low.c [__x86_64__]: Include
	"nat/amd64-linux-siginfo.h".
	(compat_siginfo_from_siginfo, siginfo_from_compat_siginfo)
	(compat_x32_siginfo_from_siginfo, siginfo_from_compat_x32_siginfo)
	(compat_timeval, compat_sigval, compat_x32_clock, cpt_si_pid)
	(cpt_si_uid, cpt_si_timerid, cpt_si_overrun, cpt_si_status)
	(cpt_si_utime, cpt_si_stime, cpt_si_ptr, cpt_si_addr, cpt_si_band)
	(cpt_si_fd, si_timerid, si_overrun): Move from
	nat/amd64-linux-siginfo.c.
	* Makefile.in (amd64-linux-siginfo.o:): New rule.
2016-02-02 11:42:56 +01:00
Andrew Burgess
5fdf6324fa gdb: New set/show max-value-size command.
For languages with dynamic types, an incorrect program, or uninitialised
variables within a program, could result in an incorrect, overly large
type being associated with a value.  Currently, attempting to print such
a variable will result in gdb trying to allocate an overly large buffer.

If this large memory allocation fails then the result can be gdb either
terminating, or (due to memory contention) becoming unresponsive for the
user.

A new user visible variable in gdb helps guard against such problems,
two new commands are available:

   set max-value-size
   show max-value-size

The 'max-value-size' is the maximum size of memory in bytes that gdb
will allocate for the contents of a value.  Any attempt to allocate a
value with a size greater than this will result in an error.  The
initial default for this limit is set at 64k, this is based on a similar
limit that exists within the ada specific code.

It is possible for the user to set max-value-size to unlimited, in which
case the old behaviour is restored.

gdb/ChangeLog:

	* value.c (max_value_size): New variable.
	(MIN_VALUE_FOR_MAX_VALUE_SIZE): New define.
	(show_max_value_size): New function.
	(check_type_length_before_alloc): New function.
	(allocate_value_contents): Call check_type_length_before_alloc.
	(set_value_enclosing_type): Likewise.
	(_initialize_values): Add set/show handler for max-value-size.
	* NEWS: Mention new set/show command.

gdb/doc/ChangeLog:

	* gdb.texinfo (Value Sizes): New section.
	(Data): Add the 'Value Sizes' node to the menu.

gdb/testsuite/ChangeLog:

	* gdb.base/max-value-size.c: New file.
	* gdb.base/max-value-size.exp: New file.
	* gdb.base/huge.exp: Disable max-value-size for this test.
2016-02-01 18:05:35 +00:00
Simon Marchi
5fa1307022 Fix some comments in varobj.{c,h}
A few typos.  The comment about varobj_create has been misplaced since
the dawn of time.

gdb/ChangeLog:

	* varobj.h (struct varobj): Fix typos in comments.
	(struct lang_varobj_ops): Likewise.
	* varobj.c (VAROBJ_TABLE_SIZE): Likewise.
	(varobj_create): Move misplaced comment.
2016-01-31 22:24:17 -05:00
Simon Marchi
a2e3e93f44 Fix two misleading indentation warnings
Two small changes so everything builds with latest GCC and its
-Wmisleading-indentation.

In the aarch64-tdep.c case, the two misindented lines should actually be
part of the for loop.  It looks like the indentation is all done using
spaces in that file though...  I fixed it (changed for tabs + spaces) for
the lines I touched.

In the xcoffread.c case, we can simply remove the braces and fix the
indentation.

gdb/ChangeLog:

	* aarch64-tdep.c (aarch64_record_asimd_load_store): Add braces
	to for include additional lines.
	* xcoffread.c (scan_xcoff_symtab): Remove unnecessary braces.
2016-01-29 15:32:29 -05:00
Simon Marchi
56e374a6bc Add rawmemchr to imported gnulib modules
rawmemchr is a dependency of strchrnul, so it should be explicitly
listed.

gdb/ChangeLog:

	* gnulib/import/Makefile.am: Regenerate.
	* gnulib/import/Makefile.in: Regenerate.
	* gnulib/import/m4/gnulib-cache.m4: Regenerate.
	* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add rawmemchr.
2016-01-28 13:49:46 -05:00
Simon Marchi
8424cc978c Import strchrnul from gnulib and use it
For a forthcoming patch, I need a "skip_to_colon" function.  I noticed
there are two skip_to_semicolon (one in gdb and one in gdbserver). I
thought we could put it in common/, and generalize it for any character.
It turns out that the strchrnul function does exactly that.  I imported
the corresponding module from gnulib, for those systems that do not have
it.

There are probably more places where this function can be used instead
of doing the work by hand (I am looking at
remote-utils.c::look_up_one_symbol).

gdb/ChangeLog:

	* remote.c (skip_to_semicolon): Remove.
	(remote_parse_stop_reply): Use strchrnul instead of
	skip_to_semicolon.
	* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add
	strchrnul.
	* gnulib/aclocal.m4: Regenerate.
	* gnulib/config.in: Regenerate.
	* gnulib/configure: Regenerate.
	* gnulib/import/Makefile.am: Regenerate.
	* gnulib/import/Makefile.in: Regenerate.
	* gnulib/import/m4/gnulib-cache.m4: Regenerate.
	* gnulib/import/m4/gnulib-comp.m4: Regenerate.
	* gnulib/import/m4/rawmemchr.m4: New file.
	* gnulib/import/m4/strchrnul.m4: New file.
	* gnulib/import/rawmemchr.c: New file.
	* gnulib/import/rawmemchr.valgrind: New file.
	* gnulib/import/strchrnul.c: New file.
	* gnulib/import/strchrnul.valgrind: New file.

gdb/gdbserver/ChangeLog:

	* server.c (skip_to_semicolon):  Remove.
	(process_point_options): Use strchrnul instead of
	skip_to_semicolon.
2016-01-28 10:28:56 -05:00
Yao Qi
4a6a1ed4a1 Fix GDB crash in dprintf.exp
I see GDB crashes in dprintf.exp on aarch64-linux testing,

(gdb) PASS: gdb.base/dprintf.exp: agent: break 29
set dprintf-style agent^M
(gdb) PASS: gdb.base/dprintf.exp: agent: set dprintf style to agent
continue^M
Continuing.
ASAN:SIGSEGV
=================================================================
==22475==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000000494820 sp 0x7fff389b83a0 bp 0x62d000082417 T0)
    #0 0x49481f in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9190^M
    #1 0x49e576 in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9174^M
    #2 0x49e576 in remote_insert_breakpoint /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9240^M
    #3 0x5278b7 in insert_bp_location /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:2734^M
    #4 0x52ac09 in insert_breakpoint_locations /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:3159^M
    #5 0x52ac09 in update_global_location_list /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:12686

the root cause of this problem in this case is about linespec and
symtab which produces additional incorrect location and a NULL is added to
bp_tgt->tcommands.  I posted a patch
https://sourceware.org/ml/gdb-patches/2015-12/msg00321.html to fix it
in linespec (the fix causes regression), but GDB still shouldn't add
NULL into bp_tgt->tcommands.  The logic of build_target_command_list
looks odd to me.  If we get something wrong in parse_cmd_to_aexpr (it
returns NULL), we shouldn't continue, instead we should set flag
null_command_or_parse_error.  This is what this patch does.  In the
meantime, we find build_target_condition_list has the same problem, so
fix it too.

gdb:

2016-01-28  Yao Qi  <yao.qi@linaro.org>

	* breakpoint.c (build_target_command_list): Don't call continue
	if aexpr is NULL.
	(build_target_condition_list): Likewise.
2016-01-28 14:16:42 +00:00
Kevin Buettner
94715c1790 rx: Treat scalars larger than 8 bytes as aggregates in rx_push_dummy_call.
This patch fixes the following failures (which are also GDB internal errors)
for the -m64bit-doubles multilib:

FAIL: gdb.base/callfuncs.exp: p t_double_complex_values(dc1, dc2) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_double_complex_values(dc3, dc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_double_complex_many_args(dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_double_complex_many_args(dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_values(ldc1, ldc2) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_values(ldc3, ldc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_many_args(ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_many_args(ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1,ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_values(dc1, dc2) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_values(dc3, dc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_many_args(dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_many_args(dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_values(ldc1, ldc2) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_values(ldc3, ldc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_many_args(ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4) (GDB internal error)
FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_many_args(ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1,ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1) (GDB internal error)
FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4) (GDB internal error)
FAIL: gdb.base/varargs.exp: print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4) (GDB internal error)

The assertion failure which is tripped is:

		  gdb_assert (arg_size <= 4);

While it may seem that the patch ought to disallow scalars larger than
4, scalars of size 8 are explicitly handled by the code elsewhere.

This came up because gcc has a complex type that is 16 bytes in length
when 64-bit doubles are used.

gdb/ChangeLog:

	* rx-tdep.c (rx_push_dummy_call): Treat scalars larger than 8
	bytes as aggregates.
2016-01-27 12:34:29 -07:00
Joel Brobecker
c07af0ab29 Add Keith Seitz as Linespec Maintainer
gdb/ChangeLog:

        * MAINTAINERS (Responsible Maintainers): Add Keith Seitz as
        Linespec Maintainers.
2016-01-27 13:54:37 +04:00
Simon Marchi
41548caa9b Fix function comments
Two obvious fixes.

gdb/ChangeLog:

	* common/common-utils.c (skip_spaces): Fix comment.
	(skip_to_space_const): Likewise.
2016-01-26 16:30:03 -05:00