public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-8.2-branch] contrib/gdb-add-index.sh -dwarf-5
@ 2018-07-07 21:34 sergiodj+buildbot
  2018-07-07 21:34 ` Failures on RHEL-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
                   ` (13 more replies)
  0 siblings, 14 replies; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-07 21:34 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT dbc864ae0befb776deae11a6e420ba7f1c6b80c4 ***

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

contrib/gdb-add-index.sh -dwarf-5

------------------------------------------------------------------------------
(gdb) help save gdb-index
Save a gdb-index file.
Usage: save gdb-index [-dwarf-5] DIRECTORY

No options create one file with .gdb-index extension for pre-DWARF-5
compatible .gdb_index section.  With -dwarf-5 creates two files with
extension .debug_names and .debug_str for DWARF-5 .debug_names section.
------------------------------------------------------------------------------

But gdb-add-index command provided no way how to pass the -dwarf-5 option.

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

	* contrib/gdb-add-index.sh ($dwarf5): New, use it.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Import patch to fix PR23919 from the mainline.
@ 2019-02-26 20:27 sergiodj+buildbot
  2019-02-27  4:19 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2019-02-26 20:27 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6d33d996167a33552b68c036f1b1571a208ace42 ***

Author: Nick Clifton <nickc@redhat.com>
Branch: gdb-8.2-branch
Commit: 6d33d996167a33552b68c036f1b1571a208ace42

Import patch to fix PR23919 from the mainline.

	PR binutils/23919
bfd	* bfd.c (bfd_update_compression_header): Explicitly set alignment.
	(bfd_check_compression_header): Add uncompressed_alignment_power
	argument. Check ch_addralign is a power of 2.
	* bfd-in2.h: Regenerated.
	* compress.c (bfd_compress_section_contents): Get and set
	orig_uncompressed_alignment_pow if section is decompressed.
	(bfd_is_section_compressed_with_header): Add and get
	uncompressed_align_pow_p argument.
	(bfd_is_section_compressed): Add uncompressed_align_power argument
	to bfd_is_section_compressed_with_header call.
	(bfd_init_section_decompress_status): Get and set
	uncompressed_alignment_power.
	* elf.c (_bfd_elf_make_section_from_shdr): Add
	uncompressed_align_power argument to
	bfd_is_section_compressed_with_header call.

	* compress.c (bfd_is_section_compressed_with_header): Initialize
	* uncompressed_align_pow_p to 0.

binutils* readelf.c (dump_sections_as_strings): Remove bogus addralign check.
	(dump_sections_as_bytes): Likewise.
	(load_specific_debug_sections): Likewise.
	* testsuite/binutils-all/dw2-3.rS: Adjust alignment.
	* testsuite/binutils-all/dw2-3.rt: Likewise.

gold	* merge.cc (Output_merge_string<Char_type>::do_add_input_section):
	Get addralign from decompressed_section_contents.
	* object.cc (build_compressed_section_map): Set info.addralign.
	(Object::decompressed_section_contents): Add a palign
	argument and store p->second.addralign in *palign if it isn't
	NULL.
	* object.h (Compressed_section_info): Add addralign.
	(section_is_compressed): Add a palign argument, default it
	to NULL, store p->second.addralign in *palign if it isn't NULL.
	(Object::decompressed_section_contents): Likewise.
	* output.cc (Output_section::add_input_section): Get addralign
	from section_is_compressed.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Bump GDB version number to 8.2.1.DATE-git.
@ 2018-12-23  7:11 sergiodj+buildbot
  2018-12-23 10:30 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-12-23  7:11 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ca0560bb34ac7f194cadfe6e036f1365cf440466 ***

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

Bump GDB version number to 8.2.1.DATE-git.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Set GDB version number to 8.2.1.
@ 2018-12-23  6:42 sergiodj+buildbot
  2018-12-23  8:27 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-12-23  6:42 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 15146ff7370d5abad01dbecfacb0bf0e66a93cd6 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.2-branch
Commit: 15146ff7370d5abad01dbecfacb0bf0e66a93cd6

Set GDB version number to 8.2.1.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] gdb: Fix "info os <unknown>" command
@ 2018-12-21 19:25 sergiodj+buildbot
  2018-12-22  1:58 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-12-21 19:25 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6ef08cc9a8e7ce3f64ebbb67ea7b628129d3dc4f ***

Author: Paul Marechal <paul.marechal@ericsson.com>
Branch: gdb-8.2-branch
Commit: 6ef08cc9a8e7ce3f64ebbb67ea7b628129d3dc4f

gdb: Fix "info os <unknown>" command

Running `info os someUnknownOsType` is crashing when gdb is built with
-D_GLIBCXX_DEBUG:

	/usr/include/c++/5/debug/vector:439:error: attempt to
	access an element in an empty container.

In target_read_stralloc from target.c, the call to
target_read_alloc_1 can return an empty vector, we then call vector::back on
this vector, which is invalid.

This commit adds a check for emptiness before trying to call
vector::back on it. It also adds test to check for `info os <unknown>`
to return the proper error message.

This is a regression in gdb 8.2 and this patch restores the behavior of
previous versions.

gdb/ChangeLog:

	PR gdb/23974
	* target.c (target_read_stralloc): Check for empty vector.

gdb/testsuite/ChangeLog:

	PR gdb/23974
	* gdb.base/info-os.exp: Check return for unknown "info os" type.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix SYMBOL_LANGUAGE assertion failure on AIX.
@ 2018-12-19 11:24 sergiodj+buildbot
  2018-12-19 15:59 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-12-19 11:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT efa138468817d1d26d1a57c0c772793f31908064 ***

Author: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Branch: gdb-8.2-branch
Commit: efa138468817d1d26d1a57c0c772793f31908064

Fix SYMBOL_LANGUAGE assertion failure on AIX.

PR gdb/23999
* xcoffread.c (read_xcoff_symtab): Pass deduced language to
symtab_start instead of always using language_unknown.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix dwarf2read.c:dwarf2_find_containing_comp_unit's binary search
@ 2018-12-18 16:43 sergiodj+buildbot
  2018-12-18 17:52 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-12-18 16:43 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 438b265f3e29bf2cc6aa025295e838ccb361d148 ***

Author: Sergio Durigan Junior <sergiodj@redhat.com>
Branch: gdb-8.2-branch
Commit: 438b265f3e29bf2cc6aa025295e838ccb361d148

Fix dwarf2read.c:dwarf2_find_containing_comp_unit's binary search

First of all, I would like to express my gratitude to Keith Seitz, Jan
Kratochvil and Tom Tromey, who were really kind and helped a lot with
this bug.  The patch itself was authored by Jan.

This all began with:

  https://bugzilla.redhat.com/show_bug.cgi?id=1639242
  py-bt is broken, results in exception

In summary, the error reported by the bug above is:

  $ gdb -args python3
  GNU gdb (GDB) Fedora 8.1.1-3.fc28
  (...)
  Reading symbols from python3...Reading symbols from /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug...done.
  done.
  Dwarf Error: could not find partial DIE containing offset 0x316 [in module /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug]

After a long investigation, and after thinking that the problem might
actually be on DWZ's side, we were able to determine that there's
something wrong going on when
dwarf2read.c:dwarf2_find_containing_comp_unit performs a binary search
over all of the CUs belonging to an objfile in order to find the CU
which contains a DIE at an specific offset.  The current algorithm is:

  static struct dwarf2_per_cu_data *
  dwarf2_find_containing_comp_unit (sect_offset sect_off,
				    unsigned int offset_in_dwz,
				    struct dwarf2_per_objfile *dwarf2_per_objfile)
  {
    struct dwarf2_per_cu_data *this_cu;
    int low, high;
    const sect_offset *cu_off;

    low = 0;
    high = dwarf2_per_objfile->all_comp_units.size () - 1;
    while (high > low)
      {
	struct dwarf2_per_cu_data *mid_cu;
	int mid = low + (high - low) / 2;

	mid_cu = dwarf2_per_objfile->all_comp_units[mid];
	cu_off = &mid_cu->sect_off;
	if (mid_cu->is_dwz > offset_in_dwz
	    || (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off))
	  high = mid;
	else
	  low = mid + 1;
      }

For the sake of this example, let's consider that "sect_off =
0x7d".

There are a few important things going on here.  First,
"dwarf2_per_objfile->all_comp_units ()" will be sorted first by
whether the CU is a DWZ CU, and then by cu->sect_off.  In this
specific bug, "offset_in_dwz" is false, which means that, for the most
part of the loop, we're going to do "high = mid" (i.e, we'll work with
the lower part of the vector).

In our particular case, when we reach the part where "mid_cu->is_dwz
== offset_in_dwz" (i.e, both are false), we end up with "high = 2" and
"mid = 1".  I.e., there are only 2 elements in the vector who are not
DWZ.  The vector looks like this:

  #0: cu->sect_off = 0;   length = 114;  is_dwz = false  <-- low
  #1: cu->sect_off = 114; length = 7796; is_dwz = false  <-- mid
  #2: cu->sect_off = 0;   length = 28;   is_dwz = true   <-- high
  ...

The CU we want is #1, which is exactly where "mid" is.  Also, #1 is
not DWZ, which is also exactly what we want.  So we perform the second
comparison:

  (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off)
                                      ^^^^^^^^^^^^^^^^^^^

Because "*cu_off = 114" and "sect_off = 0x7d", this evaluates to
false, so we end up with "low = mid + 1 = 2", which actually gives us
the wrong CU (i.e., a CU that is DWZ).  Next in the code, GDB does:

    gdb_assert (low == high);
    this_cu = dwarf2_per_objfile->all_comp_units[low];
    cu_off = &this_cu->sect_off;
    if (this_cu->is_dwz != offset_in_dwz || *cu_off > sect_off)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      {
	if (low == 0 || this_cu->is_dwz != offset_in_dwz)
	  error (_("Dwarf Error: could not find partial DIE containing "
		 "offset %s [in module %s]"),
		 sect_offset_str (sect_off),
		 bfd_get_filename (dwarf2_per_objfile->objfile->obfd));
	...

Triggering the error we saw in the original bug report.

It's important to notice that we see the error message because the
selected CU is a DWZ one, but we're looking for a non-DWZ CU here.
However, even when the selected CU is *not* a DWZ (and we don't see
any error message), we still end up with the wrong CU.  For example,
suppose that the vector had:

  #0: cu->sect_off = 0;    length = 114;  is_dwz = false
  #1: cu->sect_off = 114;  length = 7796; is_dwz = false
  #2: cu->sect_off = 7910; length = 28;   is_dwz = false
  ...

I.e., #2's "is_dwz" is false instead of true.  In this case, we still
want #1, because that's where the DIE is located.  After the loop ends
up in #2, we have "is_dwz" as false, which is what we wanted, so we
compare offsets.  In this case, "7910 >= 0x7d", so we set "mid = high
= 2".  Next iteration, we have "mid = 0 + (2 - 0) / 2 = 1", and thus
we examining #1.  "is_dwz" is still false, but "114 >= 0x7d" also
evaluates to false, so "low = mid + 1 = 2", which makes the loop stop.
Therefore, we end up choosing #2 as our CU, even though #1 is the
right one.

The problem here is happening because we're comparing "sect_off"
directly against "*cu_off", while we should actually be comparing
against "*cu_off + mid_cu->length" (i.e., the end offset):

  ...
  || (mid_cu->is_dwz == offset_in_dwz
      && *cu_off + mid_cu->length >= sect_off))
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ...

And this is what the patch does.  The idea is that if GDB is searching
for an offset that falls above the *end* of the CU being
analyzed (i.e., "mid"), then the next iteration should try a
higher-offset CU next.  The previous algorithm was using
the *beginning* of the CU.

Unfortunately, I could not devise a testcase for this problem, so I am
proposing a fix with this huge explanation attached to it in the hope
that it is sufficient.  After talking a bit to Keith (our testcase
guru), it seems that one would have to create an objfile with both DWZ
and non-DWZ sections, which may prove very hard to do, I think.

I ran this patch on our BuildBot, and no regressions were detected.

gdb/ChangeLog:
2018-11-30  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Keith Seitz  <keiths@redhat.com>
	    Tom Tromey  <tom@tromey.com>
	    Sergio Durigan Junior  <sergiodj@redhat.com>

	https://bugzilla.redhat.com/show_bug.cgi?id=1613614
	PR gdb/24003
	* dwarf2read.c (dwarf2_find_containing_comp_unit): Add
	'mid_cu->length' to '*cu_off' when checking if 'sect_off' is
	inside the CU.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Make command-repeat work after gdb.execute
@ 2018-11-21 18:19 sergiodj+buildbot
  2018-11-22  2:42 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-11-21 18:19 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7d9e516326ff542b3c9c85a3c08be2622d9126b6 ***

Author: Benno Fnfstck <benno.fuenfstueck@gmail.com>
Branch: gdb-8.2-branch
Commit: 7d9e516326ff542b3c9c85a3c08be2622d9126b6

Make command-repeat work after gdb.execute

Since commit

  56bcdbea2bed ("Let gdb.execute handle multi-line commands")

command repetition after using the `gdb.execute` Python function
fails (the previous command is not repeated anymore). This happens
because read_command_lines_1 sets dont_repeat, but the call to
prevent_dont_repeat in execute_gdb_command is later.

The fix is to move the call to prevent_dont_repeat to the beginning of
the function.

Tested on my laptop (ArchLinux-x86_64).

gdb/ChangeLog:

	PR python/23714
	* gdb/python/python.c (execute_gdb_command): Call
	prevent_dont_repeat earlier to avoid affecting dont_repeat.

gdb/testuite/ChangeLog:

	PR python/23714
	* gdb.python/python.exp: Test command repetition after
	gdb.execute.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] gdb.base/warning.exp tweaks
@ 2018-11-19 19:20 sergiodj+buildbot
  2018-11-20  0:17 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-11-19 19:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 52ec8c2b0264127d8e7468ab28a0ee079ebc487f ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-8.2-branch
Commit: 52ec8c2b0264127d8e7468ab28a0ee079ebc487f

gdb.base/warning.exp tweaks

#1- Check that the warning is emitted.

#2- Avoid overriding INTERNAL_GDBFLAGS, as per documentated in
    gdb/testsuite/README:

 ~~~
 The testsuite does not override a value provided by the user.
 ~~~

We don't actually need to tweak INTERNAL_GDBFLAGS, we just need to
append out -data-directory to GDBFLAGS, because each passed
-data-directory option leads to a call to the warning:

 $ ./gdb -data-directory=foo -data-directory=bar
 Warning: foo: No such file or directory.
 Warning: bar: No such file or directory.
 [...]

2018-11-19  Pedro Alves  <palves@redhat.com>

	* gdb.base/warning.exp: Don't override INTERNAL_FLAGS.  Use
	gdb_spawn_with_cmdline_opts instead of gdb_start.  Check that we
	see the expected warning.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Avoid crash when calling warning too early
@ 2018-11-19 19:08 sergiodj+buildbot
  2018-11-19 22:42 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-11-19 19:08 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 9ec912f34410c33de581b5af4a0773c12b4fe20a ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: 9ec912f34410c33de581b5af4a0773c12b4fe20a

Avoid crash when calling warning too early

I noticed that if you pass the name of an existing file (not a
directory) as the argument to --data-directory, gdb will crash:

    $ ./gdb -nx  --data-directory  ./gdb
    ../../binutils-gdb/gdb/target.c:590:56: runtime error: member call on null pointer of type 'struct target_ops'

This was later reported as PR gdb/23838.

This happens because warning ends up calling
target_supports_terminal_ours, which calls current_top_target, which
returns nullptr this early.

This fixes the problem by handling this case specially in
target_supports_terminal_ours.  I also changed
target_supports_terminal_ours to return bool.

2018-11-08  Tom Tromey  <tom@tromey.com>

	PR gdb/23555:
	PR gdb/23838:
	* target.h (target_supports_terminal_ours): Return bool.
	* target.c (target_supports_terminal_ours): Handle case where
	current_top_target returns nullptr.  Return bool.

gdb/testsuite/ChangeLog
2018-11-08  Tom Tromey  <tom@tromey.com>

	PR gdb/23555:
	PR gdb/23838:
	* gdb.base/warning.exp: New file.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] python: Make gdb.execute("show commands") work (PR 23669)
@ 2018-09-18 16:29 sergiodj+buildbot
  2018-09-19  6:31 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-18 16:29 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT b13ab533d38674e6273eb78eeef261d5b0655bbf ***

Author: Simon Marchi <simon.marchi@polymtl.ca>
Branch: gdb-8.2-branch
Commit: b13ab533d38674e6273eb78eeef261d5b0655bbf

python: Make gdb.execute("show commands") work (PR 23669)

Since commit

  56bcdbea2bed ("Let gdb.execute handle multi-line commands")

trying to use a command like gdb.execute("show commands") in Python
fails.  GDB ends up trying to run the "commands" command.

The reason is that GDB gets confused with the special "commands"
command.  In process_next_line, the lookup_cmd_1 function returns the
cmd_list_element representing the "commands" sub-command of "show".
Lower, we check the cmd_list_element to see if it matches various
control commands by name, including the "commands" command.  This is
where we wrongfully conclude that the executed command must be
"commands", when in reality it was "show commands".

The fix proposed in this patch removes the comparisons by name, instead
comparing the cmd_list_element object by pointer with the objects
created at initialization time.

Tested on the buildbot, though on a single builder (Fedora-x86_64-m64).

gdb/ChangeLog:

	PR python/23669
	* breakpoint.c (commands_cmd_element): New.
	(_initialize_breakpoint): Assign commands_cmd_element.
	* breakpoint.h (commands_cmd_element): New.
	* cli/cli-script.c (while_cmd_element, if_command,
	define_cmd_element): New.
	(command_name_equals): Remove.
	(process_next_line): Compare commands by pointer, not by name.
	(_initialize_cli_script): Assign the various cmd_list_element
	variables.
	* compile/compile.c (compile_cmd_element): New.
	(_initialize_compile): Assign compile_cmd_element.
	* compile/compile.h (compile_cmd_element): New.
	* guile/guile.c (guile_cmd_element): New.
	(install_gdb_commands): Assign guile_cmd_element.
	* guile/guile.h (guile_cmd_element): New.
	* python/python.c (python_cmd_element): New.
	(_initialize_python): Assign python_cmd_element.
	* python/python.h (python_cmd_element): New.
	* tracepoint.c (while_stepping_cmd_element): New.
	(_initialize_tracepoint): Assign while_stepping_cmd_element.
	* tracepoint.h (while_stepping_cmd_element): New.

gdb/testsuite/ChangeLog:

	PR python/23669
	* gdb.python/python.exp: Test gdb.execute("show commands").


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Move 'is_regular_file' from common-utils.c to filestuff.c
@ 2018-09-16 23:49 sergiodj+buildbot
  2018-09-17 12:56 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-16 23:49 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5de69bdbd0bbd7941b4cd93d4571f5e22cdb28be ***

Author: Sergio Durigan Junior <sergiodj@redhat.com>
Branch: gdb-8.2-branch
Commit: 5de69bdbd0bbd7941b4cd93d4571f5e22cdb28be

Move 'is_regular_file' from common-utils.c to filestuff.c

There is no reason for 'is_regular_file' to be in common-utils.c; it
belongs to 'filestuff.c'.  This commit moves the function definition
and its prototype to the appropriate files.

The motivation behind this move is a failure that happens on certain
cross-compilation environments when compiling the IPA library, due to
the way gnulib probes the need for a 'stat' call replacement.  Because
configure checks when cross-compiling are more limited, gnulib decides
that it needs to substitute the 'stat' calls its own 'rpl_stat';
however, the IPA library doesn't link with gnulib, which leads to an
error when compiling 'common-utils.c':

  ...
  /opt/x86-core2--musl--bleeding-edge-2018.09-1/bin/i686-buildroot-linux-musl-g++  -shared -fPIC -Wl,--soname=libinproctrace.so -Wl,--no-undefined -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os      -I. -I. -I./../common -I./../regformats -I./.. -I./../../include -I./../gnulib/import -Ibuild-gnulib-gdbserver/import -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized  -DGDBSERVER \
   -Wl,--dynamic-list=./proc-service.list -o libinproctrace.so ax-ipa.o common-utils-ipa.o errors-ipa.o format-ipa.o print-utils-ipa.o regcache-ipa.o remote-utils-ipa.o rsp-low-ipa.o tdesc-ipa.o tracepoint-ipa.o utils-ipa.o vec-ipa.o linux-i386-ipa.o linux-x86-tdesc-ipa.o arch/i386-ipa.o -ldl -pthread
  /opt/x86-core2--musl--bleeding-edge-2018.09-1/lib/gcc/i686-buildroot-linux-musl/8.2.0/../../../../i686-buildroot-linux-musl/bin/ld: common-utils-ipa.o: in function `is_regular_file(char const*, int*)':
  common-utils.c:(.text+0x695): undefined reference to `rpl_stat'
  collect2: error: ld returned 1 exit status
  Makefile:413: recipe for target 'libinproctrace.so' failed
  make[1]: *** [libinproctrace.so] Error 1
  ...

More details can also be found at:

  https://sourceware.org/ml/gdb-patches/2018-09/msg00304.html

The most simple fix for this problem is to move 'is_regular_file' to
'filestuff.c', which is not used by IPA.  This ends up making the
files more logically organized as well, since 'is_regular_file' is a
file operation.

No regressions found.

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

	PR gdb/23663
	* common/common-utils.c: Don't include '<sys/stat.h>'.
	(is_regular_file): Move to...
	* common/filestuff.c (is_regular_file): ... here.
	* common/common-utils.h (is_regular_file): Move to...
	* common/filestuff.h (is_regular_file): ... here.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Make Rust error message mention the field name
@ 2018-09-14  9:41 sergiodj+buildbot
  2018-09-16  7:33 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-14  9:41 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT fde24e1a534b7df3edd0fc167d0ace7d240021f8 ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: fde24e1a534b7df3edd0fc167d0ace7d240021f8

Make Rust error message mention the field name

I noticed a spot in rust-lang.c where the placeholder "foo" was used
instead of the actual field name.  This patch fixes the bug.

2018-09-13  Tom Tromey  <tom@tromey.com>

	PR rust/23650:
	* rust-lang.c (rust_evaluate_subexp): Use field name, not "foo".

gdb/testsuite/ChangeLog
2018-09-13  Tom Tromey  <tom@tromey.com>

	PR rust/23650:
	* gdb.rust/simple.exp: Add test for enum field access error.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix "make install-strip" failure to install gdb-add-index.sh
@ 2018-09-12 18:25 sergiodj+buildbot
  2018-09-12 23:23 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-12 18:25 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7c09445cf887b2501ce33e47cdd0d1c2545b6934 ***

Author: Eli Zaretskii <eliz@gnu.org>
Branch: gdb-8.2-branch
Commit: 7c09445cf887b2501ce33e47cdd0d1c2545b6934

Fix "make install-strip" failure to install gdb-add-index.sh

gdb/ChangeLog:
2018-09-10  Eli Zaretskii  <eliz@gnu.org>

	* Makefile.in (transformed_name): Use INSTALL_SCRIPT instead of
	INSTALL_PROGRAM to install gdb-add-index.sh.  Don't append
	$(EXEEXT) to the script, as it is not a program.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Bump GDB version number to 8.2.0.DATE-git.
@ 2018-09-06 22:40 sergiodj+buildbot
  2018-09-07  0:16 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-06 22:40 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT f0b71378f1e781945a8b05061114fce5af9e2f12 ***

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

Bump GDB version number to 8.2.0.DATE-git.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Set GDB version number to 8.2.
@ 2018-09-06 16:39 sergiodj+buildbot
  2018-09-06 22:16 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-06 16:39 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 00f223631fa9803b783515a2f667f86997e2cdbe ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.2-branch
Commit: 00f223631fa9803b783515a2f667f86997e2cdbe

Set GDB version number to 8.2.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Set TYPE_LENGTH on a variant part
@ 2018-09-01  4:20 sergiodj+buildbot
  2018-09-01  7:58 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-09-01  4:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT c07c917f276d6e055a4e6ba5be5d6b9c4d355de7 ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: c07c917f276d6e055a4e6ba5be5d6b9c4d355de7

Set TYPE_LENGTH on a variant part

gdb represents a DW_TAG_variant_part as a union.  While normally DWARF
would not set the size of a DW_TAG_variant_part, gdb's representation
requires the TYPE_LENGTH to be set.

This patch arranges to set the TYPE_LENGTH of a variant part if it has
not already been set.

This fixes some Rust regressions when testing against a version of
rustc that emits DW_TAG_variant_part.

2018-08-31  Tom Tromey  <tom@tromey.com>

	* dwarf2read.c (dwarf2_add_field): Set the TYPE_LENGTH of the
	variant part type.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Modify gdb.base/commands.exp to test multi breakpoints command clearing.
@ 2018-08-29  1:20 sergiodj+buildbot
  2018-08-29 13:12 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-29  1:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 145a1cb045dcb73002e06d33f011d9185502e3c4 ***

Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Branch: gdb-8.2-branch
Commit: 145a1cb045dcb73002e06d33f011d9185502e3c4

Modify gdb.base/commands.exp to test multi breakpoints command clearing.

gdb/testsuite/ChangeLog
2018-08-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* gdb.base/commands.exp: Test multi breakpoints command clearing.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix regression for multi breakpoints command line clearing.
@ 2018-08-29  0:54 sergiodj+buildbot
  2018-08-29 12:55 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-29  0:54 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5dc5ecd1fde2c3eba2f0c870ad12c4cb120224d0 ***

Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Branch: gdb-8.2-branch
Commit: 5dc5ecd1fde2c3eba2f0c870ad12c4cb120224d0

Fix regression for multi breakpoints command line clearing.

breakpoint.c is modified to fix the regression introduced
when clearing the commands of several breakpoints by giving an empty
list of commands, by just typing "end".
GDB should read an empty list of command once, but it reads
it for each breakpoint, as an empty list of command is NULL,
and NULL is interpreted as 'not having read the command list yet'.

The fix consists in having a boolean set to true once the
command list has been read.

gdb/ChangeLog

2018-08-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* breakpoint.c (commands_command_1): New boolean cmd_read
	to detect cmd was already read.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Parse SVE registers in aarch64 core file reading/writing
@ 2018-08-28 12:52 sergiodj+buildbot
  2018-08-28 16:51 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-28 12:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT fec2cf3421a5195353499d95d340ee002fa5ef9e ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: fec2cf3421a5195353499d95d340ee002fa5ef9e

Parse SVE registers in aarch64 core file reading/writing

sve_regmap cannot be global static as the size is dependant on the current
vector length.

gdb/
	* aarch64-linux-tdep.c (aarch64_linux_supply_sve_regset): New function.
	(aarch64_linux_collect_sve_regset): Likewise.
	(aarch64_linux_iterate_over_regset_sections): Check for SVE.
	* regcache.h (regcache_map_entry_size): New function.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Detect SVE when reading aarch64 core files
@ 2018-08-28 12:25 sergiodj+buildbot
  2018-08-28 15:26 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-28 12:25 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT fb20254d1ac83c182daf37698fdcf281c24e08f3 ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: fb20254d1ac83c182daf37698fdcf281c24e08f3

Detect SVE when reading aarch64 core files

The SVE section in a core file contains a header followed by the registers.
Add defines to easily access the header fields within a buffer.

gdb/
	* aarch64-linux-tdep.c (SVE_HEADER_SIZE_LENGTH): Add define.
	(SVE_HEADER_MAX_SIZE_LENGTH): Likewise.
	(SVE_HEADER_VL_LENGTH): Likewise.
	(SVE_HEADER_MAX_VL_LENGTH): Likewise.
	(SVE_HEADER_FLAGS_LENGTH): Likewise.
	(SVE_HEADER_RESERVED_LENGTH): Likewise.
	(SVE_HEADER_SIZE_OFFSET): Likewise.
	(SVE_HEADER_MAX_SIZE_OFFSET): Likewise.
	(SVE_HEADER_VL_OFFSET): Likewise.
	(SVE_HEADER_MAX_VL_OFFSET): Likewise.
	(SVE_HEADER_FLAGS_OFFSET): Likewise.
	(SVE_HEADER_RESERVED_OFFSET): Likewise.
	(SVE_HEADER_SIZE): Likewise.
	(aarch64_linux_core_read_vq): Add function.
	(aarch64_linux_core_read_description): Check for SVE section.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Split size in regset section iterators
@ 2018-08-28 12:05 sergiodj+buildbot
  2018-08-28 14:17 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-28 12:05 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT bf0f22c10f0cb035836aa31c3b11e0e09c57e604 ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: bf0f22c10f0cb035836aa31c3b11e0e09c57e604

Split size in regset section iterators

In the existing code, when using the regset section iteration functions, the
size parameter is used in different ways.

With collect, size is used to create the buffer in which to write the regset.
(see linux-tdep.c::linux_collect_regset_section_cb).

With supply, size is used to confirm the existing regset is the correct size.
If REGSET_VARIABLE_SIZE is set then the regset can be bigger than size.
Effectively, size is the minimum possible size of the regset.
(see corelow.c::get_core_register_section).

There are currently no targets with both REGSET_VARIABLE_SIZE and a collect
function.
In SVE, a corefile can contain one of two formats after the header, both of
which are different sizes. However, when writing a core file, we always want
to write out the full bigger size.

To allow support of collects for REGSET_VARIABLE_SIZE we need two sizes.
This is done by adding supply_size and collect_size.

gdb/

	* aarch64-fbsd-tdep.c
	(aarch64_fbsd_iterate_over_regset_sections): Add supply_size and
	collect_size.
	* aarch64-linux-tdep.c
	(aarch64_linux_iterate_over_regset_sections): Likewise.
	* alpha-linux-tdep.c
	(alpha_linux_iterate_over_regset_sections):
	* alpha-nbsd-tdep.c
	(alphanbsd_iterate_over_regset_sections): Likewise.
	* amd64-fbsd-tdep.c
	(amd64fbsd_iterate_over_regset_sections): Likewise.
	* amd64-linux-tdep.c
	(amd64_linux_iterate_over_regset_sections): Likewise.
	* arm-bsd-tdep.c
	(armbsd_iterate_over_regset_sections): Likewise.
	* arm-fbsd-tdep.c
	(arm_fbsd_iterate_over_regset_sections): Likewise.
	* arm-linux-tdep.c
	(arm_linux_iterate_over_regset_sections): Likewise.
	* corelow.c (get_core_registers_cb): Likewise.
	(core_target::fetch_registers): Likewise.
	* fbsd-tdep.c (fbsd_collect_regset_section_cb): Likewise.
	* frv-linux-tdep.c (frv_linux_iterate_over_regset_sections): Likewise.
	* gdbarch.h (void): Regenerate.
	* gdbarch.sh: Add supply_size and collect_size.
	* hppa-linux-tdep.c (hppa_linux_iterate_over_regset_sections): Likewise.
	* hppa-nbsd-tdep.c (hppanbsd_iterate_over_regset_sections): Likewise.
	* hppa-obsd-tdep.c (hppaobsd_iterate_over_regset_sections): Likewise.
	* i386-fbsd-tdep.c (i386fbsd_iterate_over_regset_sections): Likewise.
	* i386-linux-tdep.c (i386_linux_iterate_over_regset_sections): Likewise.
	* i386-tdep.c (i386_iterate_over_regset_sections): Likewise.
	* ia64-linux-tdep.c (ia64_linux_iterate_over_regset_sections): Likewise.
	* linux-tdep.c (linux_collect_regset_section_cb): Likewise.
	* m32r-linux-tdep.c (m32r_linux_iterate_over_regset_sections): Likewise.
	* m68k-bsd-tdep.c (m68kbsd_iterate_over_regset_sections): Likewise.
	* m68k-linux-tdep.c (m68k_linux_iterate_over_regset_sections): Likewise.
	* mips-fbsd-tdep.c (mips_fbsd_iterate_over_regset_sections): Likewise.
	* mips-linux-tdep.c (mips_linux_iterate_over_regset_sections): Likewise.
	* mips-nbsd-tdep.c (mipsnbsd_iterate_over_regset_sections): Likewise.
	* mips64-obsd-tdep.c (mips64obsd_iterate_over_regset_sections): Likewise.
	* mn10300-linux-tdep.c (am33_iterate_over_regset_sections): Likewise.
	* nios2-linux-tdep.c (nios2_iterate_over_regset_sections): Likewise.
	* ppc-fbsd-tdep.c (ppcfbsd_iterate_over_regset_sections): Likewise.
	* ppc-linux-tdep.c (ppc_linux_iterate_over_regset_sections): Likewise.
	* ppc-nbsd-tdep.c (ppcnbsd_iterate_over_regset_sections): Likewise.
	* ppc-obsd-tdep.c (ppcobsd_iterate_over_regset_sections): Likewise.
	* rs6000-aix-tdep.c (rs6000_aix_iterate_over_regset_sections): Likewise.
	* s390-linux-tdep.c (s390_iterate_over_regset_sections): Likewise.
	* score-tdep.c (score7_linux_iterate_over_regset_sections): Likewise.
	* sh-tdep.c (sh_iterate_over_regset_sections): Likewise.
	* sparc-tdep.c (sparc_iterate_over_regset_sections): Likewise.
	* tilegx-linux-tdep.c (tilegx_iterate_over_regset_sections): Likewise.
	* vax-tdep.c (vax_iterate_over_regset_sections): Likewise.
	* xtensa-tdep.c (xtensa_iterate_over_regset_sections): Likewise.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Rename size in get_core_register_section
@ 2018-08-28 11:55 sergiodj+buildbot
  2018-08-28 12:55 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-28 11:55 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT d29c8c214cb296e0e20f6e88f27535c340ca98db ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: d29c8c214cb296e0e20f6e88f27535c340ca98db

Rename size in get_core_register_section

Make it clearer that the size field indicates the size of the section.

gdb/

	* corelow.c (core_target::get_core_register_section): Rename
	min_size to section_min_size.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Restore behavior of disabling address randomization by default on GDBserver
@ 2018-08-26 18:25 sergiodj+buildbot
  2018-08-26 22:42 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-26 18:25 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 83b6e2e989510db105c52a02c490ab2c284b5469 ***

Author: Simon Marchi <simon.marchi@ericsson.com>
Branch: gdb-8.2-branch
Commit: 83b6e2e989510db105c52a02c490ab2c284b5469

Restore behavior of disabling address randomization by default on GDBserver

Commit

  c12a508 ("Add client_state struct.")

inadvertently changed the default behavior of GDBserver wrt address
randomization.  The old disable_randomization global variable was
initialized to 1, whereas the corresponding field in the client_state
structure is initialized to 0.

This fixes

  make check TESTS="gdb.base/jit-simple.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
  make check TESTS="gdb.base/execl-update-breakpoints.exp" RUNTESTFLAGS="--target_board=native-gdbserver"

Note that the execl-update-breakpoints.exp would only fail on systems
where the toolchain emits position-independent executables by default
(otherwise the main executable position is never randomized, so the
value of disable_randomization didn't matter).

gdb/gdbserver/ChangeLog:

	PR gdb/23374
	PR gdb/23375
	* server.h (struct client_state) <disable_randomization>:
	Initialize to 1.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Initialize variable in py_get_event_thread
@ 2018-08-25 22:47 sergiodj+buildbot
  2018-08-26 12:18 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 22:47 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT c6f50f8869ac0dd10040f5c32387eb404f9ff50a ***

Author: Simon Marchi <simon.marchi@polymtl.ca>
Branch: gdb-8.2-branch
Commit: c6f50f8869ac0dd10040f5c32387eb404f9ff50a

Initialize variable in py_get_event_thread

The pythread variable could be used without being initialized, fix it by
initializing it to nullptr.

gdb/ChangeLog:

	* python/py-threadevent.c (py_get_event_thread): Initialize
	pythread.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Test case for functions with non-contiguous ranges
@ 2018-08-25 12:24 sergiodj+buildbot
  2018-08-25 22:51 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 12:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6518e6562b56b258c4933fcb8bce057215544a8f ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: 6518e6562b56b258c4933fcb8bce057215544a8f

Test case for functions with non-contiguous ranges

See comments in the new files for what this is about - I tried to
explain it all there.

gdb/testsuite/ChangeLog:

	* gdb.dwarf2/dw2-ranges-func.c: New file.
	* gdb.dwarf2/dw2-ranges-func.exp: New file.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Relocate block range start and end addresses
@ 2018-08-25 11:56 sergiodj+buildbot
  2018-08-25 20:22 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 11:56 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT cb0f34520d4e4ad233696a293d69c979418f3ccd ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: cb0f34520d4e4ad233696a293d69c979418f3ccd

Relocate block range start and end addresses

gdb/ChangeLog:

	* objfiles.c (objfile_relocate1): Relocate start and end addresses
	for each range in a block.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Introduce find_function_entry_range_from_pc and use it in infrun.c
@ 2018-08-25 11:51 sergiodj+buildbot
  2018-08-25 16:46 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 11:51 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 65a1b8803a0d3a3a4f3fce3b289dc4a06048d5f2 ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: 65a1b8803a0d3a3a4f3fce3b289dc4a06048d5f2

Introduce find_function_entry_range_from_pc and use it in infrun.c

An earlier version of this patch used the returned block in conjunction
with BLOCK_ENTRY_PC to set stop_func_start in fill_in_stop_func() in
infrun.c.  While I think this was the correct thing to do, changes
to find_inferior_partial_function could potentially end up with
stop_func_end < stop_func_start, which is definitely wrong.  For
this case, we want to set both stop_func_start and stop_func_end
to the start and end of the range containing the function's entry
pc.

I think that this functionality will be useful in many other places
too - it probably ought to be used in all of the various prologue
analyzers in GDB.

The change to infrun.c was simple: the call to
find_pc_partial_function was replaced with a call to
find_function_entry_range_from_pc.  The difference between these two
functions is that find_pc_partial_entry_function will (potentially)
return the start and end address corresponding to the range in which
PC is found, but find_function_entry_range_from_pc will (again,
potentially) return the start and end address of the range containing
the entry pc.  find_pc_partial_function has the property that
*ADDRESS <= PC < *ENDADDR.  This condition does not necessarily hold
for the outputs of find_function_entry_range_from_pc.

It should be noted that for functions which contain only a single
range, the outputs of find_pc_partial_function and
find_function_entry_range_from_pc are identical.

I think it might happen that find_function_entry_range_from_pc will come
to be used in place of many of the calls to find_pc_partial_function
within GDB.  Care must be taken in making this change, however, since
some of this code depends on the *ADDRESS <= PC < *ENDADDR property.

Finally, a note regarding the name: I had initially chosen a different
name with a find_pc_partial_ prefix, but Simon suggested the current
name citing the goal of eventually making naming consistent using
the form find_X_from_Y.  In this case X is "function_entry_range" and
Y is "pc".  Both the name and rationale made sense to me, so that's
how it came to be.

gdb/ChangeLog:

	* infrun.c (fill_in_stop_func): Use find_function_entry_range_from_pc
	in place of find_pc_partial_function.
	* blockframe.c (find_function_entry_range_from_pc): New function.
	* symtab.h (find_function_entry_range_from_pc): Declare and document.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Use BLOCK_ENTRY_PC in place of most uses of BLOCK_START
@ 2018-08-25 11:16 sergiodj+buildbot
  2018-08-25 15:34 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 11:16 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 84b14f21ca4257a882a28ba1cbd49dbbcea555db ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: 84b14f21ca4257a882a28ba1cbd49dbbcea555db

Use BLOCK_ENTRY_PC in place of most uses of BLOCK_START

This change/patch substitues BLOCK_ENTRY_PC for BLOCK_START in
places where BLOCK_START is used to obtain the address at which
execution should enter the block.  Since blocks can now contain
non-contiguous ranges, the BLOCK_START - which is still be the
very lowest address in the block - might not be the same as
BLOCK_ENTRY_PC.

There is a change to infrun.c which is less obvious and less mechanical.
I'm posting it as a separate patch.

gdb/ChangeLog:

	* ax-gdb.c (gen_var_ref): Use BLOCK_ENTRY_PC in place of
	BLOCK_START.
	* blockframe.c (get_pc_function_start): Likewise.
	* compile/compile-c-symbols.c (convert_one_symbol): Likewise.
	(gcc_symbol_address): Likewise.
	* compile/compile-object-run.c (compile_object_run): Likewise.
	* compile/compile.c (get_expr_block_and_pc): Likewise.
	* dwarf2loc.c (dwarf2_find_location_expression): Likewise.
	(func_addr_to_tail_call_list): Likewise.
	* findvar.c (default_read_var_value): Likewise.
	* inline-frame.c (inline_frame_this_id): Likewise.
	(skip-inline_frames): Likewise.
	* infcmd.c (until_next_command): Likewise.
	* linespec.c (convert_linespec_to_sals): Likewise.
	* parse.c (parse_exp_in_context_1): Likewise.
	* printcmd.c (build_address_symbolic): likewise.
	(info_address_command): Likewise.
	symtab.c (find_function_start_sal): Likewise.
	(skip_prologue_sal): Likewise.
	(find_function_alias_target): Likewise.
	(find_gnu_ifunc): Likewise.
	* stack.c (find_frame_funname): Likewise.
	* symtab.c (fixup_symbol_section): Likewise.
	(find_function_start_sal): Likewise.
	(skip_prologue_sal): Likewsie.
	(find_function_alias_target): Likewise.
	(find_gnu_ifunc): Likewise.
	* tracepoint.c (info_scope_command): Likewise.
	* value.c (value_fn_field): Likewise.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Disassemble blocks with non-contiguous ranges
@ 2018-08-25 11:13 sergiodj+buildbot
  2018-08-25 14:53 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 11:13 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 9fef689604c87f695e947a52a6eff7da4f13a0f8 ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: 9fef689604c87f695e947a52a6eff7da4f13a0f8

Disassemble blocks with non-contiguous ranges

This patch adds support for disassembly of blocks with non-contiguous
ranges.  These blocks are printed as follows:

(gdb) disassemble foo
Dump of assembler code for function foo:
Address range 0x401136 to 0x401151:
   0x0000000000401136 <+0>:     push   %rbp
   0x0000000000401137 <+1>:     mov    %rsp,%rbp
   0x000000000040113a <+4>:     callq  0x401134 <bar>
   0x000000000040113f <+9>:     mov    0x2eef(%rip),%eax        # 0x404034 <e>
   0x0000000000401145 <+15>:    test   %eax,%eax
   0x0000000000401147 <+17>:    je     0x40114e <foo+24>
   0x0000000000401149 <+19>:    callq  0x401128 <foo+4294967282>
   0x000000000040114e <+24>:    nop
   0x000000000040114f <+25>:    pop    %rbp
   0x0000000000401150 <+26>:    retq
Address range 0x401128 to 0x401134:
   0x0000000000401128 <+-14>:   push   %rbp
   0x0000000000401129 <+-13>:   mov    %rsp,%rbp
   0x000000000040112c <+-10>:   callq  0x401126 <baz>
   0x0000000000401131 <+-5>:    nop
   0x0000000000401132 <+-4>:    pop    %rbp
   0x0000000000401133 <+-3>:    retq
End of assembler dump.

This is an actual dump from the test case that I constructed for
this work.  The ranges are printed in the order encountered in the
debug info. For the above example, note that the second range occupies
lower addresses than the first range.

Functions with contiguous ranges are still printed as follows:

(gdb) disassemble main
Dump of assembler code for function main:
   0x0000000000401151 <+0>:     push   %rbp
   0x0000000000401152 <+1>:     mov    %rsp,%rbp
   0x0000000000401155 <+4>:     callq  0x401136 <foo>
   0x000000000040115a <+9>:     mov    $0x0,%eax
   0x000000000040115f <+14>:    pop    %rbp
   0x0000000000401160 <+15>:    retq
End of assembler dump.

gdb/ChangeLog:

	* cli/cli-cmds.c (block.h): Include.
	(print_disassembly): Handle printing of non-contiguous blocks.
	(disassemble_current_function): Likewise.
	(disassemble_command): Likewise.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Record explicit block ranges from dwarf2read.c
@ 2018-08-25 10:00 sergiodj+buildbot
  2018-08-25 13:16 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25 10:00 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 8cad3755f9d24f236699ecf4100c116095f7ab01 ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: 8cad3755f9d24f236699ecf4100c116095f7ab01

Record explicit block ranges from dwarf2read.c

This change sets BLOCK_RANGES for the block under consideration by
calling make_blockranges().  This action is performed in
dwarf2_record_block_ranges().

It should be noted that dwarf2_record_block_ranges() already does some
recording of the range via a call to record_block_range().  The ranges
recorded in that fashion end up in the address map associated with the
blockvector for the compilation unit's symtab.  Given an address, the
addrmap provides a fast way of finding the block containing that
address.  The address map does not, however, provide a convenient way
of determining which address ranges make up a particular block.

While reading a set of ranges, a vector of pairs is used to collect
the starting and ending addresses for each range in the block.  Once
all of the ranges for a block have been collected, make_blockranges()
is called to fill in BLOCK_RANGES for the block.

The ranges are stored for the block in the order that they're read
from the debug info.  For DWARF, the starting address of the first
range of the block will be the entry pc in cases where DW_AT_entry_pc
is not present.  (Well, that would ideally be the case.  At the moment
DW_AT_entry_pc is not being handled.)

gdb/ChangeLog:

	* dwarf2read.c (dwarf2_record_block_ranges): Fill in BLOCK_RANGES
	for block.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Add block range data structure for blocks with non-contiguous address ranges
@ 2018-08-25  9:16 sergiodj+buildbot
  2018-08-25 12:51 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-25  9:16 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 76dae9eb044ab86c242724968f541ee6702851af ***

Author: Kevin Buettner <kevinb@redhat.com>
Branch: gdb-8.2-branch
Commit: 76dae9eb044ab86c242724968f541ee6702851af

Add block range data structure for blocks with non-contiguous address ranges

This patch does the following:

- Introduces a block range data structure which is accessed via
  a new field in struct block.
- Defines several macros for accessing block ranges.
- Defines a new function, make_blockrange, which is responsible for
  creating the new data structure.

It should be noted that some support for non-contiguous ranges already
existed in GDB in the form of blockvector addrmaps.  This support
allowed GDB to quickly find a block containing a particular address
even when the block consists of non-contiguous addresses.  See
find_block_in_blockvector() in block.c, dwarf2_record_block_ranges()
in dwarf2read.c, and record_block_range() in buildsym.c.

Addrmaps do not provide a convenient way to examine address ranges
associated with a particular block.  This data structure (and its
interface) is set up for quickly finding the value (which in this case
is a block) associated with a particular address.  The interface
does not include a method for doing a reverse mapping from blocks to
addresses.  A linear time mapping might be attempted via use of the
addrmap's foreach method, but this is not as straightforward as it
might first appear due to the fact that blocks corresponding to inline
function instances and lexical blocks w/ variables end up getting
interspersed in in the set of transitions.

Note:  If this approach is deemed to be too expensive in terms of
space, an alternate approach might be to attempt the linear time
mapping noted above.  find_pc_partial_function() needs to be able to
quickly know whether there are discontiguous ranges, so a flag for
this property would have to be added to struct block.  Also integral
to this set of changes is the concept of an "entry pc" which might be
different from the block's start address.  An entry_pc field would
also need to be added to struct block.  This does not result in any
space savings in struct block though since the space for the flag and
entry_pc use more space than the blockranges struct pointer that I've
added.  There would, however, be some space savings due to the fact
that the new data structures that I've added for this patch would not
need to be allocated.  (I happen to like the approach I've come up
with, but I wanted to mention another possibility just in case someone
does not.)

gdb/ChangeLog:

	* block.h (blockrange, blockranges): New struct declarations.
	(struct block): Add new field named `ranges'.
	(BLOCK_RANGES, BLOCK_NRANGES, BLOCK_RANGE, BLOCK_CONTIGUOUS_P)
	(BLOCK_RANGE_START, BLOCK_RANGE_END, BLOCK_ENTRY_PC): New
	macros for accessing ranges in struct block.
	(make_blockranges): New declaration.
	block.c (make_blockranges): New function.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR gdb/23379)
@ 2018-08-24 23:50 sergiodj+buildbot
  2018-08-25  6:09 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-24 23:50 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 0e84db8c75a5afbfef02a295f4f8867bd07ea12d ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-8.2-branch
Commit: 0e84db8c75a5afbfef02a295f4f8867bd07ea12d

Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR gdb/23379)

This commit fixes a 8.1->8.2 regression exposed by
gdb.python/py-evthreads.exp when testing with
--target_board=native-gdbserver.

gdb.log shows:

  src/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n) FAIL: gdb.python/py-evthreads.exp: run to breakpoint 1 (GDB internal error)

A backtrace shows (frames #2 and #10 highlighted) that the assertion
fails when GDB is setting up the connection to the remote target, in
non-stop mode:

  #0  0x0000000000622ff0 in internal_error(char const*, int, char const*, ...) (file=0xc1ad98 "src/gdb/thread.c", line=93, fmt=0xc1ad20 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54
  #1  0x000000000089567e in inferior_thread() () at src/gdb/thread.c:93
= #2  0x00000000004da91d in get_event_thread() () at src/gdb/python/py-threadevent.c:38
  #3  0x00000000004da9b7 in create_thread_event_object(_typeobject*, _object*) (py_type=0x11574c0 <continue_event_object_type>, thread=0x0)
      at src/gdb/python/py-threadevent.c:60
  #4  0x00000000004bf6fe in create_continue_event_object() () at src/gdb/python/py-continueevent.c:27
  #5  0x00000000004bf738 in emit_continue_event(ptid_t) (ptid=...) at src/gdb/python/py-continueevent.c:40
  #6  0x00000000004c7d47 in python_on_resume(ptid_t) (ptid=...) at src/gdb/python/py-inferior.c:108
  #7  0x0000000000485bfb in std::_Function_handler<void (ptid_t), void (*)(ptid_t)>::_M_invoke(std::_Any_data const&, ptid_t&&) (__functor=..., __args#0=...) at /usr/include/c++/7/bits/std_function.h:316
  #8  0x000000000089b416 in std::function<void (ptid_t)>::operator()(ptid_t) const (this=0x12aa600, __args#0=...)
      at /usr/include/c++/7/bits/std_function.h:706
  #9  0x000000000089aa0e in gdb::observers::observable<ptid_t>::notify(ptid_t) const (this=0x118a7a0 <gdb::observers::target_resumed>, args#0=...)
      at src/gdb/common/observable.h:106
= #10 0x0000000000896fbe in set_running(ptid_t, int) (ptid=..., running=1) at src/gdb/thread.c:880
  #11 0x00000000007f750f in remote_target::remote_add_thread(ptid_t, bool, bool) (this=0x12c5440, ptid=..., running=true, executing=true) at src/gdb/remote.c:2434
  #12 0x00000000007f779d in remote_target::remote_notice_new_inferior(ptid_t, int) (this=0x12c5440, currthread=..., executing=1)
      at src/gdb/remote.c:2515
  #13 0x00000000007f9c44 in remote_target::update_thread_list() (this=0x12c5440) at src/gdb/remote.c:3831
  #14 0x00000000007fb922 in remote_target::start_remote(int, int) (this=0x12c5440, from_tty=0, extended_p=0)
      at src/gdb/remote.c:4655
  #15 0x00000000007fd102 in remote_target::open_1(char const*, int, int) (name=0x1a4f45e "localhost:2346", from_tty=0, extended_p=0)
      at src/gdb/remote.c:5638
  #16 0x00000000007fbec1 in remote_target::open(char const*, int) (name=0x1a4f45e "localhost:2346", from_tty=0)
      at src/gdb/remote.c:4862

So on frame #10, we're marking a newly-discovered thread as running,
and that causes the Python API to emit a gdb.ContinueEvent.
gdb.ContinueEvent is a gdb.ThreadEvent, and as such includes the event
thread as the "inferior_thread" attribute.  The problem is that when
we get to frame #3/#4, we lost all references to the thread that is
being marked as running.  create_continue_event_object assumes that it
is the current thread, which is not true in this case.

Fix this by passing down the right thread in
create_continue_event_object.  Also remove
create_thread_event_object's default argument and have the only other
caller left pass down the right thread explicitly too.

gdb/ChangeLog:
2018-08-24  Pedro Alves  <palves@redhat.com>
	    Simon Marchi  <simon.marchi@ericsson.com>

	PR gdb/23379
	* python/py-continueevent.c: Include "gdbthread.h".
	(create_continue_event_object): Add intro comment.  Add 'ptid'
	parameter.  Use it to find thread to pass to
	create_thread_event_object.
	(emit_continue_event): Pass PTID down to
	create_continue_event_object.
	* python/py-event.h (py_get_event_thread): Declare.
	(create_thread_event_object): Remove default from 'thread'
	parameter.
	* python/py-stopevent.c (create_stop_event_object): Use
	py_get_event_thread.
	* python/py-threadevent.c (get_event_thread): Rename to ...
	(py_get_event_thread): ... this, make extern, add 'ptid' parameter
	and use it to find the thread.
	(create_thread_event_object): Assert that THREAD isn't null.
	Don't find the event thread here.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Darwin: fix bad loop incrementation
@ 2018-08-23 15:34 sergiodj+buildbot
  2018-08-23 16:57 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-23 15:34 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6354b6519382f592c81932631c7d45c61d6ba5b7 ***

Author: Xavier Roirand <roirand@adacore.com>
Branch: gdb-8.2-branch
Commit: 6354b6519382f592c81932631c7d45c61d6ba5b7

Darwin: fix bad loop incrementation

When reading symbols from the vector of oso files on Mac OS X
Darwin, a previous commit introduce a change in the loop and add
an increment at each loop iteration whereas this incrementation is
not needed since the increment or set of the loop control variable
is already done in the loop.

gdb/ChangeLog:

	* machoread.c (macho_symfile_read_all_oso): Remove uneeded
	incrementation.

Change-Id: I3a5a6deb4e9d834ee7d4217a62d90c2ffb7241bc


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Aarch64 SVE VG is Vector Granule
@ 2018-08-22  9:18 sergiodj+buildbot
  2018-08-22 17:11 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-22  9:18 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 7c46ec12730d911b0a3d0f5aaafb1ba12f0bdeac ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: 7c46ec12730d911b0a3d0f5aaafb1ba12f0bdeac

Aarch64 SVE VG is Vector Granule

...not Vector Gradient.

See: DWARF for the ARM 64-bit Architecture (AArch64) with SVE support

gdb/
	* arch/aarch64.h (aarch64_regnum): Update comment.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Add AArch64 SVE to NEWS and GDB manual
@ 2018-08-22  9:07 sergiodj+buildbot
  2018-08-22 15:55 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-22  9:07 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 694b0fb308cb7a6b19cd6323d9284408a503de9c ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: 694b0fb308cb7a6b19cd6323d9284408a503de9c

Add AArch64 SVE to NEWS and GDB manual

gdb/
	* NEWS: Add SVE to 8.2 section.

gdb/doc/
	* doc/gdb.texinfo (AArch64 SVE): New subsubsection.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Remove "repeat" argument from command_line_input
@ 2018-08-18  0:04 sergiodj+buildbot
  2018-08-18  3:33 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-18  0:04 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 84a39102d73de5b195b3f8037780ed2133db1fb7 ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: 84a39102d73de5b195b3f8037780ed2133db1fb7

Remove "repeat" argument from command_line_input

After the previous patch, all callers pass 0 as the repeat argument to
command_line_input.  So, this patch removes it.

2018-08-16  Tom Tromey  <tom@tromey.com>

	* top.c (read_command_file): Update.
	(command_line_input): Remove "repeat" argument.
	* ada-lang.c (get_selections): Update.
	* linespec.c (decode_line_2): Update.
	* defs.h (command_line_input): Remove argument.
	* cli/cli-script.c (read_next_line): Update.
	* python/py-gdb-readline.c: Update.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix use-after-free in number_or_range_parser
@ 2018-08-17 23:51 sergiodj+buildbot
  2018-08-18  2:22 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-08-17 23:51 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 5424be6a70bd9b462e7fd72e817367602c354e2c ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: 5424be6a70bd9b462e7fd72e817367602c354e2c

Fix use-after-free in number_or_range_parser

-fsanitize=address showed a use-after-free in number_or_range_parser.

The cause was that handle_line_of_input could stash the input into
"saved_command_line", and then this could be freed by reentrant calls.

This fixes the bug by preventing commands that are read by "commands"
from being eligible for repeating.

2018-08-17  Tom Tromey  <tom@tromey.com>

	* cli/cli-script.c (read_next_line): Pass 0 as repeat argument to
	command_line_input.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Remove struct keyword in range-based for loop
@ 2018-07-31 17:24 sergiodj+buildbot
  2018-08-01  1:15 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-31 17:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 599849befcc9a03584c7c03e65e5d5cf7ea0e4e8 ***

Author: Simon Marchi <simon.marchi@polymtl.ca>
Branch: gdb-8.2-branch
Commit: 599849befcc9a03584c7c03e65e5d5cf7ea0e4e8

Remove struct keyword in range-based for loop

PR gdb/23469
Fix this with gcc 6.3.0:

/home/simark/src/binutils-gdb/gdb/symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
/home/simark/src/binutils-gdb/gdb/symfile.c:2114:14: error: types may not be defined in a for-range-declaration [-Werror]
   for (const struct other_sections *objf_sect : objf_addrs_sorted)
              ^~~~~~
gdb/ChangeLog:

	* symfile.c (set_objfile_default_section_offset): Remove struct
	keyword.

(cherry picked from commit ff27d0737ef0c9433a6a7c83c1e678ac57a27699)


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Rename tdesc_register_size to tdesc_register_bitsize
@ 2018-07-25 10:09 sergiodj+buildbot
  2018-07-25 10:41 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-25 10:09 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 450cf17e305ba3dcccfff7643e85537f1de58d9c ***

Author: Alan Hayward <alan.hayward@arm.com>
Branch: gdb-8.2-branch
Commit: 450cf17e305ba3dcccfff7643e85537f1de58d9c

Rename tdesc_register_size to tdesc_register_bitsize

tdesc_register_size returns number of bits, not bytes.
Rename to make it clearer.

Also, fixed bug in aarch64_get_tdesc_vq which assumed bytes.

gdb/
	* target-descriptions.c (tdesc_register_bitsize): Rename.
	* target-descriptions.h (tdesc_register_bitsize): Likewise.
	* rs6000-tdep.c (rs6000_gdbarch_init): Use new name.
	* aarch64-tdep.c (aarch64_get_tdesc_vq): Convert size.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Set CU language before processing any DIEs (symtab/23010 et al)
@ 2018-07-24 20:38 sergiodj+buildbot
  2018-07-24 21:09 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-24 20:38 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 9eb8d8e3e025323c9c5566b36c1fdc331aa33132 ***

Author: Keith Seitz <keiths@redhat.com>
Branch: gdb-8.2-branch
Commit: 9eb8d8e3e025323c9c5566b36c1fdc331aa33132

Set CU language before processing any DIEs (symtab/23010 et al)

This patch is another attempt at really fixing the multitude of assertions
being seen where symbols of one language are being added to symbol lists of
another language.

In this specific case, the backtrace command (thread apply all bt full) that
is looking for the compunit containing the PC of the thread. That calls
get_prev_frame several times. This function calls (eventually)
dwarf2_frame_prev_register. That eventually ends up calling
find_pc_compunit_symtab.

In this function (find_pc_sect_compunit_symtab actually), we loop over all
compunits, calling the "quick" function dw2_find_pc_sect_compunit_symtab.
That function calls dw2_instantiate_symtab to read in all the CU's symbols.
Now the fun begins.

dw2_do_instantiate_symtab queues the per_cu for reading, using a default
"pretend" language of language_minimal with the expectation that this will
be set later.

The DIEs of this (only queued) CU are then processed.

The first DIE is DW_TAG_compile_unit. That's handled by read_file_scope.

(Nearly) The first thing read_file_scope does is:

  get_scope_pc_bounds (die, &lowpc, &highpc, cu);

This function loops over the children of the current DIE (a compile_unit),
looking for bounds. The first such child is a subprogram, and we attempt to
get its bounds. We use dwarf2_attr to get at DW_AT_high_pc.

This subprogram has DW_AT_specification set, so dwarf_attr (via
follow_die_ref/follow_die_offset) will follow that, but follow_die_offset
*also* attempts to load the containing CU for the spec DIE. That spec DIE
lives inside a CU that is a partial_unit and has no language attribute. So
it simply inherits the language from the CU that elicited the read. [That
all happens in follow_die_offset.]

The original CU's language is still language_minimal -- we haven't gotten to
the line in read_file_scope that actually sets the language yet!

And that is the cause of these problems. The call to prepare_one_comp_unit
needs to be the *first* thing that is done when reading a CU so that the
CU's language can be recorded (and inherited by any referenced
partial_units).

Since a test reproducer for this has been so elusive, this patch also adds a
wrapper function around add_symbol_to_list which asserts when adding a
symbol of one language to a list containing symbols of a different language.

gdb/ChangeLog:
2017-07-24  Keith Seitz  <keiths@redhat.com>

        PR symtab/23010
        * dwarf2read.c (dw2_add_symbol_to_list): New function.
        (fixup_go_packaging, new_symbol): Use dw2_add_symbol_to_list
        instead of add_symbol_to_list.
        (read_file_scope): Call prepare_one_comp_unit before reading
        any other DIEs.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix ravenscar-thread.c to use arch_ops
@ 2018-07-22 22:30 sergiodj+buildbot
  2018-07-23 13:36 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-22 22:30 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ac4f58d797780e305ba7be2c5d7efa8abf45fb74 ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: ac4f58d797780e305ba7be2c5d7efa8abf45fb74

Fix ravenscar-thread.c to use arch_ops

The change to turn target ops into methods accidentally introduced a
bug in ravenscar-thread.c, changing some calls that were using
"arch_ops" to use the target beneath.

This patch changes ravenscar-thread.c to use these variables where
appropriate.

2018-07-22  Tom Tromey  <tom@tromey.com>

	* ravenscar-thread.c (ravenscar_thread_target::store_registers):
	Use arch_ops.
	(ravenscar_thread_target::prepare_to_store): Likewise.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix GDB build using mingw.org's MinGW
@ 2018-07-19 14:15 sergiodj+buildbot
  2018-07-19 20:39 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-19 14:15 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 6b5c10c4f80cd4a741f3e378a3a42f3ed1741d49 ***

Author: Eli Zaretskii <eliz@gnu.org>
Branch: gdb-8.2-branch
Commit: 6b5c10c4f80cd4a741f3e378a3a42f3ed1741d49

Fix GDB build using mingw.org's MinGW

libiberty/
2018-07-18  Eli Zaretskii  <eliz@gnu.org>

	PR gdb/23434
	* libiberty/simple-object-elf.c (ENOTSUP): If not defined by
        errno.h, redirect ENOTSUP to ENOSYS.

(cherry picked from commit db3410f80f793189d3c8afb8b80951333d3fe007)


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Use scoped_free_pendings in coff_symtab_read
@ 2018-07-17 16:04 sergiodj+buildbot
  2018-07-18  9:12 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-17 16:04 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 79b38778d788e01e66e82f16bf3d4957439c77d5 ***

Author: Tom Tromey <tom@tromey.com>
Branch: gdb-8.2-branch
Commit: 79b38778d788e01e66e82f16bf3d4957439c77d5

Use scoped_free_pendings in coff_symtab_read

PR gdb/18624 concerns an assertion failure that occurs when setting a
breakpoint in a Go program on Windows.

What happens here is that coff_symtab_read uses buildsym but does not
instantiate scoped_free_pendings.  So, the struct pending objects are
never released.  Later, dwarf2read.c calls buildsym_init, which
asserts.

This patch fixes the problem by instantiating scoped_free_pendings in
coff_symtab_read.

Tested using the test executable from the PR.  I don't know how to
test this more fully.

2018-07-17  Tom Tromey  <tom@tromey.com>

	PR gdb/18624:
	* coffread.c (coff_symtab_read): Use scoped_free_pendings.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] GDBserver: Fix "Cond. jump or move depends on uninit value" in x87 code
@ 2018-07-11 19:59 sergiodj+buildbot
  2018-07-12  2:11 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-11 19:59 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 82e080dcf7289255f3a9bf6b860d4864aa93e554 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-8.2-branch
Commit: 82e080dcf7289255f3a9bf6b860d4864aa93e554

GDBserver: Fix "Cond. jump or move depends on uninit value" in x87 code

Running gdbserver under Valgrind I get:

  ==26925== Conditional jump or move depends on uninitialised value(s)
  ==26925==    at 0x473E7F: i387_cache_to_xsave(regcache*, void*) (i387-fp.c:579)
  ==26925==    by 0x46E3ED: x86_fill_xstateregset(regcache*, void*) (linux-x86-low.c:418)
  ==26925==    by 0x45E747: regsets_store_inferior_registers(regsets_info*, regcache*) (linux-low.c:5456)
  ==26925==    by 0x45EEF8: linux_store_registers(regcache*, int) (linux-low.c:5731)
  ==26925==    by 0x426441: regcache_invalidate_thread(thread_info*) (regcache.c:89)
  ==26925==    by 0x45CCAF: linux_resume_one_lwp_throw(lwp_info*, int, int, siginfo_t*) (linux-low.c:4447)
  ==26925==    by 0x45CE2A: linux_resume_one_lwp(lwp_info*, int, int, siginfo_t*) (linux-low.c:4519)
  ==26925==    by 0x45E17C: proceed_one_lwp(thread_info*, lwp_info*) (linux-low.c:5216)
  ==26925==    by 0x45DC81: linux_resume_one_thread(thread_info*, bool) (linux-low.c:5031)
  ==26925==    by 0x45DD34: linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}::operator()(thread_info*) const (linux-low.c:5095)
  ==26925==    by 0x462907: void for_each_thread<linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}>(linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}) (gdbthread.h:150)
  ==26925==    by 0x45DE62: linux_resume(thread_resume*, unsigned long) (linux-low.c:5093)
  ==26925==
  ==26925== Conditional jump or move depends on uninitialised value(s)
  ==26925==    at 0x473EBD: i387_cache_to_xsave(regcache*, void*) (i387-fp.c:586)
  ==26925==    by 0x46E3ED: x86_fill_xstateregset(regcache*, void*) (linux-x86-low.c:418)
  ==26925==    by 0x45E747: regsets_store_inferior_registers(regsets_info*, regcache*) (linux-low.c:5456)
  ==26925==    by 0x45EEF8: linux_store_registers(regcache*, int) (linux-low.c:5731)
  ==26925==    by 0x426441: regcache_invalidate_thread(thread_info*) (regcache.c:89)
  ==26925==    by 0x45CCAF: linux_resume_one_lwp_throw(lwp_info*, int, int, siginfo_t*) (linux-low.c:4447)
  ==26925==    by 0x45CE2A: linux_resume_one_lwp(lwp_info*, int, int, siginfo_t*) (linux-low.c:4519)
  ==26925==    by 0x45E17C: proceed_one_lwp(thread_info*, lwp_info*) (linux-low.c:5216)
  ==26925==    by 0x45DC81: linux_resume_one_thread(thread_info*, bool) (linux-low.c:5031)
  ==26925==    by 0x45DD34: linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}::operator()(thread_info*) const (linux-low.c:5095)
  ==26925==    by 0x462907: void for_each_thread<linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}>(linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}) (gdbthread.h:150)
  ==26925==    by 0x45DE62: linux_resume(thread_resume*, unsigned long) (linux-low.c:5093)

The problem is a type/width mismatch in code like this, in
gdbserver/i387-fp.c:

  /* Some registers are 16-bit.  */
  collect_register_by_name (regcache, "fctrl", &val);
  fp->fctrl = val;

In the above code:

 #1 - 'val' is a 64-bit unsigned long.

 #2 - "fctrl" is 32-bit in the register cache, thus half of 'val' is
      left uninitialized by collect_register_by_name, which works with
      an untyped raw buffer output (i.e., void*).

 #3 - fp->fctrl is an unsigned short (16-bit).  For some such
      registers we're masking off the uninitialized bits with 0xffff,
      but not in all cases.

We end up in such a fragile situation because
collect_registers_by_name works with an untyped output buffer pointer,
making it easy to pass a pointer to a variable of the wrong size.

Fix this by using regcache_raw_get_unsigned instead (actually a new
regcache_raw_get_unsigned_by_name wrapper), which always returns a
zero-extended ULONGEST register value.  It ends up simplifying the
i387-tdep.c code a bit, even.

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

	* i387-fp.c (i387_cache_to_fsave, cache_to_fxsave)
	(i387_cache_to_xsave): Use regcache_raw_get_unsigned_by_name
	instead of collect_register_by_name.
	* regcache.c (regcache_raw_get_unsigned_by_name): New.
	* regcache.h (regcache_raw_get_unsigned_by_name): New.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Fix PR c++/23373: GDB hangs when printing a struct with a static member of itself
@ 2018-07-11 19:31 sergiodj+buildbot
  2018-07-12  1:01 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-11 19:31 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ad3c631a762734c39b85086d20ba28940c2fc9b8 ***

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

Fix PR c++/23373: GDB hangs when printing a struct with a static member of itself

This patch fixes a failure that happens when a structure has a static
member whose type is the same as itself.  From the bug report:

  Example code:
  struct A
  {
      static A Empty;
      int a;
  };

  int main(void) {
      A a;
      return 0;
  }

  Output:
  (gdb) ptype/o A
  /* offset    |  size */  type = struct A {
			     static struct A {
				 static struct A {
				     static struct A {
					 static struct A {
					     static struct A {
						 static struct A {
						     ... # infinite loop

The problem here is that GDB is not taking into account the fact that
static members inside a class/struct are not stored in the
class/struct, and therefore they should not be accounted for during
the display of the offsets/sizes.  The fix is simple: we just check if
the field we're dealing with (on
c-typeprint.c:c_type_print_base_struct_union) is static, and if it is
then we don't iterate over it.

This patch also adds a new test for this case, and doesn't introduce
any regressions.  I believe it is important enough to be included in
the 8.2 branch.

OK?

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

	PR c++/23373
	* c-typeprint.c (c_type_print_base_struct_union): Don't print
	offsets/sizes for static members of a class/struct.

gdb/testsuite/ChangeLog:
2018-07-11  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR c++/23373
	* gdb.base/ptype-offsets.cc (struct static_member): New
	struct.
	(main) <stmember>: New variable.
	* gdb.base/ptype-offsets.exp: Add test for printing a struct
	with a static member in it.


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Bump GDB version number to 8.1.90.DATE-git.
@ 2018-07-04 17:35 sergiodj+buildbot
  2018-07-05  0:18 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-04 17:35 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 1e80936c63d3ad2c1e0a357a8ff1b701dfdb2531 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.2-branch
Commit: 1e80936c63d3ad2c1e0a357a8ff1b701dfdb2531

Bump GDB version number to 8.1.90.DATE-git.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] Set GDB version number to 8.1.90.
@ 2018-07-04 17:24 sergiodj+buildbot
  2018-07-04 23:08 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-04 17:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT a37b7a0260c019bbbaa9d7cc205f2d0f9fa21292 ***

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

Set GDB version number to 8.1.90.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 63+ messages in thread
* [binutils-gdb/gdb-8.2-branch] gdb/NEWS: Change "Changes since GDB 8.1" into "Changes in GDB 8.2".
@ 2018-07-04 16:53 sergiodj+buildbot
  2018-07-04 21:56 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
  0 siblings, 1 reply; 63+ messages in thread
From: sergiodj+buildbot @ 2018-07-04 16:53 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 564d85cd9fc88b1e82336dc06fc32bcb7ed80a04 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-8.2-branch
Commit: 564d85cd9fc88b1e82336dc06fc32bcb7ed80a04

gdb/NEWS: Change "Changes since GDB 8.1" into "Changes in GDB 8.2".

gdb/ChangeLog:

        * NEWS: Change "Changes since GDB 8.1" into "Changes in GDB 8.2".


^ permalink raw reply	[flat|nested] 63+ messages in thread
end of thread, other threads:[~2019-02-27  4:19 UTC | newest]

Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-07 21:34 [binutils-gdb/gdb-8.2-branch] contrib/gdb-add-index.sh -dwarf-5 sergiodj+buildbot
2018-07-07 21:34 ` Failures on RHEL-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-07 21:49 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2018-07-07 22:26 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-07-07 22:29 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2018-07-07 22:42 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2018-07-07 22:42 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2018-07-07 22:43 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-w64-mingw32, branch gdb-8.2-branch *** BREAKAGE *** sergiodj+buildbot
2018-07-07 22:47 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, branch gdb-8.2-branch sergiodj+buildbot
2018-07-07 22:57 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2018-07-07 23:07 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2018-07-07 23:08 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-07-07 23:09 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2018-07-07 23:21 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2018-07-07 23:25 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
  -- strict thread matches above, loose matches on Subject: below --
2019-02-26 20:27 [binutils-gdb/gdb-8.2-branch] Import patch to fix PR23919 from the mainline sergiodj+buildbot
2019-02-27  4:19 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-12-23  7:11 [binutils-gdb/gdb-8.2-branch] Bump GDB version number to 8.2.1.DATE-git sergiodj+buildbot
2018-12-23 10:30 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-12-23  6:42 [binutils-gdb/gdb-8.2-branch] Set GDB version number to 8.2.1 sergiodj+buildbot
2018-12-23  8:27 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-12-21 19:25 [binutils-gdb/gdb-8.2-branch] gdb: Fix "info os <unknown>" command sergiodj+buildbot
2018-12-22  1:58 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-12-19 11:24 [binutils-gdb/gdb-8.2-branch] Fix SYMBOL_LANGUAGE assertion failure on AIX sergiodj+buildbot
2018-12-19 15:59 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-12-18 16:43 [binutils-gdb/gdb-8.2-branch] Fix dwarf2read.c:dwarf2_find_containing_comp_unit's binary search sergiodj+buildbot
2018-12-18 17:52 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-11-21 18:19 [binutils-gdb/gdb-8.2-branch] Make command-repeat work after gdb.execute sergiodj+buildbot
2018-11-22  2:42 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-11-19 19:20 [binutils-gdb/gdb-8.2-branch] gdb.base/warning.exp tweaks sergiodj+buildbot
2018-11-20  0:17 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-11-19 19:08 [binutils-gdb/gdb-8.2-branch] Avoid crash when calling warning too early sergiodj+buildbot
2018-11-19 22:42 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-18 16:29 [binutils-gdb/gdb-8.2-branch] python: Make gdb.execute("show commands") work (PR 23669) sergiodj+buildbot
2018-09-19  6:31 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-16 23:49 [binutils-gdb/gdb-8.2-branch] Move 'is_regular_file' from common-utils.c to filestuff.c sergiodj+buildbot
2018-09-17 12:56 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-14  9:41 [binutils-gdb/gdb-8.2-branch] Make Rust error message mention the field name sergiodj+buildbot
2018-09-16  7:33 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-12 18:25 [binutils-gdb/gdb-8.2-branch] Fix "make install-strip" failure to install gdb-add-index.sh sergiodj+buildbot
2018-09-12 23:23 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-06 22:40 [binutils-gdb/gdb-8.2-branch] Bump GDB version number to 8.2.0.DATE-git sergiodj+buildbot
2018-09-07  0:16 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-06 16:39 [binutils-gdb/gdb-8.2-branch] Set GDB version number to 8.2 sergiodj+buildbot
2018-09-06 22:16 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-09-01  4:20 [binutils-gdb/gdb-8.2-branch] Set TYPE_LENGTH on a variant part sergiodj+buildbot
2018-09-01  7:58 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-29  1:20 [binutils-gdb/gdb-8.2-branch] Modify gdb.base/commands.exp to test multi breakpoints command clearing sergiodj+buildbot
2018-08-29 13:12 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-29  0:54 [binutils-gdb/gdb-8.2-branch] Fix regression for multi breakpoints command line clearing sergiodj+buildbot
2018-08-29 12:55 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-28 12:52 [binutils-gdb/gdb-8.2-branch] Parse SVE registers in aarch64 core file reading/writing sergiodj+buildbot
2018-08-28 16:51 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-28 12:25 [binutils-gdb/gdb-8.2-branch] Detect SVE when reading aarch64 core files sergiodj+buildbot
2018-08-28 15:26 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-28 12:05 [binutils-gdb/gdb-8.2-branch] Split size in regset section iterators sergiodj+buildbot
2018-08-28 14:17 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-28 11:55 [binutils-gdb/gdb-8.2-branch] Rename size in get_core_register_section sergiodj+buildbot
2018-08-28 12:55 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-26 18:25 [binutils-gdb/gdb-8.2-branch] Restore behavior of disabling address randomization by default on GDBserver sergiodj+buildbot
2018-08-26 22:42 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 22:47 [binutils-gdb/gdb-8.2-branch] Initialize variable in py_get_event_thread sergiodj+buildbot
2018-08-26 12:18 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 12:24 [binutils-gdb/gdb-8.2-branch] Test case for functions with non-contiguous ranges sergiodj+buildbot
2018-08-25 22:51 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 11:56 [binutils-gdb/gdb-8.2-branch] Relocate block range start and end addresses sergiodj+buildbot
2018-08-25 20:22 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 11:51 [binutils-gdb/gdb-8.2-branch] Introduce find_function_entry_range_from_pc and use it in infrun.c sergiodj+buildbot
2018-08-25 16:46 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 11:16 [binutils-gdb/gdb-8.2-branch] Use BLOCK_ENTRY_PC in place of most uses of BLOCK_START sergiodj+buildbot
2018-08-25 15:34 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 11:13 [binutils-gdb/gdb-8.2-branch] Disassemble blocks with non-contiguous ranges sergiodj+buildbot
2018-08-25 14:53 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25 10:00 [binutils-gdb/gdb-8.2-branch] Record explicit block ranges from dwarf2read.c sergiodj+buildbot
2018-08-25 13:16 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-25  9:16 [binutils-gdb/gdb-8.2-branch] Add block range data structure for blocks with non-contiguous address ranges sergiodj+buildbot
2018-08-25 12:51 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-24 23:50 [binutils-gdb/gdb-8.2-branch] Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR gdb/23379) sergiodj+buildbot
2018-08-25  6:09 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-23 15:34 [binutils-gdb/gdb-8.2-branch] Darwin: fix bad loop incrementation sergiodj+buildbot
2018-08-23 16:57 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-22  9:18 [binutils-gdb/gdb-8.2-branch] Aarch64 SVE VG is Vector Granule sergiodj+buildbot
2018-08-22 17:11 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-22  9:07 [binutils-gdb/gdb-8.2-branch] Add AArch64 SVE to NEWS and GDB manual sergiodj+buildbot
2018-08-22 15:55 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-18  0:04 [binutils-gdb/gdb-8.2-branch] Remove "repeat" argument from command_line_input sergiodj+buildbot
2018-08-18  3:33 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-08-17 23:51 [binutils-gdb/gdb-8.2-branch] Fix use-after-free in number_or_range_parser sergiodj+buildbot
2018-08-18  2:22 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-31 17:24 [binutils-gdb/gdb-8.2-branch] Remove struct keyword in range-based for loop sergiodj+buildbot
2018-08-01  1:15 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-25 10:09 [binutils-gdb/gdb-8.2-branch] Rename tdesc_register_size to tdesc_register_bitsize sergiodj+buildbot
2018-07-25 10:41 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-24 20:38 [binutils-gdb/gdb-8.2-branch] Set CU language before processing any DIEs (symtab/23010 et al) sergiodj+buildbot
2018-07-24 21:09 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-22 22:30 [binutils-gdb/gdb-8.2-branch] Fix ravenscar-thread.c to use arch_ops sergiodj+buildbot
2018-07-23 13:36 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-19 14:15 [binutils-gdb/gdb-8.2-branch] Fix GDB build using mingw.org's MinGW sergiodj+buildbot
2018-07-19 20:39 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-17 16:04 [binutils-gdb/gdb-8.2-branch] Use scoped_free_pendings in coff_symtab_read sergiodj+buildbot
2018-07-18  9:12 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-11 19:59 [binutils-gdb/gdb-8.2-branch] GDBserver: Fix "Cond. jump or move depends on uninit value" in x87 code sergiodj+buildbot
2018-07-12  2:11 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-11 19:31 [binutils-gdb/gdb-8.2-branch] Fix PR c++/23373: GDB hangs when printing a struct with a static member of itself sergiodj+buildbot
2018-07-12  1:01 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-04 17:35 [binutils-gdb/gdb-8.2-branch] Bump GDB version number to 8.1.90.DATE-git sergiodj+buildbot
2018-07-05  0:18 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-04 17:24 [binutils-gdb/gdb-8.2-branch] Set GDB version number to 8.1.90 sergiodj+buildbot
2018-07-04 23:08 ` Failures on Debian-s390x-m64, branch gdb-8.2-branch sergiodj+buildbot
2018-07-04 16:53 [binutils-gdb/gdb-8.2-branch] gdb/NEWS: Change "Changes since GDB 8.1" into "Changes in GDB 8.2" sergiodj+buildbot
2018-07-04 21:56 ` Failures on Debian-s390x-m64, branch gdb-8.2-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).