public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-7.11-branch] gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print'
@ 2016-02-22 16:28 sergiodj+buildbot
  2016-02-22 16:28 ` Failures on RHEL-s390x-m64, branch gdb-7.11-branch sergiodj+buildbot
                   ` (16 more replies)
  0 siblings, 17 replies; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-22 16:28 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3d58f8997229b9045899dd306a47a3c27d03a9fd ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.11-branch
Commit: 3d58f8997229b9045899dd306a47a3c27d03a9fd

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.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Sync proc_service definition with GLIBC
@ 2016-08-25 17:45 sergiodj+buildbot
  2016-08-25 17:42 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-08-25 17:45 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 140bf80050b34f0947b34dba93b830ea2bfc5040 ***

Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Branch: gdb-7.11-branch
Commit: 140bf80050b34f0947b34dba93b830ea2bfc5040

Sync proc_service definition with GLIBC

GLIBC BZ#20311 [1] proc_service.h install patch also remove 'const'
attributes from ps_get_thread_area and comment #15 discuss why to remove
the const attribute (basically since it a callback with the struct
ps_prochandle owned by the client it should be able to modify it if
it the case).

On default build this is not the issue and current g++ does not trigger
any issue with this mismatch declaration.  However, on some bootstrap
build configuration where gdbserver is build with gcc instead this
triggers:

error: conflicting types for 'ps_get_thread_area'

This patch fixes it by syncing the declaration with GLIBC.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20311

gdb/ChangeLog:

2016-08-25  Adhemerval Zanella  <adhemerval.zanella@linaro.org>

	* aarch64-linux-nat.c (ps_get_thread_area): Remove const from
	struct ps_prochandle.
	* amd64-linux-nat.c (ps_get_thread_area): Likewise.
	* arm-linux-nat.c (ps_get_thread_area): Likewise.
	* gdb_proc_service.h (ps_get_thread_area): Likewise.
	* i386-linux-nat.c (ps_get_thread_area): Likewise.
	* m68klinux-nat.c (ps_get_thread_area): Likewise.
	* mips-linux-nat.c (ps_get_thread_area): Likewise.
	* nat/aarch64-linux.c (aarch64_ps_get_thread_area): Likewise.
	* nat/aarch64-linux.h (aarch64_ps_get_thread_area): Likewise.
	* xtensa-linux-nat.c (ps_get_thread_area): Likewise.

gdb/gdbserver/ChangeLog:

2016-08-25  Adhemerval Zanella  <adhemerval.zanella@linaro.org>

	PR server/20491
	* gdb_proc_service.h (ps_get_thread_area): Remove const from struct
	ps_prochandle.
	* linux-aarch64-low.c (ps_get_thread_area): Likewise.
	* linux-arm-low.c (ps_get_thread_area): Likewise.
	* linux-crisv32-low.c (ps_get_thread_area): Likewise.
	* linux-m68k-low.c (ps_get_thread_area): Likewise.
	* linux-mips-low.c (ps_get_thread_area): Likewise.
	* linux-nios2-low.c (ps_get_thread_area): Likewise.
	* linux-tic6x-low.c (ps_get_thread_area): Likewise.
	* linux-x86-low.c (ps_get_thread_area): Likewise.
	* linux-xtensa-low.c (ps_get_thread_area): Likewise.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Bump GDB version number to 7.11.1.DATE-git.
@ 2016-06-01  1:18 sergiodj+buildbot
  2016-06-01  1:29 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-06-01  1:18 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT d03dfbf66983602a4cdb97c37edd54c420ceed40 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: d03dfbf66983602a4cdb97c37edd54c420ceed40

Bump GDB version number to 7.11.1.DATE-git.

gdb/ChangeLog:

	* version.in: Set GDB version number to 7.11.1.DATE-git.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Set GDB version number to 7.11.1.
@ 2016-06-01  0:54 sergiodj+buildbot
  2016-06-01  1:04 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-06-01  0:54 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 41d82368c333de4f7ec3fd7734ee683055e8c35c ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: 41d82368c333de4f7ec3fd7734ee683055e8c35c

Set GDB version number to 7.11.1.

gdb/ChangeLog:

	* version.in: Set GDB version number to 7.11.1.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix PR gdb/19828: gdb -p <process from a container>: internal error
@ 2016-05-25 18:48 sergiodj+buildbot
  2016-05-25 19:11 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-25 18:48 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 136613ef0c6850427317e57be1b644080ff6decb ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 136613ef0c6850427317e57be1b644080ff6decb

Fix PR gdb/19828: gdb -p <process from a container>: internal error

When GDB attaches to a process, it looks at the /proc/PID/task/ dir
for all clone threads of that process, and attaches to each of them.

Usually, if there is more than one clone thread, it means the program
is multi threaded and linked with pthreads.  Thus when GDB soon after
attaching finds and loads a libthread_db matching the process, it'll
add a thread to the thread list for each of the initially found
lower-level LWPs.

If, however, GDB fails to find/load a matching libthread_db, nothing
is adding the LWPs to the thread list.  And because of that, "detach"
hits an internal error:

  (gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
  info threads
    Id   Target Id         Frame
  * 1    LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
  (gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
  detach
  .../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n)
  FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)

>From here:

  ...
  #8  0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
      at .../src/gdb/common/errors.c:55
  #9  0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
  #10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
  #11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
  #12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
  #13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
  #14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
  #15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
  #16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
  ...

Tested on x86-64 Fedora 23.  Also confirmed the test passes against
gdbserver with "maint set target-non-stop".

Unfortunately, making GDB add LWPs to the thread list sooner exposes
inefficiencies that in turn result in
gdb.threads/attach-many-short-lived-threads.exp timing out frequently.
Since that testcase is really a contrived use case designed to stress
some aspects of attach/detach and thread listing, not really
representative of real programs, this commit disables the test.

gdb/ChangeLog:
2016-05-25  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
	resumed, and add the thread to GDB's thread list.

testsuite/ChangeLog:
2016-05-25  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* gdb.threads/clone-attach-detach.c: New file.
	* gdb.threads/clone-attach-detach.exp: New file.
	* gdb.threads/attach-many-short-lived-threads.exp: Skip.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Make gdb/linux-nat.c consider a waitstatus pending on the infrun side
@ 2016-05-25 17:52 sergiodj+buildbot
  2016-05-25 18:42 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-25 17:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a0de87e7be6a58dfeb9bfb00172dbd975dabb72e ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: a0de87e7be6a58dfeb9bfb00172dbd975dabb72e

Make gdb/linux-nat.c consider a waitstatus pending on the infrun side

Working on the fix for gdb/19828, I saw
gdb.threads/attach-many-short-lived-threads.exp fail once in an
unusual way.  Unfortunately I didn't keep debug logs, but it's an
issue similar to what's been fixed in remote.c a while ago --
linux-nat.c was not fetching the pending status from the right place.

gdb/ChangeLog:
2016-05-25  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (get_pending_status): If the thread reported the
	event to the core and it's pending, use the pending status signal
	number.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Add mi-threads-interrupt.exp test (PR 20039)
@ 2016-05-18 14:59 sergiodj+buildbot
  2016-05-18 16:52 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-18 14:59 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT cf2cd51217c0b99f5370708cc3932c12a1f4edad ***

Author: Simon Marchi <simon.marchi@ericsson.com>
Branch: gdb-7.11-branch
Commit: cf2cd51217c0b99f5370708cc3932c12a1f4edad

Add mi-threads-interrupt.exp test (PR 20039)

Add a new test for PR 20039.  The test spawns new threads, then tries to
interrupt, continue, and interrupt again.  This use case was fixed by
commit 5fe966540d6b748f825774868463003700f0c878 in master, but gdb 7.11
is affected (so if you try it on the gdb-7.11-branch right now, the test
will fail).

New in v2, the test now handles mi-async on mode properly.  The failure
was specific to mi-async off, but I don't think it's bad to test the
same thing under async on mode.  I added a little hack when running in
async mode to work around bug 20045.

I also removed one continue/interrupt pair, as a single one was enough to
trigger the problem.

gdb/testsuite/ChangeLog:

	* gdb.mi/mi-threads-interrupt.c: New file.
	* gdb.mi/mi-threads-interrupt.exp: New file.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix double prompt output after run control MI commands with mi-async on (PR 20045)
@ 2016-05-18 14:48 sergiodj+buildbot
  2016-05-18 16:43 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-18 14:48 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f0a8d0dc70eddbf1e323e8c07f5092ff5e327548 ***

Author: Simon Marchi <simon.marchi@ericsson.com>
Branch: gdb-7.11-branch
Commit: f0a8d0dc70eddbf1e323e8c07f5092ff5e327548

Fix double prompt output after run control MI commands with mi-async on (PR 20045)

When you use a run control command (-exec-run, -exec-continue,
-exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed:

  -exec-continue
  ^running
  *running,thread-id="all"
  (gdb)
  (gdb)

It doesn't seem to be a big problem for front-ends, since this behavior
started in gdb 7.9 and we haven't heard anything about that.  However,
it caused me some trouble while writing a test for PR 20039 [1].

The problem comes from an extra (gdb) prompt that we write when running
in mi-async off mode to emulate a past buggy behavior.  When executing a
run control command synchronously, previous gdbs always printed a prompt
right away, even though they are not ready to accept new MI commands
until the target stops.  Only at this time should they display a prompt.
But to keep backwards compatibility apparently, we print it anyway.
Since commit 198297aaf, the condition that decides whether we should
print that "bogus" prompt or not has become true, even when running with
mi-async on.  Since we already print a prompt at the end of the
asynchronous command execution, it results in two prompts for one
command.

The proposed fix is to call target_can_async_p instead of
target_is_async_p, to make the condition:

  if (!target_can_async_p () || sync_execution)
    ... show prompt ...

That shows the prompt if we are emulating a synchronous command on top
of an asynchronous target (sync_execution) or if the target simply can't
run asynchronously (!target_can_async_p ()).

Note that this code is changed and this bug fixed by Pedro's separate
console series, but I think it would be nice to have it fixed in the
mean time.

I ran the gdb.mi directory of the testsuite with mi-async on and off, I
didn't see any regressions.

gdb/ChangeLog:

	* mi/mi-main.c (mi_on_resume): Call target_can_async_p instead
	of target_is_async_p.

[1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077)
@ 2016-05-17 22:13 sergiodj+buildbot
  2016-05-18  1:55 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-17 22:13 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT b5f0db46b3057bcb64243e7da0943717abd6459b ***

Author: Simon Marchi <simon.marchi@ericsson.com>
Branch: gdb-7.11-branch
Commit: b5f0db46b3057bcb64243e7da0943717abd6459b

Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077)

When doing -exec-run on a freshly started GDB, the only target on the
target stack at the time the dummy one.  When mi_async_p is called to
know whether the run should be async, it queries whether the current
target (dummy) supports async, and the answer is no.  The fix is to make
the code query the target that will be used for the run, which is not
necessarily the current target.

No regressions in the gdb.mi directory using the unix, native-gdbserver
and native-extended-gdbserver boards.  The test doesn't pass when
forcing maint set target-async off, obviously, since it makes mi-async
have no effect.  It doesn't seem like other tests are checking for that
eventuality, so I didn't in the new test.

gdb/ChangeLog:

	* mi/mi-main.c (run_one_inferior): Use run target to determine
	whether to run async or not.
	(mi_cmd_exec_run): Likewise.

gdb/testsuite/ChangeLog:

	* gdb.mi/mi-async-run.exp: New file.
	* gdb.mi/mi-async-run.c: New file.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Use target_terminal_ours_for_output in MI
@ 2016-05-16 21:17 sergiodj+buildbot
  2016-05-16 21:35 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-16 21:17 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7f8e34d8604098e221f342cf162898fb25499900 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 7f8e34d8604098e221f342cf162898fb25499900

Use target_terminal_ours_for_output in MI

The MI code only does output, so leave raw/cooked mode alone, as well
as the SIGINT handler.  Restore terminal settings after output, while
at it.  Also, a couple events missed calling target_terminal_ours
before output, even.

[Backported to the 7.11 branch by Simon Marchi, as it fixes PR 20039.]

gdb/ChangeLog:
YYYY-MM-DD  Pedro Alves  <palves@redhat.com>

	* mi/mi-interp.c (mi_new_thread): Put
	target_terminal_ours_for_output in effect while outputting.
	(mi_thread_exit): Use target_terminal_ours_for_output instead of
	target_terminal_ours.
	(mi_record_changed, mi_inferior_added, mi_inferior_appeared)
	(mi_inferior_exit, mi_inferior_removed, mi_traceframe_changed)
	(mi_tsv_created, mi_tsv_deleted, mi_tsv_modified)
	(mi_breakpoint_created, mi_breakpoint_deleted)
	(mi_breakpoint_modified, mi_solib_loaded, mi_solib_unloaded)
	(mi_command_param_changed, mi_memory_changed)
	(report_initial_inferior): Use target_terminal_ours_for_output
	instead of target_terminal_ours.  Restore terminal settings.
	* mi/mi-main.c (mi_execute_command): Use
	target_terminal_ours_for_output instead of target_terminal_ours.
	Restore terminal settings.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix gdb/python/python.c use-after-free
@ 2016-05-03 11:55 sergiodj+buildbot
  2016-05-03 13:58 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-03 11:55 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 329dec6fc5f2efa83d626583135081b53abe8729 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 329dec6fc5f2efa83d626583135081b53abe8729

Fix gdb/python/python.c use-after-free

Valgrind shows:

 ==26964== Invalid read of size 1
 ==26964==    at 0x6E14100: __GI_strcmp (strcmp.S:180)
 ==26964==    by 0x6DB55AA: setlocale (setlocale.c:238)
 ==26964==    by 0x4E0455: _initialize_python() (python.c:1731)
 ==26964==    by 0x786731: initialize_all_files() (init.c:319)
 ==26964==    by 0x72EF0A: gdb_init(char*) (top.c:1929)
 ==26964==    by 0x60BCAC: captured_main(void*) (main.c:863)
 ==26964==    by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
 ==26964==    by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
 ==26964==    by 0x40CAEC: main (gdb.c:32)
 ==26964==  Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd
 ==26964==    at 0x4C29CF0: free (vg_replace_malloc.c:530)
 ==26964==    by 0x6DB5B65: setname (setlocale.c:201)
 ==26964==    by 0x6DB5B65: setlocale (setlocale.c:388)
 ==26964==    by 0x4E037F: _initialize_python() (python.c:1712)
 ==26964==    by 0x786731: initialize_all_files() (init.c:319)
 ==26964==    by 0x72EF0A: gdb_init(char*) (top.c:1929)
 ==26964==    by 0x60BCAC: captured_main(void*) (main.c:863)
 ==26964==    by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
 ==26964==    by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
 ==26964==    by 0x40CAEC: main (gdb.c:32)

The problem is doing this:

  oldloc = setlocale (LC_ALL, NULL);
  setlocale (LC_ALL, "");
  ...
  setlocale (LC_ALL, oldloc);

I.e., the second setlocale call frees 'oldloc'.

>From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html :

 "The returned string pointer might be invalidated or the string
 content might be overwritten by a subsequent call to setlocale()."

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

	PR python/20037
	* python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree
	oldloc.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Remove gdb/python/python.c code that handles strlen failing with -1
@ 2016-05-03 11:46 sergiodj+buildbot
  2016-05-03 13:32 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-03 11:46 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT aaa3178dfb979f8ec476a326aca273125a1e3ee9 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: aaa3178dfb979f8ec476a326aca273125a1e3ee9

Remove gdb/python/python.c code that handles strlen failing with -1

This makes no sense -- strlen doesn't really ever fail with -1.

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

	* python/python.c (_initialize_python) [IS_PY3K]: Remove dead
	code.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] [gdb] Fix -Wparentheses warnings
@ 2016-05-03  9:05 sergiodj+buildbot
  2016-05-03  9:50 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-05-03  9:05 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 386c90348551eb089124d64c9bc6ab17cbefb016 ***

Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Branch: gdb-7.11-branch
Commit: 386c90348551eb089124d64c9bc6ab17cbefb016

[gdb] Fix -Wparentheses warnings

2016-05-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

	* symfile.c (find_pc_overlay): Add braces to avoid -Wparentheses
	warning.
	(find_pc_mapped_section): Likewise.
	(list_overlays_command): Likewise.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Workaround gdbserver<7.7 for setfs
@ 2016-04-27 19:52 sergiodj+buildbot
  2016-04-27 21:23 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-04-27 19:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a6ff23076f49c6322d96a76e0098f8019139bc4e ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.11-branch
Commit: a6ff23076f49c6322d96a76e0098f8019139bc4e

Workaround gdbserver<7.7 for setfs

With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
	gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
	Sending packet: $vFile:setfs:0#bf...Packet received: OK
	Packet vFile:setfs (hostio-setfs) is supported
	...
	Sending packet: $vFile:setfs:104#24...Packet received: OK
	"target:/root/redhat/threadit": could not open as an executable file: Invalid argument

GDB documentation says:
	The valid responses to Host I/O packets are:
	An empty response indicates that this operation is not recognized.

This "empty response" vs. "OK" was a bug in gdbserver < 7.7.  It was fixed by:
	commit e7f0d979dd5cc4f8b658df892e93db69d6d660b7
	Author: Yao Qi <yao@codesourcery.com>
	Date:   Tue Dec 10 21:59:20 2013 +0800
	    Fix a bug in matching notifications.
	Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
	https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
	2013-12-10  Yao Qi  <yao@codesourcery.com>
		* notif.c (handle_notif_ack): Return 0 if no notification
		matches.

with unpatched old FSF gdbserver and patched FSF GDB HEAD:
	gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
	Sending packet: $vFile:setfs:0#bf...Packet received: OK
	Packet vFile:setfs (hostio-setfs) is NOT supported
	...
	(gdb) info sharedlibrary
	From                To                  Syms Read   Shared Object Library
	0x00007ffff7ddbae0  0x00007ffff7df627a  Yes (*)     target:/lib64/ld-linux-x86-64.so.2
	0x00007ffff7bc48a0  0x00007ffff7bcf514  Yes (*)     target:/lib64/libpthread.so.0

gdb/ChangeLog
2016-04-27  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] MIPS/Linux: Also recognize TRAP_BRKPT and TRAP_HWBKPT
@ 2016-04-16  0:19 sergiodj+buildbot
  2016-04-16  0:48 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-04-16  0:19 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT da611eed9a74de742e9436b6fdd92041b6e9bbf1 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: da611eed9a74de742e9436b6fdd92041b6e9bbf1

MIPS/Linux: Also recognize TRAP_BRKPT and TRAP_HWBKPT

This makes the MIPS Linux backends recognize TRAP_BRKPT and
TRAP_HWBKPT in siginfo.si_code in addition to SI_KERNEL, since Linux
4.6 now reports the finer-grained si_code values too.

Refs:
 https://sourceware.org/ml/gdb-patches/2016-02/msg00756.html
 https://sourceware.org/ml/gdb-patches/2016-04/msg00090.html

On kernels that report SI_KERNEL (<= 4.5), we'll enter the "ambiguous"
path of save_stop_reason:

	  if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)
	      && GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
	    {
	      /* The si_code is ambiguous on this arch -- check debug
		 registers.  */
	      if (!check_stopped_by_watchpoint (lp))
		lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;
	    }

while on kernels that report the finer-grained si_code values (>= 4.6),
we'll enter the corresponding branches:

	  else if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code))
	    {
	    }
	  else if (GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
	    {
	      ...

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

	* nat/linux-ptrace.h [__mips__] (GDB_ARCH_IS_TRAP_BRKPT): Also
	accept TRAP_BRKPT.
	 [__mips__] (GDB_ARCH_IS_TRAP_HWBKPT): Also accept TRAP_HWBKPT.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Handle MIPS Linux SIGTRAP siginfo.si_code values
@ 2016-04-15 23:43 sergiodj+buildbot
  2016-04-16  0:28 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-04-15 23:43 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 619f36aa006c4263ec17b1d2a73613f840042c16 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 619f36aa006c4263ec17b1d2a73613f840042c16

Handle MIPS Linux SIGTRAP siginfo.si_code values

This unbreaks pending/delayed breakpoints handling, as well as
hardware watchpoints, on MIPS.

Ref: https://sourceware.org/ml/gdb-patches/2016-02/msg00681.html

The MIPS kernel reports SI_KERNEL for all kernel generated traps,
instead of TRAP_BRKPT / TRAP_HWBKPT, but GDB isn't aware of this.

Basically, this commit:

- Folds watchpoints logic into check_stopped_by_breakpoint, and
  renames it to save_stop_reason.

- Adds GDB_ARCH_IS_TRAP_HWBKPT.

- Makes MIPS set both GDB_ARCH_IS_TRAP_BRPT and
  GDB_ARCH_IS_TRAP_HWBKPT to SI_KERNEL.  In save_stop_reason, we
  handle the case of the same si_code returning true for both
  TRAP_BRPT and TRAP_HWBKPT by looking at what the debug registers
  say.

Tested on x86-64 Fedora 20, native and gdbserver.

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

	* linux-nat.c (save_sigtrap) Delete.
	(stop_wait_callback): Call save_stop_reason instead of
	save_sigtrap.
	(check_stopped_by_breakpoint): Rename to ...
	(save_stop_reason): ... this.  Bits of save_sigtrap folded here.
	Use GDB_ARCH_IS_TRAP_HWBKPT and handle ambiguous
	GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT.  Factor out
	common code between the USE_SIGTRAP_SIGINFO and
	!USE_SIGTRAP_SIGINFO blocks.
	(linux_nat_filter_event): Call save_stop_reason instead of
	save_sigtrap.
	* nat/linux-ptrace.h: Check for both SI_KERNEL and TRAP_BRKPT
	si_code for MIPS.
	* nat/linux-ptrace.h: Fix "TRAP_HWBPT" typo in x86 table.  Add
	comments on MIPS behavior.
	(GDB_ARCH_IS_TRAP_HWBKPT): Define for all archs.

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

	* linux-low.c (check_stopped_by_breakpoint): Rename to ...
	(save_stop_reason): ... this.  Use GDB_ARCH_IS_TRAP_HWBKPT and
	handle ambiguous GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT.
	Factor out common code between the USE_SIGTRAP_SIGINFO and
	!USE_SIGTRAP_SIGINFO blocks.
	(linux_low_filter_event): Call save_stop_reason instead of
	check_stopped_by_breakpoint and check_stopped_by_watchpoint.
	Update comments.
	(linux_wait_1): Update comments.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix PR remote/19840: gdb crashes on reverse-stepi
@ 2016-04-13 13:51 sergiodj+buildbot
  2016-04-13 15:22 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-04-13 13:51 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6b9ef0d488c556339aea7b095ef7a9b6bf6b1af1 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 6b9ef0d488c556339aea7b095ef7a9b6bf6b1af1

Fix PR remote/19840: gdb crashes on reverse-stepi

Reverse debugging against a remote target that does reverse debugging
itself (with the bs/bc packets) always trips on:

 (gdb) target remote localhost:...
 (gdb) reverse-stepi
 ../../gdb/target.c:602: internal-error: default_execution_direction: to_execution_direction must be implemented for reverse async

I missed adding a to_execution_direction method to remote.c in commit
3223143295b5 (Adds target_execution_direction to make record targets
support async mode), GDB 7.4 time.  Later, GDB 7.8 switched to
target-async on by default, making the regression user-visible by
default too.

Fix is simply to add the missing to_execution_direction implementation
to target remote.

Tested by Andi Kleen against Simics.

gdb/ChangeLog:
2016-04-13  Pedro Alves  <palves@redhat.com>

	PR remote/19840
	* remote.c (struct remote_state) <last_resume_exec_dir>: New
	field.
	(new_remote_state): Default last_resume_exec_dir to EXEC_FORWARD.
	(remote_open_1): Reset last_resume_exec_dir to EXEC_FORWARD.
	(remote_resume): Store the last execution direction.
	(remote_execution_direction): New function.
	(init_remote_ops): Install it as to_execution_direction target_ops
	method.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Add regression test for PR gdb/19858 (JIT code registration on attach)
@ 2016-03-31 19:43 sergiodj+buildbot
  2016-04-01  1:07 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-03-31 19:43 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 85af34ee0211eedf8d30a5c44dfc59dddf8b512a ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 85af34ee0211eedf8d30a5c44dfc59dddf8b512a

Add regression test for PR gdb/19858 (JIT code registration on attach)

This test would fail without the previous gdb/jit.c fix:

  (gdb) attach 23031
  Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031
  [...]
  207           WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
  (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach
  set var wait_for_gdb = 0
  (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0
  info function ^jit_function
  All functions matching regular expression "^jit_function":
  (gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function

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

	PR gdb/19858
	* gdb.base/jit-main.c: Include unistd.h.
	(ATTACH): Define to 0 if not already defined.
	(wait_for_gdb, mypid): New globals.
	(WAIT_FOR_GDB): New macro.
	(MAIN): Set an alarm.  Store the process's pid.  Wait for GDB at
	some breakpoint locations.
	* gdb.base/jit.exp (clean_reattach, continue_to_test_location):
	New procedures.
	(one_jit_test): Add REATTACH parameter, and handle it.  Use
	continue_to_test_location.
	(top level): Test attach, and adjusts calls to one_jit_test.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Make gdb.base/jit.exp binaries unique
@ 2016-03-31 19:33 sergiodj+buildbot
  2016-04-01  0:55 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-03-31 19:33 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 89df5d6cce0e91c4b34c7a62ba4a68756a8ed4e7 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.11-branch
Commit: 89df5d6cce0e91c4b34c7a62ba4a68756a8ed4e7

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.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix PR gdb/19858: GDB doesn't register the JIT libraries on attach
@ 2016-03-31 19:23 sergiodj+buildbot
  2016-04-01  0:44 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-03-31 19:23 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT cd64cabb8c66a5565fc33bf66a07c08bc767e413 ***

Author: Yichao Yu <yyc1992@gmail.com>
Branch: gdb-7.11-branch
Commit: cd64cabb8c66a5565fc33bf66a07c08bc767e413

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 (03bef283c2d3):
 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>


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] btrace: fix PR gdb/19829
@ 2016-03-17 11:28 sergiodj+buildbot
  2016-03-18  0:47 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-03-17 11:28 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 2ef34d11f61d79dcb152713aa059051d8cd3295d ***

Author: Markus Metzger <markus.t.metzger@intel.com>
Branch: gdb-7.11-branch
Commit: 2ef34d11f61d79dcb152713aa059051d8cd3295d

btrace: fix PR gdb/19829

This is a backport of

33b4777ca1b7 btrace, frame: fix crash in get_frame_type
a038fa3e14a4 stack: check frame_unwind_caller_id
2f3ef606b912 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.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Bump GDB version number to 7.11.0.DATE-git.
@ 2016-02-24 10:31 sergiodj+buildbot
  2016-02-24 10:54 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-24 10:31 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 63a034c19fa2a0c09aeb1ae3575daa57edf19d0c ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: 63a034c19fa2a0c09aeb1ae3575daa57edf19d0c

Bump GDB version number to 7.11.0.DATE-git.

gdb/ChangeLog:

	* version.in: Set GDB version number to 7.11.0.DATE-git.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Set GDB version number to 7.11.
@ 2016-02-24 10:07 sergiodj+buildbot
  2016-02-24 10:27 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-24 10:07 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ac6c80b22321afd27328828f2e4a67220ffed2d5 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: ac6c80b22321afd27328828f2e4a67220ffed2d5

Set GDB version number to 7.11.

gdb/ChangeLog:

	* version.in: Set GDB version number to 7.11.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] PR remote/19496, internal err forking-threads-plus-bkpt
@ 2016-02-16 17:31 sergiodj+buildbot
  2016-02-16 17:54 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-16 17:31 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT e993d610a980ea8df9200f158bfae69308c2138d ***

Author: Don Breazeal <donb@codesourcery.com>
Branch: gdb-7.11-branch
Commit: e993d610a980ea8df9200f158bfae69308c2138d

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.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix cleanup in arm_linux_software_single_step
@ 2016-02-16 14:55 sergiodj+buildbot
  2016-02-16 15:10 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-16 14:55 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 523f1dab16b5c8706bbb81c6fdbac741b3fffb19 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.11-branch
Commit: 523f1dab16b5c8706bbb81c6fdbac741b3fffb19

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.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Fix more testcases with standard_output_file.
@ 2016-02-15 18:07 sergiodj+buildbot
  2016-02-15 18:26 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-15 18:07 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 8b6bd5aca63189590498195a7a2696cde021c9cd ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.11-branch
Commit: 8b6bd5aca63189590498195a7a2696cde021c9cd

Fix more testcases with standard_output_file.

Since
	commit 2151ccc56c74b55a8f0debf0724a495368f92591
	Author: Simon Marchi <simon.marchi@ericsson.com>
	Date:   Mon Feb 8 14:02:36 2016 -0500
	    Always organize test artifacts in a directory hierarchy
these testfiles could not build.

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

	* gdb.arch/i386-gnu-cfi.exp: Use standard_output_file.
	* gdb.arch/i386-prologue.exp: Likewise.
	* gdb.arch/i386-size.exp: Likewise.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] testsuite: Fix false Fortran regressions with recent gcc
@ 2016-02-14  8:52 sergiodj+buildbot
  2016-02-14 10:03 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-14  8:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 46e42194d8d2585b6860b1267c2b3e24ba9c589c ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.11-branch
Commit: 46e42194d8d2585b6860b1267c2b3e24ba9c589c

testsuite: Fix false Fortran regressions with recent gcc

gcc-4.9.2-6.fc21.x86_64 -> gcc-5.3.1-2.fc23.x86_64

-PASS: gdb.fortran/vla-ptype.exp: ptype pvla not initialized
+FAIL: gdb.fortran/vla-ptype.exp: ptype pvla not initialized
-PASS: gdb.fortran/vla-history.exp: print vla1 allocated
+FAIL: gdb.fortran/vla-history.exp: print vla1 allocated
-PASS: gdb.fortran/vla-history.exp: print $2
+FAIL: gdb.fortran/vla-history.exp: print $2
-PASS: gdb.fortran/vla-value.exp: print undefined pvla
+FAIL: gdb.fortran/vla-value.exp: print undefined pvla
-PASS: gdb.fortran/vla-value.exp: print non-associated &pvla
+FAIL: gdb.fortran/vla-value.exp: print non-associated &pvla
-PASS: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)
+FAIL: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)

These issues get fixed (or removed if no longer applicable) by attached patch.

It is based on Googled:
	http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#5
	When a pointer is declared its status is undefined, and cannot be
	safely queried with the associated intrinsic.
	-> nullify(VARNAME)
+
	https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786
	ALLOCATE is not supposed to initialize the array.
	-> Remove checks like an initial print is: \\( *0, *0, *0...\\)

These regressions remain:
	-PASS: gdb.fortran/library-module.exp: print var_i in lib
	+FAIL: gdb.fortran/library-module.exp: print var_i in lib
	-PASS: gdb.fortran/library-module.exp: print var_i in main
	+FAIL: gdb.fortran/library-module.exp: print var_i in main
I believe it is more a GDB bug (in a code contributed by me), filed:
	gdb.fortran/library-module.exp false regression on GCC upgrade
	https://sourceware.org/bugzilla/show_bug.cgi?id=19635

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

	Fix compatibility with recent gfortran-5.3.1.
	* gdb.fortran/vla-history.exp (print vla1 allocated)
	(print vla2 allocated, print $2, print $3): Remove
	(print $4): Rename to ...
	(print $2): ... here.
	(print $9): Rename to ...
	(print $5): ... here.
	(print $10): Rename to ...
	(print $6): ... here.
	* gdb.fortran/vla.f90: Add pvla initialization.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] testsuite regression: gdb.fortran/vla-value-sub.exp gdb.fortran/vla-value-sub-finish.exp
@ 2016-02-14  8:35 sergiodj+buildbot
  2016-02-14  9:11 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-14  8:35 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 307c2facb242da4fc557baea06e63d8e8a621142 ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.11-branch
Commit: 307c2facb242da4fc557baea06e63d8e8a621142

testsuite regression: gdb.fortran/vla-value-sub.exp gdb.fortran/vla-value-sub-finish.exp

> +static int max_value_size = 65536; /* 64k bytes */

FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)
FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was mofified in debugger (passed fixed array)
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was filled
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was mofified in debugger

print array2
value requires 296352 bytes, which is more than max-value-size
(gdb) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)

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

	* gdb.fortran/vla-value-sub-finish.exp (set max-value-size 1024*1024):
	New test.
	* gdb.fortran/vla-value-sub.exp: Likewise.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Clear *VAL in regcache_raw_read_unsigned
@ 2016-02-10 16:55 sergiodj+buildbot
  2016-02-10 17:12 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-10 16:55 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 83d9e733abe9cc0553f899064a955a6255550ade ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.11-branch
Commit: 83d9e733abe9cc0553f899064a955a6255550ade

Clear *VAL in regcache_raw_read_unsigned

We have function regcache_raw_read_unsigned defined in both GDB and
GDBserver, so that it is used in common like this,

  ULONGEST value;
  status = regcache_raw_read_unsigned (regcache, regnum, &value);

'value' is correctly set in GDB side, but may not be correctly set
in GDBserver, because &value is passed in regcache_raw_read_unsigned
but collect_register may only set part of the whole variable.  In my
test, I see the top half of 'value' is garbage.  This patch fixes this
problem by clearing *VAL before calling collect_register.

gdb/gdbserver:

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

	* regcache.c (regcache_raw_read_unsigned): Clear *VAL.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] gdb/version.in: Replace -cvs suffix by -git suffix
@ 2016-02-10  9:41 sergiodj+buildbot
  2016-02-10  9:58 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-10  9:41 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7bcc056ca977328fa96a24fd747834f100be863a ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: 7bcc056ca977328fa96a24fd747834f100be863a

gdb/version.in: Replace -cvs suffix by -git suffix

gdb/ChangeLog:

        * version.in: Replace -cvs suffix by -git suffix.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Bump GDB version number to 7.10.90.DATE-cvs.
@ 2016-02-10  4:32 sergiodj+buildbot
  2016-02-10  6:30 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-10  4:32 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 45e8913772c2db1235b3a0eb113d804cb254af13 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: 45e8913772c2db1235b3a0eb113d804cb254af13

Bump GDB version number to 7.10.90.DATE-cvs.

gdb/ChangeLog:

	* version.in: Set GDB version number to 7.10.90.DATE-cvs.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Set GDB version number to 7.10.90.
@ 2016-02-10  4:23 sergiodj+buildbot
  2016-02-10  6:07 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-10  4:23 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 8e1043a37a176f07f0e06d29fe2f54752c8976e5 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: 8e1043a37a176f07f0e06d29fe2f54752c8976e5

Set GDB version number to 7.10.90.

gdb/ChangeLog:

	* version.in: Set GDB version number to 7.10.90.


^ permalink raw reply	[flat|nested] 50+ messages in thread
* [binutils-gdb/gdb-7.11-branch] Bump version to 7.10.90.DATE-git.
@ 2016-02-10  3:41 sergiodj+buildbot
  2016-02-10  3:59 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
  0 siblings, 1 reply; 50+ messages in thread
From: sergiodj+buildbot @ 2016-02-10  3:41 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT d5d168eef1464c735c5dba0cf76d638bd27970b9 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.11-branch
Commit: d5d168eef1464c735c5dba0cf76d638bd27970b9

Bump version to 7.10.90.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 (9ef9e6a6a0dd8f948708cb67c9afcfd0be40cb0a):
	* version.in: Bump version to 7.10.90.DATE-git.


^ permalink raw reply	[flat|nested] 50+ messages in thread

end of thread, other threads:[~2016-08-25  8:57 UTC | newest]

Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-22 16:28 [binutils-gdb/gdb-7.11-branch] gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print' sergiodj+buildbot
2016-02-22 16:28 ` Failures on RHEL-s390x-m64, branch gdb-7.11-branch sergiodj+buildbot
2016-02-22 16:28 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2016-02-22 16:31 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2016-02-22 16:31 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2016-02-22 16:32 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2016-02-22 16:40 ` Failures on Debian-i686, " sergiodj+buildbot
2016-02-22 16:43 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2016-02-22 16:47 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2016-02-22 16:53 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot
2016-02-22 17:11 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2016-02-22 17:15 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2016-02-22 17:22 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj+buildbot
2016-02-22 17:28 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot
2016-02-22 17:34 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2016-02-22 17:45 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot
2016-02-22 18:10 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot
2016-02-22 18:46 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot
  -- strict thread matches above, loose matches on Subject: below --
2016-08-25 17:45 [binutils-gdb/gdb-7.11-branch] Sync proc_service definition with GLIBC sergiodj+buildbot
2016-08-25 17:42 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-06-01  1:18 [binutils-gdb/gdb-7.11-branch] Bump GDB version number to 7.11.1.DATE-git sergiodj+buildbot
2016-06-01  1:29 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-06-01  0:54 [binutils-gdb/gdb-7.11-branch] Set GDB version number to 7.11.1 sergiodj+buildbot
2016-06-01  1:04 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-25 18:48 [binutils-gdb/gdb-7.11-branch] Fix PR gdb/19828: gdb -p <process from a container>: internal error sergiodj+buildbot
2016-05-25 19:11 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-25 17:52 [binutils-gdb/gdb-7.11-branch] Make gdb/linux-nat.c consider a waitstatus pending on the infrun side sergiodj+buildbot
2016-05-25 18:42 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-18 14:59 [binutils-gdb/gdb-7.11-branch] Add mi-threads-interrupt.exp test (PR 20039) sergiodj+buildbot
2016-05-18 16:52 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-18 14:48 [binutils-gdb/gdb-7.11-branch] Fix double prompt output after run control MI commands with mi-async on (PR 20045) sergiodj+buildbot
2016-05-18 16:43 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-17 22:13 [binutils-gdb/gdb-7.11-branch] Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077) sergiodj+buildbot
2016-05-18  1:55 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-16 21:17 [binutils-gdb/gdb-7.11-branch] Use target_terminal_ours_for_output in MI sergiodj+buildbot
2016-05-16 21:35 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-03 11:55 [binutils-gdb/gdb-7.11-branch] Fix gdb/python/python.c use-after-free sergiodj+buildbot
2016-05-03 13:58 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-03 11:46 [binutils-gdb/gdb-7.11-branch] Remove gdb/python/python.c code that handles strlen failing with -1 sergiodj+buildbot
2016-05-03 13:32 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-05-03  9:05 [binutils-gdb/gdb-7.11-branch] [gdb] Fix -Wparentheses warnings sergiodj+buildbot
2016-05-03  9:50 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-04-27 19:52 [binutils-gdb/gdb-7.11-branch] Workaround gdbserver<7.7 for setfs sergiodj+buildbot
2016-04-27 21:23 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-04-16  0:19 [binutils-gdb/gdb-7.11-branch] MIPS/Linux: Also recognize TRAP_BRKPT and TRAP_HWBKPT sergiodj+buildbot
2016-04-16  0:48 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-04-15 23:43 [binutils-gdb/gdb-7.11-branch] Handle MIPS Linux SIGTRAP siginfo.si_code values sergiodj+buildbot
2016-04-16  0:28 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-04-13 13:51 [binutils-gdb/gdb-7.11-branch] Fix PR remote/19840: gdb crashes on reverse-stepi sergiodj+buildbot
2016-04-13 15:22 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-03-31 19:43 [binutils-gdb/gdb-7.11-branch] Add regression test for PR gdb/19858 (JIT code registration on attach) sergiodj+buildbot
2016-04-01  1:07 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-03-31 19:33 [binutils-gdb/gdb-7.11-branch] Make gdb.base/jit.exp binaries unique sergiodj+buildbot
2016-04-01  0:55 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-03-31 19:23 [binutils-gdb/gdb-7.11-branch] Fix PR gdb/19858: GDB doesn't register the JIT libraries on attach sergiodj+buildbot
2016-04-01  0:44 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-03-17 11:28 [binutils-gdb/gdb-7.11-branch] btrace: fix PR gdb/19829 sergiodj+buildbot
2016-03-18  0:47 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-24 10:31 [binutils-gdb/gdb-7.11-branch] Bump GDB version number to 7.11.0.DATE-git sergiodj+buildbot
2016-02-24 10:54 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-24 10:07 [binutils-gdb/gdb-7.11-branch] Set GDB version number to 7.11 sergiodj+buildbot
2016-02-24 10:27 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-16 17:31 [binutils-gdb/gdb-7.11-branch] PR remote/19496, internal err forking-threads-plus-bkpt sergiodj+buildbot
2016-02-16 17:54 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-16 14:55 [binutils-gdb/gdb-7.11-branch] Fix cleanup in arm_linux_software_single_step sergiodj+buildbot
2016-02-16 15:10 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-15 18:07 [binutils-gdb/gdb-7.11-branch] Fix more testcases with standard_output_file sergiodj+buildbot
2016-02-15 18:26 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-14  8:52 [binutils-gdb/gdb-7.11-branch] testsuite: Fix false Fortran regressions with recent gcc sergiodj+buildbot
2016-02-14 10:03 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-14  8:35 [binutils-gdb/gdb-7.11-branch] testsuite regression: gdb.fortran/vla-value-sub.exp gdb.fortran/vla-value-sub-finish.exp sergiodj+buildbot
2016-02-14  9:11 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-10 16:55 [binutils-gdb/gdb-7.11-branch] Clear *VAL in regcache_raw_read_unsigned sergiodj+buildbot
2016-02-10 17:12 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-10  9:41 [binutils-gdb/gdb-7.11-branch] gdb/version.in: Replace -cvs suffix by -git suffix sergiodj+buildbot
2016-02-10  9:58 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-10  4:32 [binutils-gdb/gdb-7.11-branch] Bump GDB version number to 7.10.90.DATE-cvs sergiodj+buildbot
2016-02-10  6:30 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-10  4:23 [binutils-gdb/gdb-7.11-branch] Set GDB version number to 7.10.90 sergiodj+buildbot
2016-02-10  6:07 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot
2016-02-10  3:41 [binutils-gdb/gdb-7.11-branch] Bump version to 7.10.90.DATE-git sergiodj+buildbot
2016-02-10  3:59 ` Failures on Fedora-x86_64-native-gdbserver-m32, branch gdb-7.11-branch sergiodj+buildbot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).