Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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").

Automatic date update in version.in

Automatic date update in version.in

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.

Automatic date update in version.in

Automatic date update in version.in

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.

Fix crash with empty Rust enum

While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (https://github.com/rust-lang/rust/pull/54004), I found
a gdb crash coming from one of the Rust test cases.

The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.

This patch fixes the problem in a straightforward way.  Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers.  If you think that's
unacceptable, let meknow.

Tested on x86-64 Fedora 28 using several versions of the Rust
compiler.  I intend to push this to the 8.2 branch as well.

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

PR rust/23626:
* rust-lang.c (rust_enum_variant): Now static.
(rust_empty_enum_p): New function.
(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
Handle empty enum.

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

PR rust/23626:
* gdb.rust/simple.rs (EmptyEnum): New type.
(main): Use it.
* gdb.rust/simple.exp (test_one_slice): Add empty enum test.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

Document the GDB 8.2 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 8.2 released.

Set GDB version number to 8.2.

gdb/ChangeLog:

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

Automatic date update in version.in

fix incorrect gnulib getcwd replacement when cross-compiling GDB

This fixes a GDB crash observed on Android 8.0 when GDB was
cross-compiled. This patch is a backport of a patch pushed
upstream in gnulib.

gdb/ChangeLog (Sergio Durigan Junior  <sergiodj@redhat.com>):

        PR gdb/23558
        * gnulib/import/m4/getcwd-path-max.m4: Add handling of Hurd,
        Linux and kFreeBSD platforms.
        * gnulib/configure: Regenerate.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

Fix a small bug in gdb.rust/simple.rs

I noticed that gdb.rust/simple.rs had two local variables named "v".
This didn't previous cause problems, but with a newer rust compiler
this resulted in a test failure.  (It should have failed all along, so
I suppose earlier passes were due to a compiler bug.)

This patch renames the second variable.

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

* gdb.rust/simple.rs: Rename second variable "v".

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

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.

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.

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.

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.

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.

Automatic date update in version.in

Automatic date update in version.in

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.

Automatic date update in version.in

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.

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.

Relocate block range start and end addresses

gdb/ChangeLog:

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

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.

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.

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.

Add support for non-contiguous blocks to find_pc_partial_function

This change adds an optional output parameter BLOCK to
find_pc_partial_function.  If BLOCK is non-null, then *BLOCK will be
set to the address of the block corresponding to the function symbol
if such a symbol was found during lookup.  Otherwise it's set to the
NULL value.  Callers may wish to use the block information to
determine whether the block contains any non-contiguous ranges.  The
caller may also iterate over or examine those ranges.

When I first started looking at the broken stepping behavior associated
with functions w/ non-contiguous ranges, I found that I could "fix"
the problem by disabling the find_pc_partial_function cache.  It would
sometimes happen that the PC passed in would be between the low and
high cache values, but would be in some other function that happens to
be placed in between the ranges for the cached function.  This caused
incorrect values to be returned.

So dealing with this cache turns out to be very important for fixing
this problem.  I explored three different ways of dealing with the
cache.

My first approach was to clear the cache when a block was encountered
with more than one range.  This would cause the non-cache pathway to
be executed on the next call to find_pc_partial_function.

Another approach, which I suspect is slightly faster, checks to see
whether the PC is within one of the ranges associated with the cached
block.  If so, then the cached values can be used.  It falls back to
the original behavior if there is no cached block.

The current approach, suggested by Simon Marchi, is to restrict the
low/high pc values recorded for the cache to the beginning and end of
the range containing the PC value under consideration.  This allows us
to retain the simple (and fast) test for determining whether the
memoized (cached) values apply to the PC passed to
find_pc_partial_function.

Another choice that had to be made regards setting *ADDRESS and
*ENDADDR.  There are three possibilities which might make sense:

1) *ADDRESS and *ENDADDR represent the lowest and highest address
   of the function.
2) *ADDRESS and *ENDADDR are set to the start and end address of
   the range containing the entry pc.
3) *ADDRESS and *ENDADDR are set to the start and end address of
   the range in which PC is found.

An earlier version of this patch implemented option #1.  I found out
that it's not very useful though and, in fact, returns results that
are incorrect when used in the context of determining the start and
end of the function for doing prologue analysis.  While debugging a
function in which the entry pc was in the second range (of a function
containing two non-contiguous ranges), I noticed that
amd64_skip_prologue called find_pc_partial_function - the returned
start address was set to the beginning of the first range.  This is
incorrect for this function.  What was also interesting was that this
first invocation of find_pc_partial_function correctly set the cache
for the PC on which it had been invoked, but a slightly later call
from skip_prologue_using_sal could not use this cached value because
it was now being used to lookup the very lowest address of the
function - which is in a range not containing the entry pc.

Option #2 is attractive as it would provide a desirable result
when used in the context of prologue analysis.  However, many callers,
including some which do prologue analysis want the condition
*ADDRESS <= PC < *ENDADDR to hold.  This will not be the case when
find_pc_partial_function is called on a PC that's in a non-entry-pc
range.  A later patch to this series adds
find_function_entry_range_from_pc as a wrapper of
find_pc_partial_function.

Option #3 causes the *ADDRESS <= PC < *ENDADDR property to hold.  If
find_pc_partial_function is called with a PC that's within entry pc's
range, then it will correctly return the limits of that range.  So, if
the result of a minsym search is passed to find_pc_partial_function
to find the limits, then correct results will be achieved.  Returned
limits (for prologue analysis) won't be correct when PC is within some
other (non-entry-pc) range.  I don't yet know how big of a problem
this might be; I'm guessing that it won't be a serious problem - if a
compiler generates functions which have non-contiguous ranges, then it
also probably generates DWARF2 CFI which makes a lot of the old
prologue analysis moot.

I've implemented option #3 for this version of the patch.  I don't see
any regressions for x86-64.  Moreover, I don't expect to see
regressions for other targets either simply because
find_pc_partial_function behaves the same as it did before for the
contiguous address range case.  That said, there may be some
adjustments needed if GDB encounters a function requiring prologue
analysis which occupies non-contiguous ranges.

gdb/ChangeLog:

* symtab.h (find_pc_partial_function): Add new parameter `block'.
* blockframe.c (cache_pc_function_block): New static global.
(clear_pc_function_cache): Clear cache_pc_function_block.
(find_pc_partial_function): Move comment to symtab.h.  Add
support for non-contiguous blocks.

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.

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.

Automatic date update in version.in

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.

Automatic date update in version.in

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

Automatic date update in version.in

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.

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in