public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-8.1-branch] gdbserver/Windows: Fix "no program to debug" error
@ 2018-05-10 19:22 sergiodj+buildbot
  2018-05-10 19:32 ` Failures on Fedora-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
                   ` (12 more replies)
  0 siblings, 13 replies; 35+ messages in thread
From: sergiodj+buildbot @ 2018-05-10 19:22 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT c0c0270a9a38e1e888e9d6f0185b465d3751f518 ***

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

gdbserver/Windows: Fix "no program to debug" error

Trying to start a program with GDBserver on Windows yields
the following error:

    $ gdbserver.exe --once :4444 simple_main.exe
    Killing process(es): 5008
    No program to debug
    Exiting

The error itself comes from the following code shortly after
create_inferior gets called (in server.c::main):

    /* Wait till we are at first instruction in program.  */
    create_inferior (program_path.get (), program_args);
    [...]

    if (last_status.kind == TARGET_WAITKIND_EXITED
        || last_status.kind == TARGET_WAITKIND_SIGNALLED)
      was_running = 0;
    else
      was_running = 1;

    if (!was_running && !multi_mode)
      error ("No program to debug");

What happens is that the "last_status" global starts initialized
as zeroes, which means last_status.kind == TARGET_WAITKIND_EXITED,
and we expect create_inferior to be waiting for the inferior to
start until reaching the SIGTRAP, and to set the "last_status"
global to match that last event we received.

I suspect this is an unintended side-effect of the following change...

    commit 2090129c36c7e582943b7d300968d19b46160d84
    Date:   Thu Dec 22 21:11:11 2016 -0500
    Subject: Share fork_inferior et al with gdbserver

... which removes some code in server.c that was responsible for
starting the inferior in a functin that was named start_inferior,
and looked like this:

   signal_pid = create_inferior (new_argv[0], &new_argv[0]);
   [...]
   /* Wait till we are at 1st instruction in program, return new pid
      (assuming success).  */
   last_ptid = mywait (pid_to_ptid (signal_pid), &last_status, 0, 0);

The code has been transitioned to using fork_inferior, but sadly,
only for the targets that support it. On Windows, the calls to wait
setting "last_status" simply disappeared.

This patch adds it back in the Windows-specific implementation of
create_inferior.

gdb/gdbserver/ChangeLog:

        PR server/23158:
        * win32-low.c (win32_create_inferior): Add call to my_wait
        setting last_status global.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Set GDB version number to 8.1.1.
@ 2018-07-31 15:37 sergiodj+buildbot
  2018-07-31 21:16 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-07-31 15:37 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f99d9b9f436dce02aa06839395c67d400b2a0de0 ***

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

Set GDB version number to 8.1.1.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix build issue with Python 3.7
@ 2018-06-09 17:45 sergiodj+buildbot
  2018-06-09 18:18 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-06-09 17:45 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 863d5065467b16304f6b5c80a186e3bcc68c48a6 ***

Author: Paul Koning <paul_koning@dell.com>
Branch: gdb-8.1-branch
Commit: 863d5065467b16304f6b5c80a186e3bcc68c48a6

Fix build issue with Python 3.7

Originally reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1577396 -- gdb build fails
with Python 3.7 due to references to a Python internal function whose
declaration changed in 3.7.

gdb/ChangeLog
2018-06-09  Paul Koning  <paul_koning@dell.com>

	    PR gdb/23252

	    * python/python.c (do_start_initialization):
	    Avoid call to internal Python API.
	    (init__gdb_module): New function.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Unset gdbarch significant_addr_bit by default
@ 2018-05-31  4:02 sergiodj+buildbot
  2018-05-31 18:55 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-05-31  4:02 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 8679931c2c9f97ad182f8f0a9e8fab20305719b5 ***

Author: Omair Javaid <omair.javaid@linaro.org>
Branch: gdb-8.1-branch
Commit: 8679931c2c9f97ad182f8f0a9e8fab20305719b5

Unset gdbarch significant_addr_bit by default

This patch fixes a bug introduced by fix to AArch64 pointer tagging.

In our fix for tagged pointer support our agreed approach was to sign
extend user-space address after clearing tag bits. This is not same
for all architectures and this patch allows sign extension for
addresses on targets which specifically set significant_addr_bit.

More information about patch that caused the issues and discussion
around tagged pointer support can be found in links below:

https://sourceware.org/ml/gdb-patches/2018-05/msg00000.html
https://sourceware.org/ml/gdb-patches/2017-12/msg00159.html

gdb/ChangeLog:

2018-05-31  Omair Javaid  <omair.javaid@linaro.org>

	PR gdb/23210
	* gdbarch.sh (significant_addr_bit): Default to zero when
	not set by target architecture.
	* gdbarch.c: Re-generated.
	* utils.c (address_significant): Update.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] gdbserver/Windows: crash during connection establishment phase
@ 2018-05-10 19:44 sergiodj+buildbot
  2018-05-11  0:31 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-05-10 19:44 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 572797ce5f4dc697120cfd07e95553118b4f105e ***

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

gdbserver/Windows: crash during connection establishment phase

On Windows, starting a new process with GDBserver seems to work,
in the sense that the program does get started, and GDBserver
confirms that it is listening for GDB to connect. However, as soon as
GDB establishes the connection with GDBserver, and starts discussing
with it, GDBserver crashes, with a SEGV.

This SEGV occurs in remote-utils.c::prepare_resume_reply...

  | regp = current_target_desc ()->expedite_regs;
  | [...]
  | while (*regp)

... because, in our case, REGP is NULL.

This patches fixes the issues by adding a parameter to init_target_desc,
in order to make sure that we always provide the list of registers when
we initialize a target description.

gdb/ChangeLog:

        PR server/23158:
        * regformats/regdat.sh: Adjust script, following the addition
        of the new expedite_regs parameter to init_target_desc.

gdb/gdbserver/ChangeLog:

        PR server/23158:
        * tdesc.h (init_target_desc) <expedite_regs>: New parameter.
        * tdesc.c (init_target_desc) <expedite_regs>: New parameter.
        Use it to set the expedite_regs field in the given tdesc.
        * x86-tdesc.h: New file.
        * linux-aarch64-tdesc.c (aarch64_linux_read_description):
        Adjust following the addition of the new expedite_regs parameter
        to init_target_desc.
        * linux-tic6x-low.c (tic6x_read_description): Likewise.
        * linux-x86-tdesc.c: #include "x86-tdesc.h".
        (i386_linux_read_description, amd64_linux_read_description):
        Adjust following the addition of the new expedite_regs parameter
        to init_target_desc.
        * lynx-i386-low.c: #include "x86-tdesc.h".
        (lynx_i386_arch_setup): Adjust following the addition of the new
        expedite_regs parameter to init_target_desc.
        * nto-x86-low.c: #include "x86-tdesc.h".
        (nto_x86_arch_setup): Adjust following the addition of the new
        expedite_regs parameter to init_target_desc.
        * win32-i386-low.c: #include "x86-tdesc.h".
        (i386_arch_setup): Adjust following the addition of the new
        expedite_regs parameter to init_target_desc.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix tagged pointer support
@ 2018-05-10 12:45 sergiodj+buildbot
  2018-05-10 14:17 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-05-10 12:45 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 8a620990c7634e872b31718a8411a90a6f384457 ***

Author: Omair Javaid <omair.javaid@linaro.org>
Branch: gdb-8.1-branch
Commit: 8a620990c7634e872b31718a8411a90a6f384457

Fix tagged pointer support

This patch fixes tagged pointer support for AArch64 GDB. Linux kernel
debugging failure was reported after tagged pointer support was committed.

After a discussion around best path forward to manage tagged pointers
on GDB side we are going to disable tagged pointers support for
aarch64-none-elf-gdb because for non-linux applications we cant be
sure if tagged pointers will be used by MMU or not.

Also for aarch64-linux-gdb we are going to sign extend user-space
address after clearing tag bits. This will help debug both kernel
and user-space addresses based on information from linux kernel
documentation given below:

According to AArch64 memory map:
https://www.kernel.org/doc/Documentation/arm64/memory.txt

"User addresses have bits 63:48 set to 0 while the kernel addresses have
the same bits set to 1."

According to AArch64 tagged pointers document:
https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt

The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
this byte for application use.

Running gdb testsuite after applying this patch introduces no regressions
and tagged pointer test cases still pass.

gdb/ChangeLog:
2018-05-10  Omair Javaid  <omair.javaid@linaro.org>

	PR gdb/23127
	* aarch64-linux-tdep.c (aarch64_linux_init_abi): Add call to
	set_gdbarch_significant_addr_bit.
	* aarch64-tdep.c (aarch64_gdbarch_init): Remove call to
	set_gdbarch_significant_addr_bit.
	* utils.c (address_significant): Update to sign extend addr.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Fix -D_GLIBCXX_DEBUG gdb-add-index regression
@ 2018-04-12 21:16 sergiodj+buildbot
  2018-04-12 23:47 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-04-12 21:16 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 55404da3795df1b5eff514ce9d0377b6a78e5904 ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-8.1-branch
Commit: 55404da3795df1b5eff514ce9d0377b6a78e5904

Fix -D_GLIBCXX_DEBUG gdb-add-index regression

Fedora Rawhide started to use -D_GLIBCXX_DEBUG which made gdb-add-index
failing:
	gdb: Out-of-bounds vector access while running gdb-add-index
	https://bugzilla.redhat.com/show_bug.cgi?id=1540559

/usr/include/c++/7/debug/safe_iterator.h:270:
Error: attempt to dereference a past-the-end iterator.
Objects involved in the operation:
    iterator "this" @ 0x0x7fffffffcb90 {
      type = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<unsigned char*, std::__cxx1998::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > >, std::__debug::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > (mutable iterator);
      state = past-the-end;
      references sequence with type 'std::__debug::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > >' @ 0x0x7fffffffcc50
    }

/usr/include/c++/7/debug/vector:417:
Error: attempt to subscript container with out-of-bounds index 556, but
container only holds 556 elements.
Objects involved in the operation:
    sequence "this" @ 0x0x2e87af8 {
      type = std::__debug::vector<partial_symbol*, std::allocator<partial_symbol*> >;
    }

The two -D_GLIBCXX_DEBUG regressions were made by:

commit bc8f2430e08cc2a520db49a42686e0529be4a3bc
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Mon Jun 12 16:29:53 2017 +0100
    Code cleanup: C++ify .gdb_index producer

commit af5bf4ada48ff65b6658be1fab8f9c8f8ab5f319
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Sat Oct 14 08:06:29 2017 -0400
    Replace psymbol_allocation_list with std::vector

gdb/ChangeLog
2018-04-12  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR gdb/23053
	* dwarf2read.c (data_buf::grow) (write_one_signatured_type)
	(recursively_write_psymbols) (debug_names::recursively_write_psymbols)
	(debug_names::write_one_signatured_type): Fix -D_GLIBCXX_DEBUG
	regression.


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] i386: Clear vex instead of vex.evex
@ 2018-04-04 16:12 sergiodj+buildbot
  2018-04-04 16:13 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-04-04 16:12 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f13be04ec6cc83947d8c4997aa48296a915b637f ***

Author: H.J. Lu <hjl.tools@gmail.com>
Branch: gdb-8.1-branch
Commit: f13be04ec6cc83947d8c4997aa48296a915b637f

i386: Clear vex instead of vex.evex

"vex" has many fields to control how to decode an instruction.  Clear
all fields in "vex" before decoding an instruction to avoid using values
left from the previous instruction.

gas/

	PR gdb/23028
	PR binutils/23025
	* testsuite/gas/i386/prefix.s: Add tests for vcvtpd2dq with
	VEX and EVEX prefixes.
	* testsuite/gas/i386/prefix.d: Updated.

opcodes/

	PR gdb/23028
	PR binutils/23025
	* i386-dis.c (get_valid_dis386): Don't set vex.prefix nor vex.w
	to 0.
	(print_insn): Clear vex instead of vex.evex.

(cherry picked from commit caf0678c84b5b55fbc4bcc853954745a4ad8b658)


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Conditionally include "<windows.h>" on common/pathstuff.c (and unbreak build on mingw*)
@ 2018-03-02 12:58 sergiodj+buildbot
  2018-03-02 13:36 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ messages in thread
From: sergiodj+buildbot @ 2018-03-02 12:58 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a74e30b243dec8b38c8c769da04635210f9ef986 ***

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

Conditionally include "<windows.h>" on common/pathstuff.c (and unbreak build on mingw*)

commit b4987c956dfa44ca9fd8552f63e15f5fa094b2a4
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date:   Fri Feb 9 18:44:59 2018 -0500

    Create new common/pathstuff.[ch]

Introduced a regression when compiling for mingw*:

  /gdb/common/pathstuff.c: In function 'gdb::unique_xmalloc_ptr<char>
  gdb_realpath(const char*)':
  /gdb/common/pathstuff.c:56:14: error: 'MAX_PATH' was not declared in this scope
       char buf[MAX_PATH];
		^
  /gdb/common/pathstuff.c:57:5: error: 'DWORD' was not declared in this scope
       DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
       ^
  /gdb/common/pathstuff.c:57:11: error: expected ';' before 'len'
       DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
	     ^
  /gdb/common/pathstuff.c:63:9: error: 'len' was not declared in this scope
       if (len > 0 && len < MAX_PATH)
	   ^
  /gdb/common/pathstuff.c:64:54: error: 'buf' was not declared in this scope
	 return gdb::unique_xmalloc_ptr<char> (xstrdup (buf));
							^
  make[2]: *** [pathstuff.o] Error 1

The proper fix is to conditionally include "<windows.h>".  This commit
does that, without introducing any regressions as per tests made by
our BuildBot.

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

	PR gdb/22907
	* common/pathstuff.c: Conditionally include "<windows.h>".


^ permalink raw reply	[flat|nested] 35+ messages in thread
* [binutils-gdb/gdb-8.1-branch] Reset inferior::control on inferior exit
@ 2018-02-15 15:16 sergiodj+buildbot
  2018-02-17  0:16 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 13:04 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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  4:47 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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  3:47 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 19:16 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 17:28 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 19:34 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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-22 21:39 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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-22 20:35 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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  1:20 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 16:07 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 14:21 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ 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 12:37 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
  0 siblings, 1 reply; 35+ 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] 35+ messages in thread
end of thread, other threads:[~2018-07-31 21:16 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-10 19:22 [binutils-gdb/gdb-8.1-branch] gdbserver/Windows: Fix "no program to debug" error sergiodj+buildbot
2018-05-10 19:32 ` Failures on Fedora-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-05-10 20:47 ` Failures on RHEL-s390x-m64, " sergiodj+buildbot
2018-05-10 23:10 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2018-05-10 23:57 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-05-11  0:17 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2018-05-11 14:36 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2018-05-11 14:54 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-05-11 15:18 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2018-05-11 17:22 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-05-11 17:46 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2018-06-20  7:35 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot
2018-06-20  7:37 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot
2018-06-20  7:51 ` Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot
  -- strict thread matches above, loose matches on Subject: below --
2018-07-31 15:37 [binutils-gdb/gdb-8.1-branch] Set GDB version number to 8.1.1 sergiodj+buildbot
2018-07-31 21:16 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-06-09 17:45 [binutils-gdb/gdb-8.1-branch] Fix build issue with Python 3.7 sergiodj+buildbot
2018-06-09 18:18 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-05-31  4:02 [binutils-gdb/gdb-8.1-branch] Unset gdbarch significant_addr_bit by default sergiodj+buildbot
2018-05-31 18:55 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-05-10 19:44 [binutils-gdb/gdb-8.1-branch] gdbserver/Windows: crash during connection establishment phase sergiodj+buildbot
2018-05-11  0:31 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-05-10 12:45 [binutils-gdb/gdb-8.1-branch] Fix tagged pointer support sergiodj+buildbot
2018-05-10 14:17 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-04-12 21:16 [binutils-gdb/gdb-8.1-branch] Fix -D_GLIBCXX_DEBUG gdb-add-index regression sergiodj+buildbot
2018-04-12 23:47 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-04-04 16:12 [binutils-gdb/gdb-8.1-branch] i386: Clear vex instead of vex.evex sergiodj+buildbot
2018-04-04 16:13 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-03-02 12:58 [binutils-gdb/gdb-8.1-branch] Conditionally include "<windows.h>" on common/pathstuff.c (and unbreak build on mingw*) sergiodj+buildbot
2018-03-02 13:36 ` Failures on Debian-s390x-m64, branch gdb-8.1-branch sergiodj+buildbot
2018-02-15 15:16 [binutils-gdb/gdb-8.1-branch] Reset inferior::control on inferior exit sergiodj+buildbot
2018-02-17  0:16 ` Failures on Debian-s390x-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 13:04 ` Failures on Debian-s390x-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  4:47 ` Failures on Debian-s390x-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  3:47 ` Failures on Debian-s390x-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 19:16 ` Failures on Debian-s390x-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 17:28 ` Failures on Debian-s390x-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 19:34 ` Failures on Debian-s390x-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-22 21:39 ` Failures on Debian-s390x-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-22 20:35 ` Failures on Debian-s390x-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  1:20 ` Failures on Debian-s390x-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 16:07 ` Failures on Debian-s390x-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 14:21 ` Failures on Debian-s390x-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 12:37 ` Failures on Debian-s390x-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).