public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-7.10-branch] procfs.c: Include "filestuff.h"
@ 2015-08-21  8:52 sergiodj+buildbot
  2015-08-21  8:52 ` Failures on Fedora-i686, branch gdb-7.10-branch sergiodj+buildbot
                   ` (18 more replies)
  0 siblings, 19 replies; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-21  8:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 44d0cad3c4c67d21a50974bc8ef6d350ba32172d ***

Author: Marcin Cieslak <saper@saper.info>
Branch: gdb-7.10-branch
Commit: 44d0cad3c4c67d21a50974bc8ef6d350ba32172d

procfs.c: Include "filestuff.h"

Fixes implicit function declaration
error in gdb/procfs.c:4927 about undeclared
make_cleanup_close().

gdb/ChangeLog:

	PR build/18843
	* procfs.c: Include "filestuff.h".


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Bump GDB version number to 7.10.1.DATE-cvs.
@ 2015-12-05 15:56 sergiodj+buildbot
  2015-12-11 17:21 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-12-05 15:56 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 40dfe024f929c4d2e27c9e3ef1809751b4fc1c55 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: 40dfe024f929c4d2e27c9e3ef1809751b4fc1c55

Bump GDB version number to 7.10.1.DATE-cvs.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix several crashes of C++ demangler on fuzzed input.
@ 2015-11-28 21:54 sergiodj+buildbot
  2015-12-08  8:16 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 21:54 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT fde0a3e5490d784da5450aedceae764f014e54de ***

Author: Mikhail Maltsev <maltsevm@gmail.com>
Branch: gdb-7.10-branch
Commit: fde0a3e5490d784da5450aedceae764f014e54de

Fix several crashes of C++ demangler on fuzzed input.

libiberty/
	* cp-demangle.c (d_dump): Fix syntax error.
	(d_identifier): Adjust type of len to match d_source_name.
	(d_expression_1): Fix out-of-bounds access.  Check code variable for
	NULL before dereferencing it.
	(d_find_pack): Do not recurse for FIXED_TYPE, DEFAULT_ARG and NUMBER.
	(d_print_comp_inner): Add NULL pointer check.
	* cp-demangle.h (d_peek_next_char): Define as inline function when
	CHECK_DEMANGLER is defined.
	(d_advance): Likewise.
	* testsuite/demangle-expected: Add new testcases.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225727 138bc75d-0d04-0410-961f-82ee72b054a4


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Adjust GDB to demangler API change
@ 2015-11-28 21:16 sergiodj+buildbot
  2015-12-08 14:40 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 21:16 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 9a2752c7f09d24865b33fedd9ac2585f3cbba3c3 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 9a2752c7f09d24865b33fedd9ac2585f3cbba3c3

Adjust GDB to demangler API change

Before commit 3a8724032abf, DEMANGLE_COMPONENT_CAST was used for both
casts and conversion operators.  We now have
DEMANGLE_COMPONENT_CONVERSION for the latter.

gdb/ChangeLog:
2014-11-28  Pedro Alves  <palves@redhat.com>

	* cp-name-parser.y (conversion_op): Use
	DEMANGLE_COMPONENT_CONVERSION instead of DEMANGLE_COMPONENT_CAST.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters
@ 2015-11-28 20:37 sergiodj+buildbot
  2015-12-08 13:12 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 20:37 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 49037e4a1249890812a8d4995c7592774e99c399 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 49037e4a1249890812a8d4995c7592774e99c399

PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template<int> struct A {};
 template <typename Y> void function_temp(A<sizeof ((Y)(999))>) {}
 template void function_temp<int>(A<sizeof (int)>);

The 'function_temp<int>' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
    name 'function_temp'
    template argument list
      builtin type int
  function type
    builtin type void
    argument list
      template                          (*)
        name 'A'
        template argument list
          unary operator
            operator sizeof
            unary operator
              cast
                template parameter 0    (**)
              literal
                builtin type int
                name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
	       const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
      the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
     {
       dpt.next = dpi->templates;
       dpi->templates = &dpt;
       dpt.template_decl = dpi->current_template;
     }

when printing the template argument list of A (what should be "<sizeof
(int)>"), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template <typename U> explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int options,
        d_print_comp (dpi, options, dc->u.s_extended_operator.name);
        return;

     case DEMANGLE_COMPONENT_CAST:
       d_append_string (dpi, "operator ");
 -     d_print_cast (dpi, options, dc);
 +     d_print_conversion (dpi, options, dc);
       return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  <palves@redhat.com>

        PR other/61321
        PR other/61233
        * demangle.h (enum demangle_component_type)
        <DEMANGLE_COMPONENT_CONVERSION>: New value.
        * cp-demangle.c (d_demangle_callback, d_make_comp): Handle
        DEMANGLE_COMPONENT_CONVERSION.
        (is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
        instead of DEMANGLE_COMPONENT_CAST.
        (d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
        component if handling a conversion.
        (d_count_templates_scopes, d_print_comp_inner): Handle
        DEMANGLE_COMPONENT_CONVERSION.
        (d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
        of DEMANGLE_COMPONENT_CAST.
        (d_print_cast): Rename as ...
        (d_print_conversion): ... this.  Adjust comments.
        (d_print_cast): Rewrite - simply print the left subcomponent.
        * cp-demint.c (cplus_demangle_fill_component): Handle
        DEMANGLE_COMPONENT_CONVERSION.

        * testsuite/demangle-expected: Add tests.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231020 138bc75d-0d04-0410-961f-82ee72b054a4


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR remote/18965: vforkdone stop reply should indicate parent PID
@ 2015-09-15 18:09 sergiodj+buildbot
  2015-09-16  1:13 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-09-15 18:09 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 487bf2f7066948fffd3447a3c6dd83389a037e2d ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 487bf2f7066948fffd3447a3c6dd83389a037e2d

PR remote/18965: vforkdone stop reply should indicate parent PID

The vforkdone stop reply misses indicating the thread ID of the vfork
parent which the event relates to:

 @cindex vfork events, remote reply
 @item vfork
 The packet indicates that @code{vfork} was called, and @var{r}
 is the thread ID of the new child process. Refer to
 @ref{thread-id syntax} for the format of the @var{thread-id}
 field.  This packet is only applicable to targets that support
 vfork events.

 @cindex vforkdone events, remote reply
 @item vforkdone
 The packet indicates that a child process created by a vfork
 has either called @code{exec} or terminated, so that the
 address spaces of the parent and child process are no longer
 shared. The @var{r} part is ignored.  This packet is only
 applicable to targets that support vforkdone events.

Unfortunately, this is not just a documentation issue.  GDBserver
is really not specifying the thread ID.  I noticed because
in non-stop mode, gdb complains:

 [Thread 6089.6089] #1 stopped.
 #0  0x0000003615a011f0 in ?? ()
 0x0000003615a011f0 in ?? ()
 (gdb) set debug remote 1
 (gdb) c
 Continuing.
 Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK
 Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
   Notification received: Stop:T05vfork:p17ce.17ce;06:40d7ffffff7f0000;07:30d7ffffff7f0000;10:e4c9eb1536000000;thread:p17c9.17c9;core:2;
 Sending packet: $vStopped#55...Packet received: OK
 Sending packet: $D;17ce#af...Packet received: OK
 Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
   Notification received: Stop:T05vforkdone:;
 No process or thread specified in stop reply: T05vforkdone:;
 (gdb)

This is not non-stop-mode-specific, however.  Consider e.g., that in
all-stop, you may be debugging more than one process at the same time.
You continue, and both processes vfork.  So when you next get a
T05vforkdone, there's no way to tell which of the parent processes is
done with the vfork.

Tests will be added later.

Tested on x86_64 Fedora 20.

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

	PR remote/18965
	* remote-utils.c (prepare_resume_reply): Merge
	TARGET_WAITKIND_VFORK_DONE switch case with the
	TARGET_WAITKIND_FORKED case.

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

	PR remote/18965
	* gdb.texinfo (Stop Reply Packets): Explain that vforkdone's 'r'
	part indicates the thread ID of the parent process.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix build issue with nat/linux-namespaces.c
@ 2015-09-14 11:29 sergiodj+buildbot
  2015-09-14 12:40 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-09-14 11:29 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a8c636cb54328fb9a71dcf27b66a7e7ab5443d88 ***

Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: a8c636cb54328fb9a71dcf27b66a7e7ab5443d88

Fix build issue with nat/linux-namespaces.c

This commit fixes a build issue on systems with a prototype for setns
in their header files but no working setns is detected by configure.

gdb/ChangeLog:

	PR gdb/18957
	* nat/linux-namespaces.c (setns): Rename from this ...
	(do_setns): ... to this.  Support calling setns if it exists.
	(mnsh_handle_setns): Call do_setns.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10"
@ 2015-08-28 21:40 sergiodj+buildbot
  2015-08-28 22:26 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-28 21:40 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3c2ae1bb39c2c60a7b1cd5ce75c9816fab45cea4 ***

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

gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10"

This is in preparation for the GDB 7.10 release.

gdb/ChangeLog:

        * NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10".


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] remote: allow aborting long operations (e.g., file transfers)
@ 2015-08-25 18:44 sergiodj+buildbot
  2015-08-26 17:07 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-25 18:44 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 026ca0231ae6dcc107ec496ed677bd1b00474a2f ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 026ca0231ae6dcc107ec496ed677bd1b00474a2f

remote: allow aborting long operations (e.g., file transfers)

Currently, when remote debugging, if you type Ctrl-C just while the
target stopped for an internal event, and GDB is busy doing something
that takes a while (e.g., fetching chunks of a shared library off of
the target, with vFile, to process ELF headers and debug info), the
Ctrl-C is lost.

The patch hooks up the QUIT macro to a new target method that lets the
target react to the double-Ctrl-C before the event loop is reached,
which allows reacting to a double-Ctrl-C even when GDB is busy doing
some long operation and not waiting for a stop reply.  That end result
is:

 (gdb) c
 Continuing.
 ^C
 ^C
 Interrupted while waiting for the program.
 Give up waiting? (y or n) y
 Quit
 (gdb) info threads
   Id   Target Id         Frame
 * 1    Thread 11673      0x00007ffff7deb240 in _dl_debug_state () from target:/lib64/ld-linux-x86-64.so.2
 (gdb)

If, however, GDB is waiting for a stop reply (because the target has
been resumed, with e.g., vCont;c), but the target isn't responding, we
now get:

 (gdb) c
 Continuing.
 ^C
 ^C
 The target is not responding to interrupt requests.
 Stop debugging it? (y or n) y
 Disconnected from target.
 (gdb) info threads
 No threads.

This offers to disconnect, because when we're waiting for a stop
reply, there's nothing else we can send the target other than an
interrupt request.  And if that doesn't work, there's nothing else we
can do.

The Ctrl-C is presently lost because until we get to a user-visible
stop, the SIGINT handler that is installed is the one that forwards
the interrupt to the remote side, with the \003 "packet" [1].  But,
gdbserver ignores an interrupt request if the program is stopped.
Still, even if it didn't, the server can only report back a
stop-because-of-SIGINT when the program is next resumed.  And it may
take a while to actually re-resume the target.

[1] - In the old sync days, the remote target would react to a
double-Ctrl-C by asking users whether they wanted to give up waiting
and disconnect.  The code is still there, but it it isn't reacheable
on most hosts, which support serial connections in async mode
(probably only DJGPP doesn't).  Even then, in sync mode, remote.c's
SIGINT handler is only installed while the target is resumed, and is
removed as soon as the target sends back a stop reply.  That means
that a Ctrl-C just while GDB is processing an internal event can end
up with an odd "Quit" at the prompt instead of "Program stopped by
SIGINT".  In contrast, in async mode, remote.c's SIGINT handler is set
up as long as target_terminal_inferior or
target_terminal_ours_for_output are in effect (IOW, until we get a
user-visible stop and call target_terminal_ours), so the user
shouldn't get back a spurious Quit.  However, it's still desirable to
be able to interrupt a long-running GDB operation, if GDB takes a
while to re-resume the target or get back to the event loop.

Tested on x86_64 Fedora 20.

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

	PR gdb/18804
	* defs.h (maybe_quit): Declare.
	(QUIT): Now calls maybe_quit.
	* event-loop.c (clear_async_signal_handler)
	(async_signal_handler_is_marked): New functions.
	* event-loop.h (async_signal_handler_is_marked)
	(clear_async_signal_handler): New declarations.
	* remote.c (remote_check_pending_interrupt): New function.
	(interrupt_query): Use make_cleanup_restore_target_terminal.  No
	longer check whether the target is async.  If waiting for a stop
	reply, and a Ctrl-C as been sent to the target, offer to
	disconnect, and throw TARGET_CLOSE_ERROR instead of a quit.
	Otherwise do not disconnect and throw a quit.
	(_initialize_remote): Install remote_check_pending_interrupt as
	to_check_pending_interrupt.
	* target.c (target_check_pending_interrupt): New function.
	* target.h (struct target_ops) <to_check_pending_interrupt>: New
	field.
	(target_check_pending_interrupt): New declaration.
	* utils.c (maybe_quit): New function.
	* target-delegates.c: Regenerate.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Make remote file transfers interruptible
@ 2015-08-21 18:24 sergiodj+buildbot
  2015-08-22  3:30 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 18:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ecc06bd425d6fcbb994b7b4d1d6f3c6f705e0784 ***

Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: ecc06bd425d6fcbb994b7b4d1d6f3c6f705e0784

Make remote file transfers interruptible

This commit makes it possible to interrupt remote file transfers.

gdb/ChangeLog:

	* gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Warn when accessing binaries from remote targets
@ 2015-08-21 17:54 sergiodj+buildbot
  2015-08-22  1:39 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 17:54 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 290f582b49a81b7fa01fc430bad1a7f9af21c922 ***

Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: 290f582b49a81b7fa01fc430bad1a7f9af21c922

Warn when accessing binaries from remote targets

GDB provides no indicator of progress during file operations, and can
appear to have locked up during slow remote transfers.  This commit
updates GDB to print a warning each time a file is accessed over RSP.
An additional message detailing how to avoid remote transfers is
printed for the first transfer only.

gdb/ChangeLog:

	* target.h (struct target_ops) <to_fileio_open>: New argument
	warn_if_slow.  Update comment.  All implementations updated.
	(target_fileio_open_warn_if_slow): New declaration.
	* target.c (target_fileio_open): Renamed as...
	(target_fileio_open_1): ...this.  New argument warn_if_slow.
	Pass warn_if_slow to implementation.  Update debug printing.
	(target_fileio_open): New function.
	(target_fileio_open_warn_if_slow): Likewise.
	* gdb_bfd.c (gdb_bfd_iovec_fileio_open): Use new function
	target_fileio_open_warn_if_slow.

gdb/testsuite/ChangeLog:

	* gdb.trace/pending.exp: Cope with remote transfer warnings.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Prelimit number of bytes to read in "vFile:pread:"
@ 2015-08-19 13:35 sergiodj+buildbot
  2015-08-19 15:42 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-19 13:35 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5e83dd6fb19ba25a89e321a0eb1373b3d3fc3930 ***

Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: 5e83dd6fb19ba25a89e321a0eb1373b3d3fc3930

Prelimit number of bytes to read in "vFile:pread:"

While handling "vFile:pread:" packets, gdbserver would read the
number of bytes requested regardless of whether this would fit
into the reply packet.  gdbserver would then return a packet's
worth of data and discard the remainder.  When accessing large
binaries GDB (via BFD) routinely makes large "vFile:pread:"
requests, resulting in gdbserver allocating large unnecessary
buffers and reading some portions of the file many times over.

This commit causes gdbserver to limit the number of bytes to be
read to a sensible maximum prior to allocating buffers and reading
data.

gdb/gdbserver/ChangeLog:

	* hostio.c (handle_pread): Do not attempt to read more data
	than hostio_reply_with_data can fit in a packet.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR python/17136
@ 2015-08-06 17:47 sergiodj+buildbot
  2015-08-07 16:00 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 17:47 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 17d1595ac5371d06537bc57df86a9f7359e62127 ***

Author: Clem Dickey <clemd@acm.org>
Branch: gdb-7.10-branch
Commit: 17d1595ac5371d06537bc57df86a9f7359e62127

PR python/17136
gdb/ChangeLog:

	* python/lib/gdb/command/type_printers.py (InfoTypePrinter): Fix typo.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix gdbserver --debug issues caught by Valgrind
@ 2015-08-06 14:49 sergiodj+buildbot
  2015-08-07  4:45 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 14:49 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 4ede28ca86b7206859a965cfaf2b13236f2de752 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 4ede28ca86b7206859a965cfaf2b13236f2de752

Fix gdbserver --debug issues caught by Valgrind
Running gdbserver --debug under Valgrind shows:

 ==4803== Invalid read of size 4
 ==4803==    at 0x432B62: linux_write_memory (linux-low.c:5320)
 ==4803==    by 0x4143F7: write_inferior_memory (target.c:83)
 ==4803==    by 0x415895: remove_memory_breakpoint (mem-break.c:362)
 ==4803==    by 0x432EF5: linux_remove_point (linux-low.c:5460)
 ==4803==    by 0x416319: delete_raw_breakpoint (mem-break.c:802)
 ==4803==    by 0x4163F3: release_breakpoint (mem-break.c:842)
 ==4803==    by 0x416477: delete_breakpoint_1 (mem-break.c:869)
 ==4803==    by 0x4164EF: delete_breakpoint (mem-break.c:891)
 ==4803==    by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
 ==4803==    by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
 ==4803==    by 0x4134E3: process_serial_event (server.c:4051)
 ==4803==    by 0x4138E4: handle_serial_event (server.c:4196)
 ==4803==  Address 0x4c6b930 is 0 bytes inside a block of size 1 alloc'd
 ==4803==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 ==4803==    by 0x4240C6: xmalloc (common-utils.c:43)
 ==4803==    by 0x41439C: write_inferior_memory (target.c:80)
 ==4803==    by 0x415895: remove_memory_breakpoint (mem-break.c:362)
 ==4803==    by 0x432EF5: linux_remove_point (linux-low.c:5460)
 ==4803==    by 0x416319: delete_raw_breakpoint (mem-break.c:802)
 ==4803==    by 0x4163F3: release_breakpoint (mem-break.c:842)
 ==4803==    by 0x416477: delete_breakpoint_1 (mem-break.c:869)
 ==4803==    by 0x4164EF: delete_breakpoint (mem-break.c:891)
 ==4803==    by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
 ==4803==    by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
 ==4803==    by 0x4134E3: process_serial_event (server.c:4051)
 ==4803==

And:

 ==7272== Conditional jump or move depends on uninitialised value(s)
 ==7272==    at 0x3615E48361: vfprintf (vfprintf.c:1634)
 ==7272==    by 0x414E89: debug_vprintf (debug.c:60)
 ==7272==    by 0x42800A: debug_printf (common-debug.c:35)
 ==7272==    by 0x43937B: my_waitpid (linux-waitpid.c:149)
 ==7272==    by 0x42D740: linux_wait_for_event_filtered (linux-low.c:2441)
 ==7272==    by 0x42DADA: linux_wait_for_event (linux-low.c:2552)
 ==7272==    by 0x42E165: linux_wait_1 (linux-low.c:2860)
 ==7272==    by 0x42F5D8: linux_wait (linux-low.c:3453)
 ==7272==    by 0x4144A4: mywait (target.c:107)
 ==7272==    by 0x413969: handle_target_event (server.c:4214)
 ==7272==    by 0x41A1A6: handle_file_event (event-loop.c:429)
 ==7272==    by 0x41996D: process_event (event-loop.c:184)

gdb/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

	* nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid
	returned > 0.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

	* linux-low.c (linux_write_memory): Rewrite debug output to avoid
	reading beyond the passed in buffer length.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] stepping is disturbed by setjmp/longjmp | try/catch in other threads
@ 2015-08-05 19:50 sergiodj+buildbot
  2015-08-05 23:05 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-05 19:50 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ad90a3f54869130ed7bada84e5bf6e71bd3a0c35 ***

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

stepping is disturbed by setjmp/longjmp | try/catch in other threads
At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel
observed that trying to next/step a program on GNU/Linux sometimes
results in the following failed assertion:

	% gdb -q .obj/gprof/main
    (gdb) start
    (gdb) n
    (gdb) step
    [...]/infrun.c:2391: internal-error:
    resume: Assertion `sig != GDB_SIGNAL_0' failed.

What happened is that, during the "next" operation, GDB hit a
longjmp/exception/step-resume breakpoint but failed to see that this
breakpoint was set for a different thread than the one being stepped.

Joel's detailed analysis follows:

More precisely, at the end of the "start" command, we are stopped at
the start of function Main in main.adb; there are 4 threads in total,
and we are in the main thread (which is thread 1):

    (gdb) info thread
      Id   Target Id         Frame
      4    Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall ()
      3    Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall ()
      2    Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall ()
    * 1    Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57

All the logs below reference Thread ID/LWP, but it'll be easier to
talk about the threads by GDB thread number.  For instance, thread 1
is LWP 28370 while thread 3 is LWP 28378.  So, the explanations below
translate the LWPs into thread numbers.

Back to what happens while we are trying to "next' our program:
    (gdb) n
    infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379))
    infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378))
    infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377))
    infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370))
    infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x8054523

We've resumed thread 1 (LWP 28370), and received in return a signal
that the same thread stopped slightly further.  It's still in the
range of instructions for the line of source we started the "next"
from, as evidenced by the following trace...

    infrun: stepping inside range [0x805451e-0x8054531]

... and thus, we decide to continue stepping the same thread:

    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
    infrun: prepare_to_wait

That's when we get an event from a different thread (thread 3)...

    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x80782d0
    infrun: context switch
    infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)

... which we find to be at the address where we set a breakpoint on
"the unwinder debug hook" (namely "_Unwind_DebugHook").  But GDB fails
to notice that the breakpoint was inserted for thread 1 only, and so
decides to handle it as...

    infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME

... and inserts a breakpoint at the corresponding resume address, as
evidenced by this the next log:

    infrun: exception resume at 80542a2

That breakpoint seems innocent right now, but will play a role fairly
quickly.  But for now, GDB has inserted the exception-resume
breakpoint, and needs to single-step thread 3 past the breakpoint it
just hit.  Thus, it temporarily disables the exception breakpoint, and
requests a step of that thread:

    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0
    infrun: prepare_to_wait

We then get a notification, still from thread 3, that it's now past
that breakpoint...

    infrun: prepare_to_wait
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x8078424

... so we can resume what we were doing before, which is single-stepping
thread 1 until we get to a new line of code:

    infrun: switching back to stepped thread
    infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370)
    infrun: expected thread still hasn't advanced
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523

The "resume" log above shows that we're resuming thread 1 from where
we left off (0x8054523).  We get one more stop at 0x8054529, which is
still inside our stepping range so we go again.  That's when we get
the following event, from thread 3:

    infrun: prepare_to_wait
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x80542a2

Now the stop_pc address is interesting, because it's the address of
"exception resume" breakpoint...

    infrun: context switch
    infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)
    infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME

... and since that location is at a different line of code, this is
where it decides the "next" operation should stop:

    infrun: stop_waiting
    [Switching to Thread 0xb7c5aba0 (LWP 28378)]
    0x080542a2 in inte_tache_rt.ttache_rt (
        <_task>=0x80968ec <inte_tache_rt_inst.tache2>)
        at /[...]/inte_tache_rt.adb:54
    54            end loop;

However, what GDB should have noticed earlier that the exception
breakpoint we hit was for a different thread, thus should have
single-stepped that thread out of the breakpoint _without_ inserting
the exception-return breakpoint, and then resumed the single-stepping
of the initial thread (thread 1) until that thread stepped out of its
stepping range.

This is what this patch does, and after applying it, GDB now correctly
stops on the next line of code.

The patch adds a C++ test that exercises this, both for setjmp/longjmp
and exception breakpoints.  With an unpatched GDB it shows:

 (gdb) next
 [Switching to Thread 22445.22455]
 thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59
 59            catch (...)
 (gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1
 next
 /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa
 iled.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error)
 Resyncing due to internal error.
 n

Tested on x86_64-linux, no regressions.

gdb/ChangeLog:
2015-08-05  Pedro Alves  <palves@redhat.com>
	    Joel Brobecker  <brobecker@adacore.com>

        * breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy>
	<bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the
	case where BS->STOP is not set.

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

	* gdb.threads/next-while-other-thread-longjmps.c: New file.
	* gdb.threads/next-while-other-thread-longjmps.exp: New file.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Check for asprintf and vasprintf during configure stage.
@ 2015-08-05  7:33 sergiodj+buildbot
  2015-08-05 13:26 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-08-05  7:33 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a03bd1099151e16a07b3a9b3846a28bdef1ba686 ***

Author: Iain Buclaw <ibuclaw@gdcproject.org>
Branch: gdb-7.10-branch
Commit: a03bd1099151e16a07b3a9b3846a28bdef1ba686

Check for asprintf and vasprintf during configure stage.
This should fix some build errors seen on AIX, MinGW, and possibly other
non-GNU systems too due to missing asprintf().

bfd/

	* configure.in: Add asprintf and vasprintf to AC_CHECK_DECLS.
	* config.in, configure: Regenerate.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] remote follow fork and spurious child stops in non-stop mode
@ 2015-07-30 20:35 sergiodj+buildbot
  2015-08-03 16:10 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-07-30 20:35 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 4ccc18f16da05e93aff0c7ac570017d5ef79ef6c ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 4ccc18f16da05e93aff0c7ac570017d5ef79ef6c

remote follow fork and spurious child stops in non-stop mode
Running gdb.threads/fork-plus-threads.exp against gdbserver in
extended-remote mode, even though the test passes, we still see broken
behavior:

 (gdb) PASS: gdb.threads/fork-plus-threads.exp: set detach-on-fork off
 continue &
 Continuing.
 (gdb) PASS: gdb.threads/fork-plus-threads.exp: continue &
 [New Thread 28092.28092]

 [Thread 28092.28092] #2 stopped.
 [New Thread 28094.28094]
 [Inferior 2 (process 28092) exited normally]
 [New Thread 28094.28105]
 [New Thread 28094.28109]

...

[Thread 28174.28174] #18 stopped.
 [New Thread 28185.28185]
 [Inferior 10 (process 28174) exited normally]
 [New Thread 28185.28196]

 [Thread 28185.28185] #20 stopped.
 Cannot remove breakpoints because program is no longer writable.
 Further execution is probably impossible.
 [Inferior 11 (process 28185) exited normally]
 [Inferior 1 (process 28091) exited normally]
 PASS: gdb.threads/fork-plus-threads.exp: reached breakpoint
 info threads
 No threads.
 (gdb) PASS: gdb.threads/fork-plus-threads.exp: no threads left
 info inferiors
   Num  Description       Executable
 * 1    <null>            /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/fork-plus-threads
 (gdb) PASS: gdb.threads/fork-plus-threads.exp: only inferior 1 left

All the "[Thread FOO] #NN stopped." above are bogus, as well as the
"Cannot remove breakpoints because program is no longer writable.",
which is a consequence.

The problem is that when we intercept a fork event, we should report
the event for the parent, only, and leave the child stopped, but not
report its stop event.  GDB later decides whether to follow the parent
or the child.  But because handle_extended_wait does not set the
child's last_status.kind to TARGET_WAITKIND_STOPPED, a
stop_all_threads/unstop_all_lwps sequence (e.g., from trying to access
memory) by mistake ends up queueing a SIGSTOP on the child, resuming
it, and then when that SIGSTOP is intercepted, because the LWP has
last_resume_kind set to resume_stop, gdbserver reports the stop to
GDB, as GDB_SIGNAL_0:

...
 >>>> entering unstop_all_lwps
 unstopping all lwps
 proceed_one_lwp: lwp 1600
    client wants LWP to remain 1600 stopped
 proceed_one_lwp: lwp 1828
 Client wants LWP 1828 to stop. Making sure it has a SIGSTOP pending
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Sending sigstop to lwp 1828
 pc is 0x3615ebc7cc
 Resuming lwp 1828 (continue, signal 0, stop expected)
   continue from pc 0x3615ebc7cc
 unstop_all_lwps done
 sigchld_handler
 <<<< exiting unstop_all_lwps
 handling possible target event
 >>>> entering linux_wait_1
 linux_wait_1: [<all threads>]
 my_waitpid (-1, 0x40000001)
 my_waitpid (-1, 0x1): status(137f), 1828
 LWFE: waitpid(-1, ...) returned 1828, ERRNO-OK
 LLW: waitpid 1828 received Stopped (signal) (stopped)
 pc is 0x3615ebc7cc
 Expected stop.
 LLW: resume_stop SIGSTOP caught for LWP 1828.1828.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
 linux_wait_1 ret = LWP 1828.1828, 1, 0
 <<<< exiting linux_wait_1
 Writing resume reply for LWP 1828.1828:1
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Tested on x86_64 Fedora 20, extended-remote.

gdb/gdbserver/ChangeLog:
2015-07-30  Pedro Alves  <palves@redhat.com>

	* linux-low.c (handle_extended_wait): Set the child's last
	reported status to TARGET_WAITKIND_STOPPED.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] compile: Warn for old GCC on cv-qualified self-reference
@ 2015-07-08 13:27 sergiodj+buildbot
  2015-07-08 17:12 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 13:27 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 91affdd27ee8e244df417686ead2b546ee1449bf ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.10-branch
Commit: 91affdd27ee8e244df417686ead2b546ee1449bf

compile: Warn for old GCC on cv-qualified self-reference
GDB could:

compile code struct_object.selffield = &struct_object
./compile/compile-c-types.c:83: internal-error: insert_type: Assertion `add == NULL || add->gcc_type == gcc_type' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield = &struct_object (GDB internal
error)

The bug was not in GDB but in the GCC part interfacing with GDB.

Alexandre Oliva has fixed it the right way:
	https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=072dfdba0ea62abb65514cb3a90cdf3868efe286
	git://gcc.gnu.org/git/gcc.git
	aoliva/libcp1

Attaching this GDB testsuite update + info to user s/he should upgrade GCC.
After Alex upstreams the fix I can update the message to contain the specific
GCC release.

gdb/ChangeLog
2015-07-08  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR compile/18484
	* compile/compile-c-types.c (insert_type): Change gdb_assert to error.

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

	PR compile/18484
	* gdb.compile/compile.c (struct struct_type): Add volatile to
	selffield's type.
	* gdb.compile/compile.exp
	(compile code struct_object.selffield = &struct_object): Skip further
	struct_object tests if this one xfails.


^ permalink raw reply	[flat|nested] 38+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions
@ 2015-07-08 10:51 sergiodj+buildbot
  2015-07-08 13:58 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 38+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 10:51 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT cc1259417e727c47e58cea1bb4a148974689ad8e ***

Author: Robert O'Callahan <robert@ocallahan.org>
Branch: gdb-7.10-branch
Commit: cc1259417e727c47e58cea1bb4a148974689ad8e

PR18617 - Incorrect expression bytecode generated for narrowing conversions
The existing code preserves 'from' bits, which is incorrect.  E.g.

 (gdb) maint agent-eval (char)255L
 Scope: 0x4008d6
 Reg mask: 00
   0  const16 255
   3  ext 64
   5  end

'ext 64' should be 'ext 8'; this bytecode evaluates to 255 instead of
the correct result of -1.  The fix is simple.  I ran the entire test
suite on x86-64 and there were no new test failures.

gdb/ChangeLog:
2015-07-08  Robert O'Callahan  <robert@ocallahan.org>

	PR exp/18617
	* ax-gdb.c (gen_conversion): Extend to 'to' bits, not 'from'.

gdb/testsuite/ChangeLog:
2015-07-08  Robert O'Callahan  <robert@ocallahan.org>

	PR exp/18617
	* gdb.trace/ax.exp: Add test.


^ permalink raw reply	[flat|nested] 38+ messages in thread
end of thread, other threads:[~2015-12-11 17:07 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-21  8:52 [binutils-gdb/gdb-7.10-branch] procfs.c: Include "filestuff.h" sergiodj+buildbot
2015-08-21  8:52 ` Failures on Fedora-i686, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21  9:03 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2015-08-21  9:07 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2015-08-21  9:08 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot
2015-08-21  9:09 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-21  9:12 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2015-08-21  9:17 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2015-08-21  9:31 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-21  9:42 ` Failures on RHEL-s390x-m64, " sergiodj+buildbot
2015-08-21  9:52 ` Failures on Fedora-ppc64be-cc-with-index, " sergiodj+buildbot
2015-08-21 10:11 ` Failures on Fedora-ppc64be-m64, " sergiodj+buildbot
2015-08-21 10:28 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj+buildbot
2015-08-21 10:36 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-21 10:49 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot
2015-08-21 10:49 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-21 10:57 ` Failures on Fedora-ppc64le-cc-with-index, " sergiodj+buildbot
2015-08-21 11:12 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot
2015-08-21 11:26 ` Failures on Debian-x86_64-m64, " sergiodj+buildbot
2015-08-21 11:53 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot
  -- strict thread matches above, loose matches on Subject: below --
2015-12-05 15:56 [binutils-gdb/gdb-7.10-branch] Bump GDB version number to 7.10.1.DATE-cvs sergiodj+buildbot
2015-12-11 17:21 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 21:54 [binutils-gdb/gdb-7.10-branch] Fix several crashes of C++ demangler on fuzzed input sergiodj+buildbot
2015-12-08  8:16 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 21:16 [binutils-gdb/gdb-7.10-branch] Adjust GDB to demangler API change sergiodj+buildbot
2015-12-08 14:40 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 20:37 [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters sergiodj+buildbot
2015-12-08 13:12 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-09-15 18:09 [binutils-gdb/gdb-7.10-branch] PR remote/18965: vforkdone stop reply should indicate parent PID sergiodj+buildbot
2015-09-16  1:13 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-09-14 11:29 [binutils-gdb/gdb-7.10-branch] Fix build issue with nat/linux-namespaces.c sergiodj+buildbot
2015-09-14 12:40 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-28 21:40 [binutils-gdb/gdb-7.10-branch] gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10" sergiodj+buildbot
2015-08-28 22:26 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-25 18:44 [binutils-gdb/gdb-7.10-branch] remote: allow aborting long operations (e.g., file transfers) sergiodj+buildbot
2015-08-26 17:07 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 18:24 [binutils-gdb/gdb-7.10-branch] Make remote file transfers interruptible sergiodj+buildbot
2015-08-22  3:30 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 17:54 [binutils-gdb/gdb-7.10-branch] Warn when accessing binaries from remote targets sergiodj+buildbot
2015-08-22  1:39 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-19 13:35 [binutils-gdb/gdb-7.10-branch] Prelimit number of bytes to read in "vFile:pread:" sergiodj+buildbot
2015-08-19 15:42 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 17:47 [binutils-gdb/gdb-7.10-branch] PR python/17136 sergiodj+buildbot
2015-08-07 16:00 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 14:49 [binutils-gdb/gdb-7.10-branch] Fix gdbserver --debug issues caught by Valgrind sergiodj+buildbot
2015-08-07  4:45 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-05 19:50 [binutils-gdb/gdb-7.10-branch] stepping is disturbed by setjmp/longjmp | try/catch in other threads sergiodj+buildbot
2015-08-05 23:05 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-08-05  7:33 [binutils-gdb/gdb-7.10-branch] Check for asprintf and vasprintf during configure stage sergiodj+buildbot
2015-08-05 13:26 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-07-30 20:35 [binutils-gdb/gdb-7.10-branch] remote follow fork and spurious child stops in non-stop mode sergiodj+buildbot
2015-08-03 16:10 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-07-08 13:27 [binutils-gdb/gdb-7.10-branch] compile: Warn for old GCC on cv-qualified self-reference sergiodj+buildbot
2015-07-08 17:12 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-branch sergiodj+buildbot
2015-07-08 10:51 [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions sergiodj+buildbot
2015-07-08 13:58 ` Failures on Fedora-ppc64le-cc-with-index, branch gdb-7.10-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).