public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-8.1-branch] gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1".
@ 2018-01-12  5:00 sergiodj+buildbot
  2018-01-12  5:00 ` Failures on Fedora-x86_64-m64, branch gdb-8.1-branch sergiodj+buildbot
                   ` (12 more replies)
  0 siblings, 13 replies; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-12  5:00 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 93935fd4e30036cb2d549ac0b5568efa495237c4 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.1-branch
Commit: 93935fd4e30036cb2d549ac0b5568efa495237c4

gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1".

gdb/ChangeLog:

        * NEWS: Rename "Changes since 8.0" into "Changes in 8.1".


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Reset inferior::control on inferior exit
@ 2018-02-15 15:16 sergiodj+buildbot
  2018-02-27  7:08 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-02-15 15:16 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 2ba75fb16a5c78007010cfbde1c1b5be4bb9a8c8 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-8.1-branch
Commit: 2ba75fb16a5c78007010cfbde1c1b5be4bb9a8c8

Reset inferior::control on inferior exit

When we kill an inferior, the inferior is not deleted.  What is more, it
is reused when the new process is created, so we need to reset inferior's
state when it exits.

gdb:

2018-02-15  Yao Qi  <yao.qi@linaro.org>

	PR gdb/22849
	* inferior.c (exit_inferior_1): Reset inf->control.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] gdb/NEWS: Clarify the news entry for "rbreak" in GDB 8.1
@ 2018-02-09 12:51 sergiodj+buildbot
  2018-02-09 14:27 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-02-09 12:51 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT c58318003f7fd63e43b0b6aea045bc16bada8c50 ***

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

gdb/NEWS: Clarify the news entry for "rbreak" in GDB 8.1

gdb/ChangeLog:

        PR gdb/22824:
        * NEWS <Changes in GDB 8.1>: Clarify that "rbreak" is a new
        Python function, rather than a new command.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Bump GDB version number to 8.1.0.DATE-git.
@ 2018-01-31  3:31 sergiodj+buildbot
  2018-01-31  6:00 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-31  3:31 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 37634d335c0e962d9531125dd13cf9d6210429dd ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.1-branch
Commit: 37634d335c0e962d9531125dd13cf9d6210429dd

Bump GDB version number to 8.1.0.DATE-git.

gdb/ChangeLog:

	* version.in: Set GDB version number to 8.1.0.DATE-git.
	* PROBLEMS: Likewise.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Set GDB version number to 8.1.
@ 2018-01-31  3:17 sergiodj+buildbot
  2018-01-31  4:46 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-31  3:17 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT b755db3c98137baaff8a154d936d326d9a9c72a7 ***

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

Set GDB version number to 8.1.

gdb/ChangeLog:

	* version.in: Set GDB version number to 8.1.
	* PROBLEMS: Likewise.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Avoid compilation errors in MinGW native builds of GDB
@ 2018-01-27 17:20 sergiodj+buildbot
  2018-01-27 21:07 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-27 17:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 0b2b72156eef6e1a34f316e96278bc286f0d0506 ***

Author: Eli Zaretskii <eliz@gnu.org>
Branch: gdb-8.1-branch
Commit: 0b2b72156eef6e1a34f316e96278bc286f0d0506

Avoid compilation errors in MinGW native builds of GDB

The error is triggered by including python-internal.h, and the
error message is:

     In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0,
	      from build-gnulib/import/math.h:27,
	      from d:/usr/Python26/include/pyport.h:235,
	      from d:/usr/Python26/include/Python.h:58,
	      from python/python-internal.h:94,
	      from python/py-arch.c:24:
     d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared
        using ::hypot;
	        ^~~~~

This happens because Python headers define 'hypot' to expand to
'_hypot' in the Windows builds.

gdb/ChangeLog:
2018-01-27  Eli Zaretskii  <eliz@gnu.org>

	* python/python-internal.h (_hypot) [__MINGW32__]: Define back to
	'hypoth'.  This avoids a compilation error.

(cherry picked from commit b2a426e2c5632644b6b8bc0dde4cd32d42d548e2)


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Avoid compilation warning in libiberty/simple-object-xcoff.c
@ 2018-01-27 16:54 sergiodj+buildbot
  2018-01-27 18:26 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-27 16:54 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3d721be4ac8c6c8452c25aa382d09bd487dcded3 ***

Author: Eli Zaretskii <eliz@gnu.org>
Branch: gdb-8.1-branch
Commit: 3d721be4ac8c6c8452c25aa382d09bd487dcded3

Avoid compilation warning in libiberty/simple-object-xcoff.c

gdb/ChangeLog:
2018-01-27  Eli Zaretskii  <eliz@gnu.org>

	* simple-object-xcoff.c (simple_object_xcoff_find_sections): Avoid
	compilation warning in 32-bit builds not supported by
	AC_SYS_LARGEFILE.

(cherry picked from commit de54ee813f35cdeee51729c6d50b82935dc88634)


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix GCC PR83906 - [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
@ 2018-01-24 19:02 sergiodj+buildbot
  2018-01-24 22:44 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-24 19:02 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 76112dde119b37c1bf6b6234049a94a288d3e02f ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-8.1-branch
Commit: 76112dde119b37c1bf6b6234049a94a288d3e02f

Fix GCC PR83906 - [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
testcase failing randomly, as shown by running (in libstdc++'s
testsuite):

 make check RUNTESTFLAGS=prettyprinters.exp=80276.cc

in a loop.  Sometimes you get this:

 FAIL: libstdc++-prettyprinters/80276.cc whatis p4

I.e., this:
 type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>

instead of this:
 type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>

Jonathan Wakely tracked it on the printer side to this bit in
libstdc++'s type printer:

            if self.type_obj == type_obj:
                return strip_inline_namespaces(self.name)

This assumes the two types resolve to the same gdb.Type but some times
the comparison unexpectedly fails.

Running the testcase manually under Valgrind finds the problem in GDB:

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ==6118== Conditional jump or move depends on uninitialised value(s)
 ==6118==    at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
 ==6118==    by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
 ==6118==    by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
 ==6118==    by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
 ==6118==    by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
 ==6118==    by 0x63D7E6C: PyObject_RichCompare (object.c:961)
 ==6118==    by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That "bcmp" call is really a memcmp call in check_types_equal.  The
problem is that gdb is memcmp'ing two objects that are equal in value:

 (top-gdb) p *TYPE_RANGE_DATA (type1)
 $1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
   flag_bound_evaluated = 0}
 (top-gdb) p *TYPE_RANGE_DATA (type2)
 $2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
   flag_bound_evaluated = 0}

but differ in padding.  Notice the 4-byte hole:

  (top-gdb) ptype /o range_bounds
  /* offset    |  size */  type = struct range_bounds {
  /*    0      |    16 */    struct dynamic_prop {
  /*    0      |     4 */        dynamic_prop_kind kind;
  /* XXX  4-byte hole  */
  /*    8      |     8 */        union dynamic_prop_data {
  /*                 8 */            LONGEST const_val;
  /*                 8 */            void *baton;

				     /* total size (bytes):    8 */
				 } data;

which is filled with garbage:

  (top-gdb) x /40bx TYPE_RANGE_DATA (type1)
  0x2fa7ea0:      0x01    0x00    0x00    0x00    0x43    0x01    0x00    0x00
						  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  0x2fa7ea8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x2fa7eb0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
  0x2fa7eb8:      0x0f    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x2fa7ec0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  (top-gdb) x /40bx TYPE_RANGE_DATA (type2)
  0x20379b0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
						  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  0x20379b8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x20379c0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
  0x20379c8:      0x0f    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x20379d0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00

  (top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
  $3 = -187

In some cases objects of type range_bounds are memset when allocated,
but then their dynamic_prop low/high fields are copied over from some
template dynamic_prop object that wasn't memset.  E.g.,
create_static_range_type's low/high locals are left with garbage in
the padding, and then that padding is copied over to the range_bounds
object's low/high fields.

At first, I considered making sure to always memset range_bounds
objects, thinking that maybe type objects are being put in some bcache
instance somewhere.  But then I hacked bcache/bcache_full to poison
non-pod types, and made dynamic_prop a non-pod, and GDB still
compiled.

So given that, it seems safest to not assume padding will always be
memset, and instead treat them as regular value types, implementing
(in)equality operators and using those instead of memcmp.

This fixes the random FAILs in GCC's testcase.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

gdb/ChangeLog:
2018-01-24  Pedro Alves  <palves@redhat.com>

	GCC PR libstdc++/83906
	* gdbtypes.c (operator==(const dynamic_prop &,
	const dynamic_prop &)): New.
	(operator==(const range_bounds &, const range_bounds &)): New.
	(check_types_equal): Use them instead of memcmp.
	* gdbtypes.h (operator==(const dynamic_prop &,
	const dynamic_prop &)): Declare.
	(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
	(operator==(const range_bounds &, const range_bounds &)): Declare.
	(operator!=(const range_bounds &, const range_bounds &)): Declare.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] MAINTAINERS: Update my company e-mail address
@ 2018-01-22 21:38 sergiodj+buildbot
  2018-01-23  1:15 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-22 21:38 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT fd37310fb82980b66cca5b0bce5a38414d64b44f ***

Author: Maciej W. Rozycki <macro@mips.com>
Branch: gdb-8.1-branch
Commit: fd37310fb82980b66cca5b0bce5a38414d64b44f

MAINTAINERS: Update my company e-mail address

Following my recent transition from Imagination Technologies to the
reincarnated MIPS company update MAINTAINERS entries accordingly.

	binutils/
	* MAINTAINERS: Update my company e-mail address.

	gdb/
	* MAINTAINERS: Update my company e-mail address.

	sim/
	* MAINTAINERS: Update my company e-mail address.

(cherry picked from commit d65ce302abcb260e14ca5f201b78e8e6d4a2e720)


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix segfault with 'set print object on' + 'whatis <struct>' & co
@ 2018-01-22 20:14 sergiodj+buildbot
  2018-01-23  0:01 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-22 20:14 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ddd0c99df8d76047fc651911e5651e8decae86ca ***

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

Fix segfault with 'set print object on' + 'whatis <struct>' & co

Compiling GDB with a recent GCC exposes a problem:

  ../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)':
  ../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
    real_type = value_rtti_type (val, &full, &top, &using_enc);
    ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The warning is correct.  There are indeed code paths that use
uninitialized 'val', leading to crashes.  Inside the
value_rtti_indirect_type/value_rtti_type calls here in whatis_exp:

  if (opts.objectprint)
    {
      if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type))
	  && (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT))
        real_type = value_rtti_indirect_type (val, &full, &top, &using_enc);
      else if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
	real_type = value_rtti_type (val, &full, &top, &using_enc);
    }

We reach those calls above with "set print object on", and then with
any of:

  (gdb) whatis struct some_structure_type
  (gdb) whatis struct some_structure_type *
  (gdb) whatis struct some_structure_type &

because "whatis" with a type argument enters this branch:

      /* The behavior of "whatis" depends on whether the user
	 expression names a type directly, or a language expression
	 (including variable names).  If the former, then "whatis"
	 strips one level of typedefs, only.  If an expression,
	 "whatis" prints the type of the expression without stripping
	 any typedef level.  "ptype" always strips all levels of
	 typedefs.  */
      if (show == -1 && expr->elts[0].opcode == OP_TYPE)
	{

which does not initialize VAL.  Trying the above triggers crashes like
this:

  (gdb) set print object on
  (gdb) whatis some_structure_type

  Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
  0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388
  2388      int instance_flags = TYPE_INSTANCE_FLAGS (type);
  ...

This is a regression caused by a recent-ish refactoring of the code on
'whatis_exp', introduced by:

  commit c973d0aa4a2c737ab527ae44a617f1c357e07364
  Date:   Mon Aug 21 11:34:32 2017 +0100

      Fix type casts losing typedefs and reimplement "whatis" typedef stripping

Fix this by setting VAL to NULL in the "whatis TYPE" case, and
skipping fetching the dynamic type if there's no value to fetch it
from.

New tests included.

gdb/ChangeLog:
2018-01-22  Pedro Alves  <palves@redhat.com>
	    Sergio Durigan Junior  <sergiodj@redhat.com>

	* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
	case.

gdb/testsuite/ChangeLog:
2018-01-22  Pedro Alves  <palves@redhat.com>
	    Sergio Durigan Junior  <sergiodj@redhat.com>

	* gdb.base/whatis.exp: Add tests for 'set print object on' +
	'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx")
@ 2018-01-18  0:02 sergiodj+buildbot
  2018-01-18 13:32 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-18  0:02 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 2a54d2158beeb2833cb3fb4da68e7c55e341159a ***

Author: Sergio Durigan Junior <sergiodj@redhat.com>
Branch: gdb-8.1-branch
Commit: 2a54d2158beeb2833cb3fb4da68e7c55e341159a

Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx")

This fixes a GCC warning that happens when compiling
gdb/compile/compile.c on some GCC versions (e.g., "gcc (GCC) 7.2.1
20180104 (Red Hat 7.2.1-6)"):

../../gdb/compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)':
../../gdb/compile/compile.c:548:19: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized]
     error_message = compiler->fe->ops->set_arguments_v0 (compiler->fe, triplet_rx,
     ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         argc, argv);
         ~~~~~~~~~~~
../../gdb/compile/compile.c:466:9: note: 'triplet_rx' was declared here
   char *triplet_rx;
         ^~~~~~~~~~

It's a simple patch that converts "triplet_rx" from "char *" to
"std::string", thus guaranteeing that it will be always initialized.

I've regtested this patch and did not find any regressions.  OK to
apply on both master and 8.1 (after creating a bug for it)?

gdb/ChangeLog:
2018-01-17  Sergio Durigan Junior  <sergiodj@redhat.com>

	* compile/compile.c (compile_to_object): Convert "triplet_rx"
	to "std::string".


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] configure: Fix test for fs_base/gs_base in <sys/user.h>
@ 2018-01-17 14:00 sergiodj+buildbot
  2018-01-17 19:08 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-17 14:00 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6949085e3eaef536b2c76252452ec3e63e9f112c ***

Author: Eldar Abusalimov <eldar.abusalimov@jetbrains.com>
Branch: gdb-8.1-branch
Commit: 6949085e3eaef536b2c76252452ec3e63e9f112c

configure: Fix test for fs_base/gs_base in <sys/user.h>

Make <sys/types.h> be included prior to including <sys/user.h>.

glibc versions older than 2.14 use __uintNN_t types within certain
structures defined in <sys/user.h> probably assuming these types are
defined prior to including the header. This results in the following
`configure` feature test compilation error that makes it think that
`struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields,
althouh it does.

    configure:13617: checking for struct user_regs_struct.fs_base
    configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5
    In file included from conftest.c:158:0:
    /usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t'
       __uint16_t  cwd;
       ^
    /usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t'
       __uint16_t  swd;
       ^
    /usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t'
       __uint16_t  ftw;
       ^
    /usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t'
       __uint16_t  fop;
       ^
    /usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t'
       __uint64_t  rip;
       ^
    /usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t'
       __uint64_t  rdp;
       ^
    /usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t'
       __uint32_t  mxcsr;
       ^
    /usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t'
       __uint32_t  mxcr_mask;
       ^
    /usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t'
       __uint32_t  st_space[32];   /* 8*16 bytes for each FP-reg = 128 bytes */
       ^
    /usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t'
       __uint32_t  xmm_space[64];  /* 16*16 bytes for each XMM-reg = 256 bytes */
       ^
    /usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t'
       __uint32_t  padding[24];
       ^
    configure:13617: $? = 1
    configure: failed program was:
    | /* confdefs.h */
    ...
    | /* end confdefs.h.  */
    | #include <sys/user.h>
    |
    | int
    | main ()
    | {
    | static struct user_regs_struct ac_aggr;
    | if (ac_aggr.fs_base)
    | return 0;
    |   ;
    |   return 0;
    | }

Recent glibc versions don't use typedef'ed int types in <sys/user.h>,
thus allowing it to be included as is
(glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a).
However there're still some distros alive that use older glibc,
for instance, RHEL/CentOS 6 package glibc 2.12.

Also affects PR gdb/21559:

    ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.

As noted by Andrew Paprocki, who submitted the PR
(https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3):

    > It should be noted that modifying `configure` to force on
    > `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and
    > `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some
    > reason the `configure` tests for `fs_base` and `gs_base` fail
    > even though `sys/user.h` on RHEL5 has the fields defined in
    > `user_regs_struct`.

Note that this patch does NOT fix the root cause of PR gdb/21559,
although now that `configure` properly detects the presence of the
fields and sets HAVE_XXX accordingly, the execution takes another
path, which doesn't lead to the assertion failure in question.

gdb/ChangeLog:
2018-01-17  Eldar Abusalimov  <eldar.abusalimov@jetbrains.com>

	PR gdb/21559
	* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
	checking for fs_base/gs_base fields in struct user_regs_struct.
	* configure: Regenerate.

gdb/gdbserver/ChangeLog:
2018-01-17  Eldar Abusalimov  <eldar.abusalimov@jetbrains.com>

	PR gdb/21559
	* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
	checking for fs_base/gs_base fields in struct user_regs_struct.
	* configure: Regenerate.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Don't pass -m64 to libcc1 on aarch64-linux.
@ 2018-01-17 13:36 sergiodj+buildbot
  2018-01-17 16:38 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-17 13:36 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 94485cac9629ca3e5489014e1b704e35f988d3e3 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-8.1-branch
Commit: 94485cac9629ca3e5489014e1b704e35f988d3e3

Don't pass -m64 to libcc1 on aarch64-linux.

Nowadays, if we use "compile" on aarch64-linux, we'll get the following
error,

(gdb) compile code -- ;
aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'

because the default gcc_target_options returns "-m64" and
"-mcmodel=large", neither is useful to aarch64-linux.

gdb:

2018-01-17  Yao Qi  <yao.qi@linaro.org>

	* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New
	function.
	(aarch64_linux_init_abi): Install it to gdbarch hook
	gcc_target_options.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Relax gdb.compile/compile.exp to match the address printed for frame
@ 2018-01-17 11:59 sergiodj+buildbot
  2018-01-17 14:09 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-17 11:59 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 862f0945fb83319efee9c621a3434384f1882270 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-8.1-branch
Commit: 862f0945fb83319efee9c621a3434384f1882270

Relax gdb.compile/compile.exp to match the address printed for frame

One test in gdb.compile/compile.exp passes on one fedora builder,

 bt
 #0  0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb
 command line:1^M
 #1  <function called from gdb>^M
 #2  main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
 (gdb) PASS: gdb.compile/compile.exp: bt

but fails on my machine with gcc trunk,

 bt^M
 #0  _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M
 #1  <function called from gdb>^M
 #2  main () at gdb/testsuite/gdb.compile/compile.c:106^M
 (gdb) FAIL: gdb.compile/compile.exp: bt

The test should be tweaked to match both cases (pc in the start of line
vs pc in the middle of line).  Note that I am not clear that why libcc1
emits debug info this way so that the address is in the middle of line.

gdb/testsuite:

2018-01-17  Yao Qi  <yao.qi@linaro.org>

	* gdb.compile/compile.exp: Match the address printed for
	frame in the output of command "bt".


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix scm-ports.exp regression
@ 2018-01-15 22:32 sergiodj+buildbot
  2018-01-15 22:52 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-15 22:32 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5429afd6529f3a7dc7d733fc21053ca3ecadd033 ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.1-branch
Commit: 5429afd6529f3a7dc7d733fc21053ca3ecadd033

Fix scm-ports.exp regression

In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
pointed out that the scalar printing patches caused a regression in
scm-ports.exp on x86.

What happens is that on x86, this:

	set sp_reg [get_integer_valueof "\$sp" 0]

... ends up setting sp_reg to a negative value, because
get_integer_valueof uses "print/d":

    print /d $sp
    $1 = -11496

Then later the test suite does:

    gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
	"= $sp_reg" \
	"seek to \$sp"

... expecting this value to be identical to the saved $sp_reg value.
However it gets:

    guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
    = 4294955800

"print" is just a wrapper for guile's format:

    gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"

The seek function returns a scm_t_off, the printing of which is
handled by guile, not by gdb.

Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
build.

2018-01-15  Tom Tromey  <tom@tromey.com>

	* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
	compute sp_reg.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Add testcase for GDB hang fixed by previous commit
@ 2018-01-12 21:42 sergiodj+buildbot
  2018-01-12 23:20 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-12 21:42 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 1d17025506de70cb1d9d5b7a5654e40ce689bf26 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-8.1-branch
Commit: 1d17025506de70cb1d9d5b7a5654e40ce689bf26

Add testcase for GDB hang fixed by previous commit

This adds a testcase for the previous commit.  The regression was
related to in-line step overs.  The reason we didn't see it on native
x86-64/s390 GNU/Linux testing is that native debugging uses displaced
stepping by default (because native debugging defaults to "maint set
target-non-stop on"), unlike remote debugging.

So in order to trigger the bug with native debugging as well, the
testcase disables displaced stepping explicitly.

Also, instead of using watchpoints to trigger the regression, the
testcase uses a breakpoint at address 0, which should be more
portable.

gdb/testsuite/ChangeLog:
2018-01-12  Pedro Alves  <palves@redhat.com>

	* gdb.base/continue-after-aborted-step-over.c: New.
	* gdb.base/continue-after-aborted-step-over.exp: New.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix GDB hang with remote after error from resume
@ 2018-01-12 20:43 sergiodj+buildbot
  2018-01-12 22:06 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-12 20:43 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a09f837ae221977eec50cc2ded12bd765b3b634a ***

Author: Andreas Arnez <arnez@linux.vnet.ibm.com>
Branch: gdb-8.1-branch
Commit: a09f837ae221977eec50cc2ded12bd765b3b634a

Fix GDB hang with remote after error from resume

Since this commit --

  Fix PR18360 - internal error when using "interrupt -a"
  (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55)

-- the testsuite shows long delays on s390 with native-gdbserver when
executing certain tests, such as watchpoints.exp.  These hangs have been
discussed before in the context of buildbot problems, see here:

  https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html

The problem can easily be triggered by stopping on a breakpoint, then
setting impossible watchpoints, and finally doing "continue".  Then, after
having set the step-over state (in keep_going_pass_signal in infrun.c),
GDB tries to insert breakpoints and watchpoints into the inferior.  This
fails, and the "continue" command is aborted.  But the step-over state is
not cleared in this case, which causes future step-over attempts to be
skipped since GDB thinks that "we already have an in-line step-over
operation ongoing" (see start_step_over in infrun.c).  Thus the next
"continue" just goes on to wait for events from the remote, which will
never occur.

The problem can also be reproduced on amd64 with native-gdbserver, using
the following change to watchpoints.exp:

 -- >8 --
 --- a/gdb/testsuite/gdb.base/watchpoints.exp
 +++ b/gdb/testsuite/gdb.base/watchpoints.exp
 @@ -61,2 +61,3 @@ with_test_prefix "before inferior start" {
      gdb_test "watch ival3" ".*" ""
 +    gdb_test "watch *(char \[256\] *) main"

 -- >8 --

To fix the hang, this patch clears the step-over info when
insert_breakpoints has failed.  Of course, with native-gdbserver the
watchpoints.exp test case still causes many FAILs on s390, because
gdbserver does not support watchpoints for that target.  This is a
separate issue.

gdb/ChangeLog:
2018-01-12  Andreas Arnez  <arnez@linux.vnet.ibm.com>

	* infrun.c (keep_going_pass_signal): Clear step-over info when
	insert_breakpoints fails.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Bump GDB version number to 8.0.91.DATE-git.
@ 2018-01-12  6:37 sergiodj+buildbot
  2018-01-12  9:12 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-12  6:37 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 4d8dd3e16837698b48447531c8e74796d702135c ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.1-branch
Commit: 4d8dd3e16837698b48447531c8e74796d702135c

Bump GDB version number to 8.0.91.DATE-git.

gdb/ChangeLog:

	* version.in: Set GDB version number to 8.0.91.DATE-git.
	* PROBLEMS: Likewise.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Set GDB version number to 8.0.91.
@ 2018-01-12  5:53 sergiodj+buildbot
  2018-01-12  8:00 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-12  5:53 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 556dbf30fb0d5d6f59c7b38f2ac930cc6f9589eb ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.1-branch
Commit: 556dbf30fb0d5d6f59c7b38f2ac930cc6f9589eb

Set GDB version number to 8.0.91.

gdb/ChangeLog:

	* version.in: Set GDB version number to 8.0.91.
	* PROBLEMS: Likewise.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)
@ 2018-01-11 19:39 sergiodj+buildbot
  2018-01-11 20:52 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-11 19:39 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f740fa5094817e948853bbcba46410a05175260d ***

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

gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)

As Maciej reported at
<https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this
commit:

 commit d930703d68ae160ddfe8ebe5fdcf416fb6090e1e
 Date: Thu Nov 16 18:44:43 2017 +0000
 Subject: Don't ever Quit out of resume

caused regressions on software single-set targets, specifically:

 FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
 FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind
 FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break)
 FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind
 FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind

and indeed detailed logs indicate a breakpoint is left lingering, e.g.:

 (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
 maint info breakpoints 0
 Num     Type           Disp Enb Address    What
 0       sw single-step keep y   0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1
	 stop only in thread 1
 (gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind

vs:

 (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
 maint info breakpoints 0
 No breakpoint or watchpoint matching '0'.
 (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind

as at commit d930703d68ae^.

Before commit d930703d68ae, we had a cleanup installed in 'resume'
that would delete single-step breakpoints on error:

  /* Resuming.  */

  /* Things to clean up if we QUIT out of resume ().  */
  static void
  resume_cleanups (void *ignore)
  {
    if (!ptid_equal (inferior_ptid, null_ptid))
     delete_single_step_breakpoints (inferior_thread ());

    normal_stop ();
  }

That whole function was removed by d930703d68ae mainly to eliminate
the normal_stop call:

~~~~
    Note that the exception called from within resume ends up calling
    normal_stop via resume_cleanups.  That's very borked though, because
    normal_stop is going to re-handle whatever was the last reported
    event, possibly even re-running a hook stop...
~~~~

But as the regression shows, removing resume_cleanups completely went
a bit too far, as the delete_single_step_breakpoints call is still
necessary.

So fix the regression by reinstating the
delete_single_step_breakpoints call on error.  However, since we're
trying to eliminate cleanups, restore it in a different form (using
TRY/CATCH).

Tested on x86-64 GNU/Linux both top of master and on top of a series
that implements software single-step on x86.

gdb/ChangeLog:
2018-01-11  Pedro Alves  <palves@redhat.com>

	PR gdb/22583
	* infrun.c (resume): Rename to ...
	(resume_1): ... this.
	(resume): Reimplement as wrapper around resume_1.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] language_get_symbol_name_matcher -> get_symbol_name_matcher
@ 2018-01-11  5:03 sergiodj+buildbot
  2018-01-11  8:45 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-11  5:03 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a3dc9ae700a0f74bb1781be6334cfab04cf93caf ***

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

language_get_symbol_name_matcher -> get_symbol_name_matcher

Rename language_get_symbol_name_matcher -> get_symbol_name_matcher,
since the function is no longer a straight "language method".

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	* language.h (language_get_symbol_name_matcher): Rename ...
	(get_symbol_name_matcher): ... this.
	* language.c (language_get_symbol_name_matcher): Ditto.
	* dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All
	callers adjusted.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Ada: make verbatim matcher override other language matchers (PR gdb/22670)
@ 2018-01-11  4:10 sergiodj+buildbot
  2018-01-11  7:32 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-11  4:10 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 2707f065bea6f20db9296dbda4577ce45b69093a ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-8.1-branch
Commit: 2707f065bea6f20db9296dbda4577ce45b69093a

Ada: make verbatim matcher override other language matchers (PR gdb/22670)

A previous patch fixed verbatim matching in the lookup at the minimal
symbol level, but we should also be finding that same symbol through
the partial/full symtab search.

For example, this is what happens if we use "print" instead of
"break":

    (gdb) p <MixedCaseFunc>
    $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>

Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
function without parameters, and the expression above means calling
it.  If you try it before having started the inferior, you'd get the
following (expected) error:

    (gdb) print  <MixedCaseFunc>
    You can't do that without a process to debug.

The main idea behind making the name matcher be determined by the
symbol's language is so that C++ (etc.) wildmatching in linespecs
works even if the current language is not C++, as e.g., when you step
through C or assembly code.

Ada's verbatim matching syntax however ("<...>") isn't quite the same.
It is more a property of the current language than of a particular
symbol's language.  We want to support this syntax when debugging an
Ada program, but it's reason of existence is to find non-Ada symbols.
This suggests going back to enabling it depending on current language
instead of language of the symbol being matched.

I'm not entirely happy with the "current_language" reference (though I
think that it's harmless).  I think we could try storing the current
language in the lookup_name_info object, and then convert a bunch of
functions more to pass around lookup_name_info objects instead of
"const char *" names.  I.e., build the lookup_name_info higher up.
I'm not sure about that, I'll have to think more about it.  Maybe
something different will be better.  Meanwhile, this gets us going.

I've extended the testcase to also exercise a no-debug-info function,
for extra coverage of the minsyms-only paths.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	PR gdb/22670
	* dwarf2read.c
	(gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher):
	Adjust to use language_get_symbol_name_matcher instead of
	language_defn::la_get_symbol_name_matcher.
	* language.c (language_get_symbol_name_matcher): If in Ada mode
	and the lookup name is a verbatim match, return Ada's matcher.
	* language.h (language_get_symbol_name_matcher): Adjust comment.
	(ada_lookup_name_info::verbatim_p):: New method.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	PR gdb/22670
	* gdb.ada/bp_c_mixed_case.exp: Add intro comment.  Test printing C
	functions too.  Test setting breakpoints and printing C functions
	with no debug info too.
	* gdb.ada/bp_c_mixed_case/qux.c: New file.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)
@ 2018-01-11  3:20 sergiodj+buildbot
  2018-01-11  6:18 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-11  3:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT be1f9aabab1be45e324ae4cd30e7b08cb7e6c083 ***

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

Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)

This patch fixes the regression covered by the test added by:

    commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d
    Date: Thu Jan 4 03:30:37 2018 -0500
    Subject: Add "complete break ada" test to gdb.ada/complete.exp

The regression had been introduced by:

    commit b5ec771e60c1a0863e51eb491c85c674097e9e13
    Date:   Wed Nov 8 14:22:32 2017 +0000
    Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching

The gist of it is that linespec completion in Ada mode is generating
additional matches that should not appear in the match list
(internally generated symbols, or symbols that should be enclosed
between "<...>").  These extraneous entries have uppercase characters, such as:

    break ada__stringsS
    break ada__strings__R11s
    [etc]

These matches come from minimal symbols.  The problem is that Ada
minsyms end up with no language set (language_auto), and thus we end
up using the generic symbol name matcher for those instead of Ada's.
We already had a special case for in compare_symbol_name to handle
this, but it was limited to expressions, while the case at hand is
completing a linespec.  Fix this by applying the special case to
linespec completion as well.  I.e., remove the EXPRESSION check from
compare_symbol_name.  That alone turns out to not be sufficient still
-- GDB would still show a couple entries that shouldn't be there:

~~
    break ada__exceptions__exception_data__append_info_exception_name__2Xn
    break ada__exceptions__exception_data__exception_name_length__2Xn
~~

The reason is that these minimal symbols end up with their language
set to language_cplus / C++, because those encoded names manage to
demangle successfully as C++ symbols (using an old C++ mangling
scheme):

  $ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt
  Xn::ada__exceptions__exception_data__append_info_exception_name(void)

It's unfortunate that Ada's encoding scheme doesn't start with some
unique prefix like "_Z" in the C++ Itanium ABI mangling scheme.  For
now, paper over that by treating C++ minsyms as Ada minsyms.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

        PR gdb/22670
	* ada-lang.c (ada_collect_symbol_completion_matches): If the
	minsym's language is language_auto or language_cplus, pass down
	language_ada instead.
	* symtab.c (compare_symbol_name): Don't frob symbol language here.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

        PR gdb/22670
	* gdb.ada/complete.exp ("complete break ada"): Replace kfail with
	a fail.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)
@ 2018-01-11  2:27 sergiodj+buildbot
  2018-01-11  5:09 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-11  2:27 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT bd140f1f5ef06b801156c787331f2d3ad72320a1 ***

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

Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)

The problem here is that we are using the user-provided lookup name
literally for name comparisons.  I.e., "<MixedCase>" with the "<>"s
included.

This commit fixes the minsym lookup case.  psymbol/symbol lookup will
be fixed in a follow up.

In the minsym case, we're using using the user-provided lookup name
literally for linkage name comparisons.  That obviously can't work
since the "<>" are not really part of the linkage name.

The original idea was that we'd use the symbol's language to select
the right symbol name matching algorithm, but that doesn't work for
Ada because it's not really possible to unambiguously tell from the
linkage name alone whether we're dealing with Ada symbols, so Ada
minsyms end up with no language set, or sometimes C++ set.

So fix this by treating Ada mode specially when determining the
linkage name to match against.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	PR gdb/22670
	* minsyms.c (linkage_name_str): New function.
	(iterate_over_minimal_symbols): Use it.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	PR gdb/22670
	* gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] hurd: Add enough auxv support for AT_ENTRY for PIE binaries
@ 2018-01-08 16:07 sergiodj+buildbot
  2018-01-08 18:54 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-08 16:07 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT d31fecf37cc540c563e97085f1416129f51d3055 ***

Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Branch: gdb-8.1-branch
Commit: d31fecf37cc540c563e97085f1416129f51d3055

hurd: Add enough auxv support for AT_ENTRY for PIE binaries

Add PIE support for hurd, by faking an AT_ENTRY auxv entry.  That value
is expected to be read by svr4_exec_displacement, which will propagate
the executable displacement.

gdb/ChangeLog:

	* gdb/gnu-nat.c: Include <elf.h> and <link.h>.
	(gnu_xfer_auxv): New function.
	(gnu_xfer_partial): Call gnu_xfer_auxv when `object' is
	TARGET_OBJECT_AUXV.


^ permalink raw reply	[flat|nested] 39+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix GDBserver build failure when $development is false
@ 2018-01-08 12:27 sergiodj+buildbot
  2018-01-08 15:55 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 39+ messages in thread
From: sergiodj+buildbot @ 2018-01-08 12:27 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f464485579f8e0a22e87aaa568b7ed4b3ec13ee3 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-8.1-branch
Commit: f464485579f8e0a22e87aaa568b7ed4b3ec13ee3

Fix GDBserver build failure when $development is false

When we set bfd/development.sh:$development to false, GDBserver failed to
build,

selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status

selftest.o shouldn't be compiled and linked when $development is false.
With this patch, in release mode, GDBserver doesn't nothing with option
--selftest,

$ ./gdbserver --selftest=foo
Selftests are not available in a non-development build.
$ ./gdbserver --selftest
Selftests are not available in a non-development build.

gdb/gdbserver:

2018-01-08  Yao Qi  <yao.qi@linaro.org>
	    Simon Marchi  <simon.marchi@ericsson.com>

	* Makefile.in (OBS): Remove selftest.o.
	* configure.ac: Set srv_selftest_objs if $development is true.
	(GDBSERVER_DEPFILES): Append $srv_selftest_objs.
	* configure: Re-generated.
	* server.c (captured_main): Wrap variable selftest_filter with
	GDB_SELF_TEST.

gdb/testsuite:

2018-01-08  Simon Marchi  <simon.marchi@ericsson.com>

	* gdb.server/unittest.exp: Match the output in non-development
	mode.


^ permalink raw reply	[flat|nested] 39+ messages in thread
end of thread, other threads:[~2018-02-27  7:08 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-12  5:00 [binutils-gdb/gdb-8.1-branch] gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1" sergiodj+buildbot
2018-01-12  5:00 ` Failures on Fedora-x86_64-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-12  5:02 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2018-01-12  5:16 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2018-01-12  5:30 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2018-01-12  5:37 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-01-12  5:40 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2018-01-12  5:44 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-01-12  5:57 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2018-01-12  6:46 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, " sergiodj+buildbot
2018-01-12  7:22 ` Failures on Ubuntu-AArch64-m64, " sergiodj+buildbot
2018-01-12 13:13 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot
2018-01-12 13:52 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot
2018-01-12 14:29 ` Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot
  -- strict thread matches above, loose matches on Subject: below --
2018-02-15 15:16 [binutils-gdb/gdb-8.1-branch] Reset inferior::control on inferior exit sergiodj+buildbot
2018-02-27  7:08 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-02-09 12:51 [binutils-gdb/gdb-8.1-branch] gdb/NEWS: Clarify the news entry for "rbreak" in GDB 8.1 sergiodj+buildbot
2018-02-09 14:27 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-31  3:31 [binutils-gdb/gdb-8.1-branch] Bump GDB version number to 8.1.0.DATE-git sergiodj+buildbot
2018-01-31  6:00 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-31  3:17 [binutils-gdb/gdb-8.1-branch] Set GDB version number to 8.1 sergiodj+buildbot
2018-01-31  4:46 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-27 17:20 [binutils-gdb/gdb-8.1-branch] Avoid compilation errors in MinGW native builds of GDB sergiodj+buildbot
2018-01-27 21:07 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-27 16:54 [binutils-gdb/gdb-8.1-branch] Avoid compilation warning in libiberty/simple-object-xcoff.c sergiodj+buildbot
2018-01-27 18:26 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-24 19:02 [binutils-gdb/gdb-8.1-branch] Fix GCC PR83906 - [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4 sergiodj+buildbot
2018-01-24 22:44 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-22 21:38 [binutils-gdb/gdb-8.1-branch] MAINTAINERS: Update my company e-mail address sergiodj+buildbot
2018-01-23  1:15 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-22 20:14 [binutils-gdb/gdb-8.1-branch] Fix segfault with 'set print object on' + 'whatis <struct>' & co sergiodj+buildbot
2018-01-23  0:01 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-18  0:02 [binutils-gdb/gdb-8.1-branch] Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx") sergiodj+buildbot
2018-01-18 13:32 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-17 14:00 [binutils-gdb/gdb-8.1-branch] configure: Fix test for fs_base/gs_base in <sys/user.h> sergiodj+buildbot
2018-01-17 19:08 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-17 13:36 [binutils-gdb/gdb-8.1-branch] Don't pass -m64 to libcc1 on aarch64-linux sergiodj+buildbot
2018-01-17 16:38 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-17 11:59 [binutils-gdb/gdb-8.1-branch] Relax gdb.compile/compile.exp to match the address printed for frame sergiodj+buildbot
2018-01-17 14:09 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-15 22:32 [binutils-gdb/gdb-8.1-branch] Fix scm-ports.exp regression sergiodj+buildbot
2018-01-15 22:52 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-12 21:42 [binutils-gdb/gdb-8.1-branch] Add testcase for GDB hang fixed by previous commit sergiodj+buildbot
2018-01-12 23:20 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-12 20:43 [binutils-gdb/gdb-8.1-branch] Fix GDB hang with remote after error from resume sergiodj+buildbot
2018-01-12 22:06 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-12  6:37 [binutils-gdb/gdb-8.1-branch] Bump GDB version number to 8.0.91.DATE-git sergiodj+buildbot
2018-01-12  9:12 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-12  5:53 [binutils-gdb/gdb-8.1-branch] Set GDB version number to 8.0.91 sergiodj+buildbot
2018-01-12  8:00 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-11 19:39 [binutils-gdb/gdb-8.1-branch] gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583) sergiodj+buildbot
2018-01-11 20:52 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-11  5:03 [binutils-gdb/gdb-8.1-branch] language_get_symbol_name_matcher -> get_symbol_name_matcher sergiodj+buildbot
2018-01-11  8:45 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-11  4:10 [binutils-gdb/gdb-8.1-branch] Ada: make verbatim matcher override other language matchers (PR gdb/22670) sergiodj+buildbot
2018-01-11  7:32 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-11  3:20 [binutils-gdb/gdb-8.1-branch] Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670) sergiodj+buildbot
2018-01-11  6:18 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-11  2:27 [binutils-gdb/gdb-8.1-branch] Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670) sergiodj+buildbot
2018-01-11  5:09 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-08 16:07 [binutils-gdb/gdb-8.1-branch] hurd: Add enough auxv support for AT_ENTRY for PIE binaries sergiodj+buildbot
2018-01-08 18:54 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-01-08 12:27 [binutils-gdb/gdb-8.1-branch] Fix GDBserver build failure when $development is false sergiodj+buildbot
2018-01-08 15:55 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, branch gdb-8.1-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).