public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* Test results for commit 3b41352824ddc32dabca2d3281a03b4a0b8c7a27 on branch gdb-7.9-branch
@ 2015-02-19 15:26 sergiodj
  2015-02-19 15:30 ` Failures on Fedora-ppc64be-cc-with-index, " sergiodj
                   ` (15 more replies)
  0 siblings, 16 replies; 35+ messages in thread
From: sergiodj @ 2015-02-19 15:26 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3b41352824ddc32dabca2d3281a03b4a0b8c7a27 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.9-branch
Commit: 3b41352824ddc32dabca2d3281a03b4a0b8c7a27

Fix the gdb version number ("7.9" instead of "str 7.9").
This fixes an obvious error in the previous change to this file.

gdb/ChangeLog:

        * version.in: Change to "7.9" instead of "str 7.9".


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-7.9-branch] PR gdb/18464: Do not crash on unrecognized GNU .note.ABI-tag values
@ 2015-05-29 17:52 sergiodj+buildbot
  2015-05-30  0:26 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2015-05-29 17:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 509cc2cf714f6a194ab27610f4db429579f6090b ***

Author: Roland McGrath <mcgrathr@chromium.org>
Branch: gdb-7.9-branch
Commit: 509cc2cf714f6a194ab27610f4db429579f6090b

PR gdb/18464: Do not crash on unrecognized GNU .note.ABI-tag values
Diagnosis of unexpected input (in this case, in an executable file)
should not crash as if it were a bug in GDB.

gdb/
	PR gdb/18464
	* osabi.c (generic_elf_osabi_sniff_abi_tag_sections): Use warning
	rather than internal_error for an unrecognized value.

(cherry picked from commit c8f6c93cb29febd6b8174a20eb35368e70f62faa)


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-7.9-branch] PR python/18299
@ 2015-04-29  6:16 sergiodj+buildbot
  2015-04-29 14:30 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2015-04-29  6:16 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7d4281ee53df975135c132970e053a74bb18877a ***

Author: Doug Evans <dje@google.com>
Branch: gdb-7.9-branch
Commit: 7d4281ee53df975135c132970e053a74bb18877a

PR python/18299
gdb/ChangeLog:

	PR python/18299
	* python/lib/gdb/printing.py (register_pretty_printer): Handle
	name or __name__ attributes.  Handle gdb module as first argument.

gdb/testsuite/ChangeLog:

	* gdb.python/py-pp-maint.py: Move "replace" testing to ...
	* gdb.python/py-pp-registration.exp: ... here.  New file.
	* gdb.python/py-pp-registration.c: New file.
	* gdb.python/py-pp-registration.py: New file.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-7.9-branch] Fix undefined behavior in TUI's TAB expansion
@ 2015-03-21 11:59 sergiodj+buildbot
  2015-03-21 14:33 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2015-03-21 11:59 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 4fa4c2f7bed85f7cb116466d3cf194cdb6271c60 ***

Author: Eli Zaretskii <eliz@gnu.org>
Branch: gdb-7.9-branch
Commit: 4fa4c2f7bed85f7cb116466d3cf194cdb6271c60

Fix undefined behavior in TUI's TAB expansion
gdb/ChangeLog:

	* tui/tui-io.c (tui_expand_tabs): Reinitialize the column counter
	before the second loop, to avoid undefined behavior.  Reported by
	Anton Blanchard <anton@samba.org>.

(cherry picked from commit b1a0f704950296b2363192ba91999eef3635700f)


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-7.9-branch] Remove // comment in gdb/iq2000-tdep.c
@ 2015-02-26 12:11 sergiodj+buildbot
  2015-02-26 13:07 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2015-02-26 12:11 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f57347efc0338cf65539f965f171a318c4a4e523 ***

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

Remove // comment in gdb/iq2000-tdep.c
gdb/ChangeLog:

	PR build/18033:
	* iq2000-tdep.c (iq2000_frame_cache): Delete C++-style comment.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit c9ae55c9597064a8fe9a20899a17a394ac4ee3f8 on branch gdb-7.9-branch
@ 2015-02-20 19:31 sergiodj
  2015-02-20 20:28 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-20 19:31 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT c9ae55c9597064a8fe9a20899a17a394ac4ee3f8 ***

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

Bump GDB version number to 7.9.0.DATE-cvs.
gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 7b582627bc42922de3b75792472f5223f1910277 on branch gdb-7.9-branch
@ 2015-02-20  5:01 sergiodj
  2015-02-20  9:25 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-20  5:01 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7b582627bc42922de3b75792472f5223f1910277 ***

Author: David Taylor <dtaylor@emc.com>
Branch: gdb-7.9-branch
Commit: 7b582627bc42922de3b75792472f5223f1910277

[gdb/ax] small "setv" fix and documentation's adjustment.
gdb/doc/agentexpr.texi documents the "setv" opcode as follow:

    @item @code{setv} (0x2d) @var{n}: @result{} @var{v}
    Set trace state variable number @var{n} to the value found on the top
    of the stack.  The stack is unchanged, so that the value is readily
    available if the assignment is part of a larger expression.  The
    handling of @var{n} is as described for @code{getv}.

The @item line is incorrect (and does not match with its
description), so this patch fixes it.

Additionally, in gdb/common/ax.def we find the line:

    DEFOP (setv, 2, 0, 0, 1, 0x2d)

>From the comment earlier in the file:

       Each line is of the form:

       DEFOP (name, size, data_size, consumed, produced, opcode)
[...]
       CONSUMED is the number of stack elements consumed.
       PRODUCED is the number of stack elements produced.

which is saying that nothing is consumed and one item is produced.
Both should be 0 or both should be 1.

This patch sets them both to 1, which seems better since if nothing
is on the stack an error will occur.

gdb/ChangeLog:

        * common/ax.def (setv): Fix consumed entry in setv DEFOP.

gdb/doc/ChangeLog:

        * agentexpr.texi (Bytecode Descriptions): Fix summary line for setv.

Tested on x86_64-linux.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 3b7a39661610038aad32563069b10fb2cfc55fab on branch gdb-7.9-branch
@ 2015-02-20  4:06 sergiodj
  2015-02-20  7:18 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-20  4:06 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3b7a39661610038aad32563069b10fb2cfc55fab ***

Author: Andreas Arnez <arnez@linux.vnet.ibm.com>
Branch: gdb-7.9-branch
Commit: 3b7a39661610038aad32563069b10fb2cfc55fab

Fix internal error when core file section is too big
As reported in PR 17808, a test case with a forged (invalid) core file
can crash GDB with an assertion failure.  In that particular case the
prstatus of an i386 core file looks like that from an AMD64 core file.
Consequently the respective regset supply function i386_supply_gregset
is invoked with a larger buffer than usual.  But i386_supply_gregset
asserts a specific buffer size, and this assertion fails.

The patch relaxes all buffer size assertions in regset supply
functions such that they merely check for a sufficiently large buffer.
For consistency the regset collect functions are adjusted as well.

gdb/ChangeLog:

	PR corefiles/17808:
	* gdbarch.sh (iterate_over_regset_sections_cb): Document this
	function type, particularly its SIZE parameter.
	* gdbarch.h: Regenerate.
	* amd64-tdep.c (amd64_supply_fpregset): In gdb_assert, compare
	actual against required size using ">=" instead of "==".
	(amd64_collect_fpregset): Likewise.
	* i386-tdep.c (i386_supply_gregset): Likewise.
	(i386_collect_gregset): Likewise.
	(i386_supply_fpregset): Likewise.
	(i386_collect_fpregset): Likewise.
	* mips-linux-tdep.c (mips_supply_gregset_wrapper): Likewise.
	(mips_fill_gregset_wrapper): Likewise.
	(mips_supply_fpregset_wrapper): Likewise.
	(mips_fill_fpregset_wrapper): Likewise.
	(mips64_supply_gregset_wrapper): Likewise.
	(mips64_fill_gregset_wrapper): Likewise.
	(mips64_supply_fpregset_wrapper): Likewise.
	(mips64_fill_fpregset_wrapper): Likewise.
	* mn10300-linux-tdep.c (am33_supply_gregset_method): Likewise.
	(am33_supply_fpregset_method): Likewise.
	(am33_collect_gregset_method): Likewise.
	(am33_collect_fpregset_method): Likewise.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 77ef543e9e7861214232c63c960eddf19674cf61 on branch gdb-7.9-branch
@ 2015-02-19 14:13 sergiodj
  2015-02-19 16:17 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-19 14:13 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 77ef543e9e7861214232c63c960eddf19674cf61 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.9-branch
Commit: 77ef543e9e7861214232c63c960eddf19674cf61

Set GDB version number to str 7.9.
gdb/ChangeLog:

	* version.in: Set GDB version number to str 7.9.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 90ca3b45da1c08eff31605b2af7cec9979a95bde on branch gdb-7.9-branch
@ 2015-02-19 13:35 sergiodj
  2015-02-19 14:36 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-19 13:35 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 90ca3b45da1c08eff31605b2af7cec9979a95bde ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.9-branch
Commit: 90ca3b45da1c08eff31605b2af7cec9979a95bde

gdb/NEWS: "Changes since GDB 7.8" -> "Changes in GDB 7.9".
gdb/ChangeLog:

        * NEWS: Rewrite "Changes since GDB 7.8" into "Changes in GDB 7.9".


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 5991bec1d4dbd23b476dc90bc6d1ba70e044898e on branch gdb-7.9-branch
@ 2015-02-17 15:08 sergiodj
  2015-02-17 17:59 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-17 15:08 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5991bec1d4dbd23b476dc90bc6d1ba70e044898e ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.9-branch
Commit: 5991bec1d4dbd23b476dc90bc6d1ba70e044898e

Simplify event-loop core, remove two-step event processing
Even with the previous patch installed, we'll still see
sigall-reverse.exp occasionally fail.  The problem is that the event
loop's event handling processing is done in two steps:

 #1 - poll all event sources, and push new event objects to the event
  queue, until all event sources are drained.

 #2 - go through the event queue, processing each event object at a
  time.  For each event, call the associated callback, and deletes the
  event object from the queue.

and then bad things happen if between #1 and #2 something decides that
events from an event source that has already queued events shouldn't
be processed yet.  To do that, we either remove the event source from
the list of event sources, or clear its "have events" flag.  However,
if an event for that source has meanwhile already been pushed in the
event queue, #2 will still process it and call the associated
callback...

One way to fix it that I considered was to do something to the event
objects already in the event queue when an event source is no longer
interesting.  But then I couldn't find any good reason for the
two-step process in the first place.  It's much simpler (and less
code) to call the event source callbacks as we poll the sources and
find events.

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

gdb/
2015-02-17  Pedro Alves  <palves@redhat.com>

	* event-loop.c: Don't declare nor define a queue type for
	gdb_event_p.
	(event_queue): Delete.
	(create_event, create_file_event, gdb_event_xfree)
	(initialize_event_loop, process_event): Delete.
	(gdb_do_one_event): Return as soon as one event is handled.
	(handle_file_event): Change prototype.  Used the passed in
	file_handler pointer and ready_mask instead of looping over all
	file handlers.
	(gdb_wait_for_event): Update the poll/select timeouts before
	blocking.  Run event handlers directly instead of queueing events.
	Return as soon as one event is handled.
	(struct async_event_handler_data): Delete.
	(invoke_async_event_handler): Delete.
	(check_async_event_handlers): Change return type to int.  Run
	event handlers directly instead of queueing events.  Return as
	soon as one event is handled.
	(handle_timer_event): Delete.
	(update_wait_timeout): New function, factored out from
	poll_timers.
	(poll_timers): Reimplement.
	* event-loop.h (initialize_event_loop): Delete declaration.
	* top.c (gdb_init): Don't call initialize_event_loop.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit d4a0a1ff2b7f3d50180229768a270750ef94bbdf on branch gdb-7.9-branch
@ 2015-02-17 13:49 sergiodj
  2015-02-17 16:28 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-17 13:49 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT d4a0a1ff2b7f3d50180229768a270750ef94bbdf ***

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

When disabling target async, remove all target event sources from the event loop
The sigall-reverse.exp test occasionally fails with something like this:

 (gdb) PASS: gdb.reverse/sigall-reverse.exp: send signal TERM
 continue
 Continuing.
 The next instruction is syscall exit_group.  It will make the program exit.  Do you want to stop the program?([y] or n) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit (timeout)
 FAIL: gdb.reverse/sigall-reverse.exp: reverse to handler of TERM (timeout)
 FAIL: gdb.reverse/sigall-reverse.exp: reverse to gen_TERM (timeout)

This is another event-loop/async related problem exposed by the patch
that made 'query' use gdb_readline_wrapper (588dcc3edbde19f9).

The problem is that even though gdb_readline_wrapper disables
target-async while the secondary prompt is in progress, the record
target's async event source is left marked.  So when
gdb_readline_wrapper nests an event loop to process input, it may
happen that that event loop ends up processing a target event while
GDB is not really ready for it.  Here's the relevant part of the
backtrace showing the root issue in action:

...
 #14 0x000000000061cb48 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:4158
 #15 0x0000000000642917 in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:57
 #16 0x000000000077ca5c in record_full_async_inferior_event_handler (data=0x0) at src/gdb/record-full.c:791
 #17 0x0000000000640fdf in invoke_async_event_handler (data=...) at src/gdb/event-loop.c:1067
 #18 0x000000000063fb01 in process_event () at src/gdb/event-loop.c:339
 #19 0x000000000063fb2a in gdb_do_one_event () at src/gdb/event-loop.c:360
 #20 0x000000000074d607 in gdb_readline_wrapper (prompt=0x3588f40 "The next instruction is syscall exit_group.  It will make the program exit.  Do you want to stop the program?([y] or n) ") at src/gdb/top.c:842
 #21 0x0000000000750bd9 in defaulted_query (ctlstr=0x8c6588 "The next instruction is syscall exit_group.  It will make the program exit.  Do you want to stop the program?", defchar=121 'y', args=0x7fff70524410) at src/gdb/utils.c:1279
 #22 0x0000000000750e4c in yquery (ctlstr=0x8c6588 "The next instruction is syscall exit_group.  It will make the program exit.  Do you want to stop the program?") at src/gdb/utils.c:1358
 #23 0x00000000004b020e in record_linux_system_call (syscall=gdb_sys_exit_group, regcache=0x3529450, tdep=0xd6c840 <amd64_linux_record_tdep>) at src/gdb/linux-record.c:1933

With my all-stop-on-top-of-non-stop series, I'm also seeing
gdb.server/ext-attach.exp fail occasionally due to the same issue.

The first part of the fix is for target_async implementations to make
sure to remove/unmark all target-related event sources from the event
loop.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2015-02-17  Pedro Alves  <palves@redhat.com>

	* event-loop.c (clear_async_event_handler): New function.
	* event-loop.h (clear_async_event_handler): New declaration.
	* record-btrace.c (record_btrace_async): New function.
	(init_record_btrace_ops): Install record_btrace_async.
	* record-full.c (record_full_async): New function.
	(record_full_resume): Don't mark the async event source here.
	(init_record_full_ops): Install record_full_async.
	(record_full_core_resume): Don't mark the async event source here.
	(init_record_full_core_ops): Install record_full_async.
	* remote.c (remote_async): Mark and clear the async stop reply
	queue event-loop token as appropriate.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 140e2c62fd7a46b4500dbd442964543587c0337b on branch gdb-7.9-branch
@ 2015-02-17 12:43 sergiodj
  2015-02-17 15:26 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-17 12:43 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 140e2c62fd7a46b4500dbd442964543587c0337b ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.9-branch
Commit: 140e2c62fd7a46b4500dbd442964543587c0337b

Fix up some target is-async vs can-async confusions
In all these cases we're interested in whether the target is currently
async, with its event sources installed in the event loop, not whether
it can async if needed.  Also, I'm not seeing the point of the
target_async call from within linux_nat_wait.  That's normally done on
resume instead, which this target already does.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2015-02-17  Pedro Alves  <palves@redhat.com>

	* linux-nat.c (linux_child_follow_fork, linux_nat_wait_1): Use
	target_is_async_p instead of target_can_async.
	(linux_nat_wait): Use target_is_async_p instead of
	target_can_async.  Don't enable async here.
	* remote.c (interrupt_query, remote_wait, putpkt_binary): Use
	target_is_async_p instead of target_can_async.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 211e7f3c26b39159df2dedd8198148cec60307f9 on branch gdb-7.9-branch
@ 2015-02-11 17:07 sergiodj
  2015-02-11 17:15 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-11 17:07 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 211e7f3c26b39159df2dedd8198148cec60307f9 ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.9-branch
Commit: 211e7f3c26b39159df2dedd8198148cec60307f9

framefilter quit: New test
It definitely does not test all the RETURN_MASK_ERROR cases.  But it tests at
least two of them.

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

	* gdb.python/py-framefilter.exp (pagination quit - *): New tests.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit cf3f71d273c607ecd1e912ce9fe8121da320c6a9 on branch gdb-7.9-branch
@ 2015-02-11 16:34 sergiodj
  2015-02-11 16:52 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-11 16:34 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT cf3f71d273c607ecd1e912ce9fe8121da320c6a9 ***

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

framefilter quit: Use RETURN_MASK_ERROR
Now when the code is exception safe we can let RETURN_QUIT to pass through as
all the installed cleanups with handle that.

gdb/ChangeLog
2015-02-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* python/py-framefilter.c (py_print_single_arg, enumerate_locals)
	(py_print_frame): Use RETURN_MASK_ERROR.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 5dea9fe2285fee5d53691856750a0c8960fca04d on branch gdb-7.9-branch
@ 2015-02-11 15:42 sergiodj
  2015-02-11 15:45 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-11 15:42 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5dea9fe2285fee5d53691856750a0c8960fca04d ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.9-branch
Commit: 5dea9fe2285fee5d53691856750a0c8960fca04d

framefilter quit: Make it exception safe
gdb/ChangeLog
2015-02-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* python/py-framefilter.c (py_print_frame): Mention RETURN_QUIT in
	function comment.  Wrap all function that can throw in cleanups.
	(gdbpy_apply_frame_filter): Wrap all function that can throw in
	cleanups.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 46d020960241fcafd7d0ab483746a206829620ea on branch gdb-7.9-branch
@ 2015-02-11 15:19 sergiodj
  2015-02-11 15:26 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-11 15:19 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 46d020960241fcafd7d0ab483746a206829620ea ***

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

framefilter quit: Code cleanup: Avoid gotos
goto error patters are sometimes AFAIK used in C for the cases like:
	int retval=-1;
	if (!(a=malloc())) goto error;
	if (!(b=malloc())) goto error_a;
	if (!(c=malloc())) goto error_b;
	retval=0;
	error_c: free(c);
	error_b: free(b);
	error_a: free(a);
	error: return retval;

But here there is single error label with one do_cleanups() which I do not find
it worth the goto complication.  Without goto one can then furher merge code in
the exit paths in the next patches and ... after all it is all the same, just
without a goto.

gdb/ChangeLog
2015-02-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* python/py-framefilter.c (py_print_frame): Substitute goto error.
	Remove the error label.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit a9189a245363137825ce02a23202df45b04db179 on branch gdb-7.9-branch
@ 2015-02-11 14:32 sergiodj
  2015-02-11 14:52 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-11 14:32 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a9189a245363137825ce02a23202df45b04db179 ***

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

framefilter quit: Code cleanup: Reindentation
Nothing significant but I find code more clear with less deep indentation.

gdb/ChangeLog
2015-02-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* python/py-framefilter.c (py_print_frame): Put conditional code paths
	with goto first, indent the former else codepath left.  Put variable
	'elided' to a new inner block.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* Test results for commit 25a0672ba8b7f4badc682eaf08a1e342b496b483 on branch gdb-7.9-branch
@ 2015-02-11 14:04 sergiodj
  2015-02-11 14:07 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj @ 2015-02-11 14:04 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 25a0672ba8b7f4badc682eaf08a1e342b496b483 ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.9-branch
Commit: 25a0672ba8b7f4badc682eaf08a1e342b496b483

framefilter quit: Obvious whitespacing fixes
gdb/ChangeLog
2015-02-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* python/py-framefilter.c (py_print_frame): Whitespacing fixes.


^ permalink raw reply	[flat|nested] 35+ messages in thread
end of thread, other threads:[~2015-05-30  0:13 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-19 15:26 Test results for commit 3b41352824ddc32dabca2d3281a03b4a0b8c7a27 on branch gdb-7.9-branch sergiodj
2015-02-19 15:30 ` Failures on Fedora-ppc64be-cc-with-index, " sergiodj
2015-02-19 16:09 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj
2015-02-19 16:17 ` Failures on Fedora-ppc64be-m64, " sergiodj
2015-02-19 16:23 ` Failures on Fedora-x86_64-m32, " sergiodj
2015-02-19 16:32 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj
2015-02-19 16:46 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj
2015-02-19 17:07 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj
2015-02-19 17:07 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj
2015-02-19 17:09 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj
2015-02-19 17:16 ` Failures on Fedora-ppc64le-cc-with-index, " sergiodj
2015-02-19 17:29 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-19 18:05 ` Failures on Fedora-ppc64le-m64, " sergiodj
2015-02-19 20:39 ` Failures on Debian-i686, " sergiodj
2015-02-19 21:29 ` Failures on Debian-i686-native-gdbserver, " sergiodj
2015-02-20  0:14 ` Failures on Debian-x86_64-native-extended-gdbserver-m64, " sergiodj
2015-02-20  0:44 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj
  -- strict thread matches above, loose matches on Subject: below --
2015-05-29 17:52 [binutils-gdb/gdb-7.9-branch] PR gdb/18464: Do not crash on unrecognized GNU .note.ABI-tag values sergiodj+buildbot
2015-05-30  0:26 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
2015-04-29  6:16 [binutils-gdb/gdb-7.9-branch] PR python/18299 sergiodj+buildbot
2015-04-29 14:30 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
2015-03-21 11:59 [binutils-gdb/gdb-7.9-branch] Fix undefined behavior in TUI's TAB expansion sergiodj+buildbot
2015-03-21 14:33 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
2015-02-26 12:11 [binutils-gdb/gdb-7.9-branch] Remove // comment in gdb/iq2000-tdep.c sergiodj+buildbot
2015-02-26 13:07 ` Failures on Fedora-ppc64le-native-gdbserver-m64, branch gdb-7.9-branch sergiodj+buildbot
2015-02-20 19:31 Test results for commit c9ae55c9597064a8fe9a20899a17a394ac4ee3f8 on " sergiodj
2015-02-20 20:28 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-20  5:01 Test results for commit 7b582627bc42922de3b75792472f5223f1910277 on " sergiodj
2015-02-20  9:25 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-20  4:06 Test results for commit 3b7a39661610038aad32563069b10fb2cfc55fab on " sergiodj
2015-02-20  7:18 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-19 14:13 Test results for commit 77ef543e9e7861214232c63c960eddf19674cf61 on " sergiodj
2015-02-19 16:17 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-19 13:35 Test results for commit 90ca3b45da1c08eff31605b2af7cec9979a95bde on " sergiodj
2015-02-19 14:36 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-17 15:08 Test results for commit 5991bec1d4dbd23b476dc90bc6d1ba70e044898e on " sergiodj
2015-02-17 17:59 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-17 13:49 Test results for commit d4a0a1ff2b7f3d50180229768a270750ef94bbdf on " sergiodj
2015-02-17 16:28 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-17 12:43 Test results for commit 140e2c62fd7a46b4500dbd442964543587c0337b on " sergiodj
2015-02-17 15:26 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-11 17:07 Test results for commit 211e7f3c26b39159df2dedd8198148cec60307f9 on " sergiodj
2015-02-11 17:15 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-11 16:34 Test results for commit cf3f71d273c607ecd1e912ce9fe8121da320c6a9 on " sergiodj
2015-02-11 16:52 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-11 15:42 Test results for commit 5dea9fe2285fee5d53691856750a0c8960fca04d on " sergiodj
2015-02-11 15:45 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-11 15:19 Test results for commit 46d020960241fcafd7d0ab483746a206829620ea on " sergiodj
2015-02-11 15:26 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-11 14:32 Test results for commit a9189a245363137825ce02a23202df45b04db179 on " sergiodj
2015-02-11 14:52 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj
2015-02-11 14:04 Test results for commit 25a0672ba8b7f4badc682eaf08a1e342b496b483 on " sergiodj
2015-02-11 14:07 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj

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).