Commit Graph

86490 Commits

Author SHA1 Message Date
Pedro Alves
89df5d6cce Make gdb.base/jit.exp binaries unique
This testcase compiles the same program and library differently
multiple times using the same file names.  Make them unique, to make
it easier to debug test problems.

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

	PR gdb/19858
	* gdb.base/jit.exp (compile_jit_test): Add intro comment.  Add
	BINSUFFIX parameter, and handle it.
	(top level): Adjust calls compile_jit_test.
2016-03-31 19:36:08 +01:00
Yichao Yu
cd64cabb8c Fix PR gdb/19858: GDB doesn't register the JIT libraries on attach
Ref: https://sourceware.org/ml/gdb/2016-03/msg00023.html

GDB currently fails to fetch the list of already-registered JIT
modules on attach.

Nothing is calling jit_inferior_init, which is what is responsible for
walking the JIT object list at init time.

Despite the misleading naming, jit_inferior_created_hook ->
jit_inferior_init is only called when the inferior execs.

This regressed with the fix for PR gdb/13431 (03bef283c2):
 https://sourceware.org/ml/gdb-patches/2012-02/msg00023.html which
removed the inferior_created (jit_inferior_created_observer)
observer.

Adding an inferior_created observer back fixes the issue.

In turn, this exposes a bug in jit_breakpoint_re_set_internal as well,
which is returning the wrong result when we already have the
breakpoint at the right address.

gdb/ChangeLog:
2016-03-31  Yichao Yu  <yyc1992@gmail.com>

	PR gdb/19858
	* jit.c (jit_breakpoint_re_set_internal): Return 0 if we already
	got the breakpoint at the right address.
	(jit_inferior_created): New function.
	(_initialize_jit): Install jit_inferior_created as
	inferior_created observer.

Signed-off-by: Pedro Alves <palves@redhat.com>
2016-03-31 19:36:03 +01:00
GDB Administrator
f8210fb710 Automatic date update in version.in 2016-03-31 00:00:38 +00:00
GDB Administrator
dee3dbc902 Automatic date update in version.in 2016-03-30 00:00:38 +00:00
GDB Administrator
0b0edae68a Automatic date update in version.in 2016-03-29 00:00:43 +00:00
GDB Administrator
e571466b82 Automatic date update in version.in 2016-03-28 00:00:41 +00:00
GDB Administrator
a0d75692a1 Automatic date update in version.in 2016-03-27 00:00:41 +00:00
GDB Administrator
378b7e3879 Automatic date update in version.in 2016-03-26 00:00:46 +00:00
GDB Administrator
b33441714a Automatic date update in version.in 2016-03-25 00:00:41 +00:00
GDB Administrator
a87a0f8b2c Automatic date update in version.in 2016-03-24 00:00:49 +00:00
GDB Administrator
253b3b9547 Automatic date update in version.in 2016-03-23 00:00:44 +00:00
GDB Administrator
174d467379 Automatic date update in version.in 2016-03-22 00:00:35 +00:00
GDB Administrator
a608d6856a Automatic date update in version.in 2016-03-21 00:00:37 +00:00
GDB Administrator
288b250718 Automatic date update in version.in 2016-03-20 00:00:38 +00:00
GDB Administrator
ae850cee98 Automatic date update in version.in 2016-03-19 00:00:35 +00:00
GDB Administrator
f3e8a3a780 Automatic date update in version.in 2016-03-18 00:00:41 +00:00
Markus Metzger
2ef34d11f6 btrace: fix PR gdb/19829
This is a backport of

33b4777ca1 btrace, frame: fix crash in get_frame_type
a038fa3e14 stack: check frame_unwind_caller_id
2f3ef606b9 frame: add skip_tailcall_frames

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): New.
	* infcmd.c (finish_command): Call skip_tailcall_frames.
	* frame.c (skip_artificial_frames): Return NULL if only artificial frames
	are found.  Update comment.
	(frame_pop): Call skip_tailcall_frames.
	(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.
	* stack.c (frame_info): Check frame_unwind_caller_id.

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-03-17 11:48:49 +01:00
GDB Administrator
6c410d3b60 Automatic date update in version.in 2016-03-17 00:00:45 +00:00
GDB Administrator
b102e5372a Automatic date update in version.in 2016-03-16 00:00:42 +00:00
Pedro Alves
9312893c8d Fix PR gdb/19676: Internal error in linux-thread.db.c if /proc not mounted
If /proc is not mounted, GDB fails an assertion in find_new_threads_once:

 Continuing.
 .../src/gdb/linux-thread-db.c:1249: internal-error: find_new_threads_once: Assertion `!target_has_execution' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

That was supposed to catch misuses of td_ta_thr_iter, which is unsafe
for live debugging.  However, if /proc is not mounted, we still
fallback to using it.

I didn't bother with a warning, because GDB already prints several
others related to failing to open /proc files.

gdb/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>

	PR gdb/19676
	* linux-thread-db.c (try_thread_db_load_1): Leave
	info->td_ta_thr_iter_p NULL iff debugging a live process and we
	have /proc access.
	(find_new_threads_once): Assert that we have a non-NULL
	info->td_ta_thr_iter_p instead of checking whether the target has
	execution.
2016-03-15 16:36:53 +00:00
Pedro Alves
4e57eb7028 Fix PR gdb/19676: Disable displaced stepping if /proc not mounted
On GNU/Linux archs that support displaced stepping, if /proc is not
mounted, GDB gets stuck not able to step past breakpoints:

 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb)

That's because GDB can't figure out where the scratch pad is.

This is a regression introduced by the earlier changes to make the
Linux native target always work in non-stop mode.

This commit makes GDB detect the case and fallback to stepping over
breakpoints in-line.

gdb/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>

	PR gdb/19676
	* infrun.c (displaced_step_prepare): Also disable displaced
	stepping on NOT_SUPPORTED_ERROR.
	* linux-tdep.c (linux_displaced_step_location): If reading auxv
	fails, throw NOT_SUPPORTED_ERROR instead of generic error.
2016-03-15 16:36:46 +00:00
GDB Administrator
283c00efb7 Automatic date update in version.in 2016-03-15 00:00:43 +00:00
GDB Administrator
e061ed5b54 Automatic date update in version.in 2016-03-14 00:00:35 +00:00
GDB Administrator
bb11dc174e Automatic date update in version.in 2016-03-13 00:00:44 +00:00
GDB Administrator
516ff4a7dd Automatic date update in version.in 2016-03-12 00:00:37 +00:00
GDB Administrator
b3e987c24c Automatic date update in version.in 2016-03-11 00:00:39 +00:00
GDB Administrator
5883da401e Automatic date update in version.in 2016-03-10 00:00:39 +00:00
GDB Administrator
251a7aee76 Automatic date update in version.in 2016-03-09 00:00:34 +00:00
GDB Administrator
6d1f374b86 Automatic date update in version.in 2016-03-08 00:00:47 +00:00
GDB Administrator
5ec6069376 Automatic date update in version.in 2016-03-07 00:00:41 +00:00
GDB Administrator
051cabb732 Automatic date update in version.in 2016-03-06 00:00:39 +00:00
GDB Administrator
cd58937ca7 Automatic date update in version.in 2016-03-05 00:00:31 +00:00
GDB Administrator
cc22a0293f Automatic date update in version.in 2016-03-04 00:00:31 +00:00
GDB Administrator
6bdb373afe Automatic date update in version.in 2016-03-03 00:00:36 +00:00
GDB Administrator
fc5494cebb Automatic date update in version.in 2016-03-02 00:00:37 +00:00
GDB Administrator
17b5be823d Automatic date update in version.in 2016-03-01 00:00:57 +00:00
GDB Administrator
9afc053a96 Automatic date update in version.in 2016-02-29 00:00:57 +00:00
GDB Administrator
ff474daa69 Automatic date update in version.in 2016-02-28 00:00:59 +00:00
GDB Administrator
42d294de79 Automatic date update in version.in 2016-02-27 00:01:02 +00:00
GDB Administrator
08533595dc Automatic date update in version.in 2016-02-26 00:01:09 +00:00
GDB Administrator
4f80d1d126 Automatic date update in version.in 2016-02-25 00:01:02 +00:00
Joel Brobecker
63a034c19f Bump GDB version number to 7.11.0.DATE-git.
gdb/ChangeLog:

	* version.in: Set GDB version number to 7.11.0.DATE-git.
2016-02-24 11:19:36 +01:00
Joel Brobecker
cad15c35d5 Document the GDB 7.11 release in gdb/ChangeLog
gdb/ChangeLog:

	GDB 7.11 released.
2016-02-24 11:07:18 +01:00
Joel Brobecker
ac6c80b223 Set GDB version number to 7.11.
gdb/ChangeLog:

	* version.in: Set GDB version number to 7.11.
gdb-7.11-release
2016-02-24 10:55:16 +01:00
GDB Administrator
7996349ead Automatic date update in version.in 2016-02-24 00:01:02 +00:00
GDB Administrator
dee54a904b Automatic date update in version.in 2016-02-23 00:01:02 +00:00
Jan Kratochvil
3d58f89972 gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print'
After building GDB
	--with-python=/usr/bin/python3
and for example stripping ./gdb and running:
	./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb.
py" ./gdb
I get:
	Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
	  File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91
	    print "Warning: Cannot find enum type_flag_value type."
								  ^
	SyntaxError: Missing parentheses in call to 'print'
	(top-gdb) q

gdb/ChangeLog
2016-02-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.
2016-02-22 17:18:35 +01:00
GDB Administrator
976b7aed19 Automatic date update in version.in 2016-02-22 00:00:35 +00:00
GDB Administrator
cf0091e0aa Automatic date update in version.in 2016-02-21 00:00:35 +00:00
GDB Administrator
a5d53b5c70 Automatic date update in version.in 2016-02-20 00:00:31 +00:00