public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-7.10-branch] Fix testsuite regression by: Do not skip prologue for asm (.S) files
@ 2015-07-10 13:58 sergiodj+buildbot
  2015-07-10 13:58 ` Failures on AIX-POWER7-plain, branch gdb-7.10-branch sergiodj+buildbot
                   ` (21 more replies)
  0 siblings, 22 replies; 37+ messages in thread
From: sergiodj+buildbot @ 2015-07-10 13:58 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 8746ea769d67bf186d582d892cf37da42bc95ea9 ***

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

Fix testsuite regression by: Do not skip prologue for asm (.S) files
I have somehow missed gdb.asm/asm-source.exp PASS->FAIL even on x86_64.

It has no longer valid assumption that "break" breaks after the prologue even
in assembler.  So I have changed this assumption of the testfile.

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

	* gdb.asm/asm-source.exp (f at main): Stop at gdbasm_enter.
	(n at main): New.
	* gdb.asm/asmsrc1.s: Add comment "mark: main enter".


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] record: set stop_pc in "record goto" command
@ 2015-07-14  7:24 sergiodj+buildbot
  2015-07-14  7:32 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-07-14  7:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 0900c4cec7f75a00cccb3537d754c20f99096686 ***

Author: Markus Metzger <markus.t.metzger@intel.com>
Branch: gdb-7.10-branch
Commit: 0900c4cec7f75a00cccb3537d754c20f99096686

record: set stop_pc in "record goto" command
When navigating in the recorded execution trace via "record goto", we do not
set stop_pc.  This may trigger an internal error in infrun.c when stepping
from that location.  Set it.

(gdb) rec full
(gdb) c
Continuing.

Breakpoint 1, foo (void) at foo.c:42
42             x = y
(gdb) rn
foo (void)
    at foo.c:41
41             y = x
(gdb) rec go end
Go forward to insn number 98724
    at foo.c:42
42             x = y
(gdb) n
infrun.c:2382: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

This happens because there's a breakpoint at PC when the "next"
is issued, so that breapoint should be immediately stepped over.
That should have been detected/done by proceed, here:

  if (addr == (CORE_ADDR) -1)
    {
      if (pc == stop_pc
	  && breakpoint_here_p (aspace, pc) == ordinary_breakpoint_here
	  && execution_direction != EXEC_REVERSE)
	/* There is a breakpoint at the address we will resume at,
	   step one instruction before inserting breakpoints so that
	   we do not stop right away (and report a second hit at this
	   breakpoint).

	   Note, we don't do this in reverse, because we won't
	   actually be executing the breakpoint insn anyway.
	   We'll be (un-)executing the previous instruction.  */
	tp->stepping_over_breakpoint = 1;

But since stop_pc was stale, the pc == stop_pc check failed, and left the
breakpont at PC inserted.

gdb/
	* record-btrace.c (record_btrace_goto_begin, record_btrace_goto_end)
	record_btrace_goto): Move call to print_stack_frame ...
	(record_btrace_set_replay): ... here.  Set stop_pc.
	* record-full.c (record_full_goto_entry): Set stop_pc.

testsuite/
	* gdb.btrace/record_goto-step.exp: New.


^ permalink raw reply	[flat|nested] 37+ 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-07-30 20:44 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ 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] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR gdb/17960 Internal error: tracker != NULL when completing on file:function
@ 2015-08-10 20:46 sergiodj+buildbot
  2015-08-10 20:55 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-10 20:46 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3649abf39ee70a6237a06df85cf027dcc0d03c56 ***

Author: Doug Evans <dje@google.com>
Branch: gdb-7.10-branch
Commit: 3649abf39ee70a6237a06df85cf027dcc0d03c56

PR gdb/17960 Internal error: tracker != NULL when completing on file:function

gdb/ChangeLog:

	* symtab.c (make_file_symbol_completion_list_1): Renamed from
	make_file_symbol_completion_list and made static.
	(make_file_symbol_completion_list): New function.

gdb/testsuite/ChangeLog:

	* gdb.base/completion.exp: Add location completer tests.


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] [regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint
@ 2015-08-12  9:20 sergiodj+buildbot
  2015-08-12 10:31 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-12  9:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 835001623351330d49678d215d1338c0ce35c1f9 ***

Author: Luis Machado <lgustavo@codesourcery.com>
Branch: gdb-7.10-branch
Commit: 835001623351330d49678d215d1338c0ce35c1f9

[regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint

While running bare-metal tests with GDB i noticed some failures in
gdb.base/break.exp, related to the use of the catch commands.

It turns out GDB tries to access memory address 0x0 whenever one tries
to insert a catchpoint, which should obviously not happen.

This was introduced with the changes for permanent breakpoints. In special,
bp_loc_is_permanent tries to check if there is a breakpoint inserted at
the same address as the current breakpoint's location's address. In the
case of catchpoints, this is 0x0.

(top-gdb) catch fork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 4 (fork)

(top-gdb) catch vfork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 5 (vfork)

It is not obvious to detect because this fails silently for Linux. For our
bare-metal testing, though, this fails with a clear error message from the
target about not being able to read such address.

The attached patch addresses this by bailing out of bp_loc_is_permanent (...)
if the location address is not meaningful. I also took the opportunity to
update the comment for breakpoint_address_is_meaningful, which mentioned
breakpoint addresses as opposed to their locations' addresses.

gdb/ChangeLog:

2015-08-11  Luis Machado  <lgustavo@codesourcery.com>

	* breakpoint.c (bp_loc_is_permanent): Return 0 when breakpoint
	location address is not meaningful.
	(breakpoint_address_is_meaningful): Update comment.


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp sometimes broken
@ 2015-08-13 19:48 sergiodj+buildbot
  2015-08-13 20:19 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-13 19:48 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 01653c39b80c69ae02396f16cc3306ab8eb8ace0 ***

Author: Keith Seitz <keiths@redhat.com>
Branch: gdb-7.10-branch
Commit: 01653c39b80c69ae02396f16cc3306ab8eb8ace0

gdb.base/dso2dso.exp sometimes broken

Keith reported that gdb.base/dso2dso.exp is broken, with the following
error:

| $ make check RUNTESTFLAGS=dso2dso.exp
| [snip]
| Running ../../../src/gdb/testsuite/gdb.base/dso2dso.exp ...
| ERROR: tcl error sourcing ../../../src/gdb/testsuite/gdb.base/dso2dso.exp.
| ERROR: couldn't open
| "../../../src/gdb/testsuite/gdb.base/../../../src/gdb/testsuite/gdb.base/dso2dso-dso1.c":
| no such file or directory
|     while executing
| "error "$message""
|     (procedure "gdb_get_line_number" line 14)
|     invoked from within
| "gdb_get_line_number "STOP HERE" $srcfile_libdso1"
|     (file "../../../src/gdb/testsuite/gdb.base/dso2dso.exp" line 60)
|     invoked from within
| "source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
|     ("uplevel" body line 1)
|     invoked from within
| "uplevel #0 source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
|     invoked from within
| "catch "uplevel #0 source $test_file_name""

This happens because gdb_get_line_number will prepend $srcdir/$subdir
if the given filename does not start with "/", and this happens when
GDB was configured using a relative path to the configure script.
When using an absolute path like I do, we avoid the pre-pending that
Keith is seeing.

gdb/testsuite/ChangeLog:

        Keith Seitz  <keiths@redhat.com>:
        * gdb.base/dso2dso.exp: Pass basename of source file in call
        to gdb_get_line_number.

Tested on x86_64-linux with both scenarios.


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp: Improve testcase documentation.
@ 2015-08-13 20:06 sergiodj+buildbot
  2015-08-13 20:59 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-13 20:06 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3d1e2b37751fed4e014d52ce858bcb6b147c475a ***

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

gdb.base/dso2dso.exp: Improve testcase documentation.

gdb/testsuite/ChangeLog:

        * gdb.base/dso2dso.exp: Improve the testcase's documentation.


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp
@ 2015-08-18 14:03 sergiodj+buildbot
  2015-08-18 15:50 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-18 14:03 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 37419df723ec96b600030970e0fe97aaa82fa2e1 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.10-branch
Commit: 37419df723ec96b600030970e0fe97aaa82fa2e1

PR record/18691: Fix fails in solib-precsave.exp

We see the following regressions in testing on x86_64-linux,

 reverse-step^M
 Cannot access memory at address 0x2aaaaaed26c0^M
 (gdb) FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one

when GDB reverse step into a function, GDB wants to skip prologue so
it requests TARGET_OBJECT_CODE_MEMORY to read some code memory in
memory_xfer_partial_1.  However in dcache_read_memory_partial, the object
becomes TARGET_OBJECT_MEMORY

      return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL,
                                   myaddr, NULL, memaddr, len,
                                   xfered_len);

in reverse debugging, ops->to_xfer_partial is record_full_core_xfer_partial
and it will return TARGET_XFER_E_IO because it can't find any records.
The test fails.

At this moment, the delegate relationship is like

  dcache -> record-core -> core -> exec

and we want to GDB read memory across targets, which means if the
requested memory isn't found in record-core, GDB can read memory from
core, and exec even further if needed.  I find raw_memory_xfer_partial
is exactly what I want.

gdb:

2015-08-18  Yao Qi  <yao.qi@linaro.org>

	PR record/18691
	* dcache.c (dcache_read_memory_partial): Call
	raw_memory_xfer_partial.
	* target.c (raw_memory_xfer_partial): Make it non-static.
	* target.h (raw_memory_xfer_partial): Declare.


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix stale cleanup left by linux_mntns_access_fs
@ 2015-08-21 16:39 sergiodj+buildbot
  2015-08-21 16:55 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 16:39 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 23778dcc5bb92541850e239d10bf19eb311a57b6 ***

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

Fix stale cleanup left by linux_mntns_access_fs

This commit fixes a stale cleanup left by linux_mntns_access_fs.

gdb/ChangeLog:

	* nat/linux-namespaces.c (linux_mntns_access_fs):
	Do not overwrite old_chain.


^ permalink raw reply	[flat|nested] 37+ 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-21 18:45 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ 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] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] signal_command: Leftover cleanup chain regression
@ 2015-08-25 17:11 sergiodj+buildbot
  2015-08-25 20:27 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-08-25 17:11 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3ba0344e56ef739808615be5ca319f82c2a83855 ***

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

signal_command: Leftover cleanup chain regression

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

	* infcmd.c (signal_command): Call do_cleanups for args_chain.


^ permalink raw reply	[flat|nested] 37+ 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-11-29  0:14 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ 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] 37+ 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-11-28 22:35 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ 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] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix regression by Do not skip prologue for asm (.S) files
@ 2015-12-02  9:47 sergiodj+buildbot
  2015-12-02  9:56 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2015-12-02  9:47 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 87a8c81ef09b8f86844924c71b2d886b58991c60 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.10-branch
Commit: 87a8c81ef09b8f86844924c71b2d886b58991c60

Fix regression by Do not skip prologue for asm (.S) files

Patch "Do not skip prologue for asm (.S) files" [1] changes GDB's
behaviour on which test gdb.arch/thumb-singlestep.exp depends, so
it causes the fail below:

 (gdb) si^M
 37              blx     foo^M
 (gdb) FAIL: gdb.arch/thumb-singlestep.exp: step into foo

the test assumes the program will stop at the instruction after "push"
but it doesn't.  The fix to this fail is to do one more single step.

[1] https://sourceware.org/ml/gdb-patches/2015-06/msg00561.html

gdb/testsuite:

2015-12-02  Yao Qi  <yao.qi@linaro.org>

	* gdb.arch/thumb-singlestep.exp: Do one more single step.


^ permalink raw reply	[flat|nested] 37+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion
@ 2016-02-11 15:36 sergiodj+buildbot
  2016-02-11 16:20 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 37+ messages in thread
From: sergiodj+buildbot @ 2016-02-11 15:36 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 718b36fead887693158396b948d7f409b987c053 ***

Author: Don Breazeal <donb@codesourcery.com>
Branch: gdb-7.10-branch
Commit: 718b36fead887693158396b948d7f409b987c053

Fix '-data-read-memory-bytes' typo/assertion

Backported to the 7.10 branch per this thread:
https://www.sourceware.org/ml/gdb-patches/2016-02/msg00134.html

This patch fixes a typo in target.c:read_memory_robust, where
it calls read_whatever_is_readable with the function arguments
in the wrong order.  Depending on the address being read, it
can cause an xmalloc with a huge size, resulting in an assertion
failure, or just read something other than what was requested.

The problem only arises when GDB is handling an MI
"-data-read-memory-bytes" request and the initial target_read returns
an error status.  Note that read_memory_robust is only called from
the MI code.

gdb/ChangeLog:

	* gdb/target.c (read_memory_robust): Call
	read_whatever_is_readable with arguments in the correct order.


^ permalink raw reply	[flat|nested] 37+ messages in thread
end of thread, other threads:[~2016-02-11 16:20 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-10 13:58 [binutils-gdb/gdb-7.10-branch] Fix testsuite regression by: Do not skip prologue for asm (.S) files sergiodj+buildbot
2015-07-10 13:58 ` Failures on AIX-POWER7-plain, branch gdb-7.10-branch sergiodj+buildbot
2015-07-10 14:18 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-07-10 14:23 ` Failures on Fedora-i686, " sergiodj+buildbot
2015-07-10 14:31 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2015-07-10 14:37 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2015-07-10 14:46 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2015-07-10 14:52 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2015-07-10 14:52 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2015-07-10 14:53 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2015-07-10 15:01 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2015-07-10 15:13 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-07-10 15:33 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2015-07-10 15:34 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2015-07-10 17:49 ` Failures on Fedora-i686, " sergiodj+buildbot
2015-07-10 22:00 ` Failures on Debian-i686, " sergiodj+buildbot
2015-07-10 22:16 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot
2015-07-10 22:41 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot
2015-07-11  2:34 ` Failures on Fedora-ppc64be-m64, " sergiodj+buildbot
2015-07-11  3:12 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-07-11  7:56 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-07-11  8:30 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot
2015-07-11 15:32 ` Failures on Debian-x86_64-m64, " sergiodj+buildbot
2015-07-14  7:24 [binutils-gdb/gdb-7.10-branch] record: set stop_pc in "record goto" command sergiodj+buildbot
2015-07-14  7:32 ` Failures on Debian-s390x-m64, 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-07-30 20:44 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-10 20:46 [binutils-gdb/gdb-7.10-branch] PR gdb/17960 Internal error: tracker != NULL when completing on file:function sergiodj+buildbot
2015-08-10 20:55 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-12  9:20 [binutils-gdb/gdb-7.10-branch] [regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint sergiodj+buildbot
2015-08-12 10:31 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-13 19:48 [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp sometimes broken sergiodj+buildbot
2015-08-13 20:19 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-13 20:06 [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp: Improve testcase documentation sergiodj+buildbot
2015-08-13 20:59 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-18 14:03 [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp sergiodj+buildbot
2015-08-18 15:50 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 16:39 [binutils-gdb/gdb-7.10-branch] Fix stale cleanup left by linux_mntns_access_fs sergiodj+buildbot
2015-08-21 16:55 ` Failures on Debian-s390x-m64, 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-21 18:45 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-25 17:11 [binutils-gdb/gdb-7.10-branch] signal_command: Leftover cleanup chain regression sergiodj+buildbot
2015-08-25 20:27 ` Failures on Debian-s390x-m64, 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-11-29  0:14 ` Failures on Debian-s390x-m64, 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-11-28 22:35 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-12-02  9:47 [binutils-gdb/gdb-7.10-branch] Fix regression by Do not skip prologue for asm (.S) files sergiodj+buildbot
2015-12-02  9:56 ` Failures on Debian-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2016-02-11 15:36 [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion sergiodj+buildbot
2016-02-11 16:20 ` Failures on Debian-s390x-m64, 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).