Commit graph

6 commits

Author SHA1 Message Date
Pedro Alves
b05b120205 Reapply: List inferiors/threads/pspaces in ascending order
[This reapplies a change that was accidentally reverted with c0ecb95f3d.]

Before:
  (gdb) info threads
    Id   Target Id         Frame
    3    Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
    2    Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
  * 1    Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92

After:
  (gdb) info threads
    Id   Target Id         Frame
  * 1    Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
    2    Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
    3    Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30

gdb/doc/ChangeLog:
2015-11-24  Pedro Alves  <palves@redhat.com>

	PR 17539
	* gdb.texinfo (Inferiors and Programs): Adjust "maint info
	program-spaces" example to ascending order listing.
	(Threads): Adjust "info threads" example to ascending order
	listing.
	(Forks): Adjust "info inferiors" example to ascending order
	listing.

gdb/ChangeLog:
2015-11-24  Pedro Alves  <palves@redhat.com>

	PR 17539
	* inferior.c (add_inferior_silent): Append the new inferior to the
	end of the list.
	* progspace.c (add_program_space): Append the new pspace to the
	end of the list.
	* thread.c (new_thread): Append the new thread to the end of the
	list.

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

	PR 17539
	* gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and
	threads in ascending order.
	* gdb.base/foll-fork.exp: Likewise.
	* gdb.base/foll-vfork.exp: Likewise.
	* gdb.base/multi-forks.exp: Likewise.
	* gdb.mi/mi-nonstop.exp: Likewise.
	* gdb.mi/mi-nsintrall.exp: Likewise.
	* gdb.multi/base.exp: Likewise.
	* gdb.multi/multi-arch.exp: Likewise.
	* gdb.python/py-inferior.exp: Likewise.
	* gdb.threads/break-while-running.exp: Likewise.
	* gdb.threads/execl.exp: Likewise.
	* gdb.threads/gcore-thread.exp: Likewise.
	* gdb.threads/info-threads-cur-sal.exp: Likewise.
	* gdb.threads/kill.exp: Likewise.
	* gdb.threads/linux-dp.exp: Likewise.
	* gdb.threads/multiple-step-overs.exp: Likewise.
	* gdb.threads/next-bp-other-thread.exp: Likewise.
	* gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise.
	* gdb.threads/step-over-lands-on-breakpoint.exp: Likewise.
	* gdb.threads/step-over-trips-on-watchpoint.exp: Likewise.
	* gdb.threads/thread-find.exp: Likewise.
	* gdb.threads/tls.exp: Likewise.
	* lib/mi-support.exp (mi_reverse_list): Delete.
	(mi_check_thread_states): No longer reverse list.
2016-01-12 01:12:38 +00:00
Jan Kratochvil
c0ecb95f3d testsuite: Fix false FAILs on too long base directory
I was getting

gu (print arg0)^M
= 0x7fffffffdafb
"/unsafebuild-x86_64-redhat-linux-gnu/gdb/testsuite.unix.-m64/outputs/gdb.guile/scm-value/scm-"...^M
(gdb) FAIL: gdb.guile/scm-value.exp: verify dereferenced value
python print (arg0)^M
0x7fffffffdafd
"/unsafebuild-x86_64-redhat-linux-gnu/gdb/testsuite.unix.-m64/outputs/gdb.python/py-value/py-v"...^M
(gdb) FAIL: gdb.python/py-value.exp: verify dereferenced value

and also:

(gdb) p argv[0]^M
$2 = 0x7fffffffd832 "/home/jkratoch/redhat/gdb-test-", 'x' <repeats 169
times>...^M
(gdb) FAIL: gdb.guile/scm-value.exp: argv[0] should be available on this
target

gdb/testsuite/ChangeLog
2016-01-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.guile/scm-value.exp (test_value_in_inferior): Set print elements
	and repeats to unlimited.
	* gdb.python/py-value.exp: Likewise.
	* lib/gdb.exp (gdb_has_argv0): Save and temporarily set print elements
	and repeats to unlimited.
2016-01-11 22:12:16 +01:00
Joel Brobecker
618f726fcb GDB copyright headers update after running GDB's copyright.py script.
gdb/ChangeLog:

        Update year range in copyright notice of all files.
2016-01-01 08:43:22 +04:00
Pedro Alves
7e0aa6aa99 List inferiors/threads/pspaces in ascending order
Before:
  (gdb) info threads
    Id   Target Id         Frame
    3    Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
    2    Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
  * 1    Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92

After:
  (gdb) info threads
    Id   Target Id         Frame
  * 1    Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
    2    Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
    3    Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30

gdb/doc/ChangeLog:
2015-11-24  Pedro Alves  <palves@redhat.com>

	PR 17539
	* gdb.texinfo (Inferiors and Programs): Adjust "maint info
	program-spaces" example to ascending order listing.
	(Threads): Adjust "info threads" example to ascending order
	listing.
	(Forks): Adjust "info inferiors" example to ascending order
	listing.

gdb/ChangeLog:
2015-11-24  Pedro Alves  <palves@redhat.com>

	PR 17539
	* inferior.c (add_inferior_silent): Append the new inferior to the
	end of the list.
	* progspace.c (add_program_space): Append the new pspace to the
	end of the list.
	* thread.c (new_thread): Append the new thread to the end of the
	list.

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

	PR 17539
	* gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and
	threads in ascending order.
	* gdb.base/foll-fork.exp: Likewise.
	* gdb.base/foll-vfork.exp: Likewise.
	* gdb.base/multi-forks.exp: Likewise.
	* gdb.mi/mi-nonstop.exp: Likewise.
	* gdb.mi/mi-nsintrall.exp: Likewise.
	* gdb.multi/base.exp: Likewise.
	* gdb.multi/multi-arch.exp: Likewise.
	* gdb.python/py-inferior.exp: Likewise.
	* gdb.threads/break-while-running.exp: Likewise.
	* gdb.threads/execl.exp: Likewise.
	* gdb.threads/gcore-thread.exp: Likewise.
	* gdb.threads/info-threads-cur-sal.exp: Likewise.
	* gdb.threads/kill.exp: Likewise.
	* gdb.threads/linux-dp.exp: Likewise.
	* gdb.threads/multiple-step-overs.exp: Likewise.
	* gdb.threads/next-bp-other-thread.exp: Likewise.
	* gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise.
	* gdb.threads/step-over-lands-on-breakpoint.exp: Likewise.
	* gdb.threads/step-over-trips-on-watchpoint.exp: Likewise.
	* gdb.threads/thread-find.exp: Likewise.
	* gdb.threads/tls.exp: Likewise.
	* lib/mi-support.exp (mi_reverse_list): Delete.
	(mi_check_thread_states): No longer reverse list.
2015-11-24 18:36:31 +00:00
Joel Brobecker
32d0add0a6 Update year range in copyright notice of all files owned by the GDB project.
gdb/ChangeLog:

        Update year range in copyright notice of all files.
2015-01-01 13:32:14 +04:00
Pedro Alves
354204061c PR 17408 - assertion failure in switch_back_to_stepped_thread
This PR shows that GDB can easily trigger an assertion here, in
infrun.c:

 5392              /* Did we find the stepping thread?  */
 5393              if (tp->control.step_range_end)
 5394                {
 5395                  /* Yep.  There should only one though.  */
 5396                  gdb_assert (stepping_thread == NULL);
 5397
 5398                  /* The event thread is handled at the top, before we
 5399                     enter this loop.  */
 5400                  gdb_assert (tp != ecs->event_thread);
 5401
 5402                  /* If some thread other than the event thread is
 5403                     stepping, then scheduler locking can't be in effect,
 5404                     otherwise we wouldn't have resumed the current event
 5405                     thread in the first place.  */
 5406                  gdb_assert (!schedlock_applies (currently_stepping (tp)));
 5407
 5408                  stepping_thread = tp;
 5409                }

Like:

 gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.

The way the assertion is written is assuming that with schedlock=step
we'll always leave threads other than the one with the stepping range
locked, while that's not true with the "next" command.  With schedlock
"step", other threads still run unlocked when "next" detects a
function call and steps over it.  Whether that makes sense or not,
still, it's documented that way in the manual.  If another thread hits
an event that doesn't cause a stop while the nexting thread steps over
a function call, we'll get here and fail the assertion.

The fix is just to adjust the assertion.  Even though we found the
stepping thread, we'll still step-over the breakpoint that just
triggered correctly.

Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
steps over a function call.  This commits fixes that.  This ensures
that "next" doesn't switch focus to another thread, and checks whether
other threads run locked or not, depending on scheduler locking mode
and command.  There's a lot of duplication in that file that this ends
cleaning up.  There's more that could be cleaned up, but that would
end up an unrelated change, best done separately.

This new coverage in schedlock.exp happens to trigger the internal
error in question, like so:

 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)

That's because we have more than one thread running the same loop, and
while one thread is stepping over a function call, the other thread
hits the step-resume breakpoint of the first, which needs to be
stepped over, and we end up in switch_back_to_stepped_thread exactly
in the problem case.

I think a simpler and more directed test is also useful, to not rely
on internal breakpoint magics.  So this commit also adds a test that
has a thread trip on a conditional breakpoint that doesn't cause a
user-visible stop while another thread is stepping over a call.  That
currently fails like this:

 FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)

Tested on x86_64 Fedora 20.

gdb/
2014-10-29  Pedro Alves  <palves@redhat.com>

	PR gdb/17408
	* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
	instead of assuming a thread with a stepping range is always
	stepping.

gdb/testsuite/
2014-10-29  Pedro Alves  <palves@redhat.com>

	PR gdb/17408
	* gdb.threads/schedlock.c (some_function): New function.
	(call_function): New global.
	(MAYBE_CALL_SOME_FUNCTION): New macro.
	(thread_function): Call it.
	* gdb.threads/schedlock.exp (get_args): Add description parameter,
	and use it instead of a global counter.  Adjust all callers.
	(get_current_thread): Use "find current thread" for test message
	here rather than having all callers pass down the same string.
	(goto_loop): New procedure, factored out from ...
	(my_continue): ... this.
	(step_ten_loops): Change parameter from test message to command to
	use.  Adjust.
	(list_count): Delete global.
	(check_result): New procedure, factored out from duplicate top
	level code.
	(continue tests): Wrap in with_test_prefix.
	(test_step): New procedure, factored out from duplicate top level
	code.
	(top level): Test "step" in combination with all scheduler-locking
	modes.  Test "next" in combination with all scheduler-locking
	modes, and in combination with stepping over a function call or
	not.
	* gdb.threads/next-bp-other-thread.c: New file.
	* gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 18:15:39 +00:00