Commit Graph

37945 Commits

Author SHA1 Message Date
Martin Galvan
3326303bf5 [PR gdb/19893] Fix handling of synthetic C++ references
https://sourceware.org/bugzilla/show_bug.cgi?id=19893

I've traced the main source of the problem to pieced_value_funcs.coerce_ref not being
implemented. Since gdb always assumes references are implemented as pointers, this
causes it to think that it's dealing with a NULL pointer, thus breaking any operations
involving synthetic references.

What I did here was implementing pieced_value_funcs.coerce_ref using some of the synthetic
pointer handling code from indirect_pieced_value, as Pedro suggested. I also made a few
adjustments to the reference printing code so that it correctly shows either the address
of the referenced value or (if it's non-addressable) the "<synthetic pointer>" string.

I also wrote some unit tests based on Dwarf::assemble; these took a while to make
because in most cases I needed a synthetic reference to a physical variable. Additionally,
I started working on a unit test for classes that have a vtable, but ran into a few issues
so that'll probably go in a future patch. One thing that should definitely be fixed is that
proc function_range (called for MACRO_AT_func) will always try to compile/link using gcc
with the default options instead of g++, thus breaking C++ compilations that require e.g. libstdc++.

gdb/ChangeLog:

	* dwarf2loc.c (coerce_pieced_ref, indirect_synthetic_pointer,
	fetch_const_value_from_synthetic_pointer): New functions.
	(indirect_pieced_value): Move lower half to indirect_synthetic_pointer.
	(pieced_value_funcs): Implement coerce_ref.
	* valops.c (value_addr): Call coerce_ref for synthetic references.
	* valprint.c (valprint_check_validity): Return true for synthetic
	references.  Also, don't show "<synthetic pointer>" if they reference
	addressable values.
	(generic_val_print_ref): Handle synthetic references.  Also move some
	code to print_ref_address.
	(print_ref_address, get_value_addr_contents): New functions.

gdb/testsuite/ChangeLog:

	* gdb.dwarf2/implref.exp: Rename to...
	* gdb.dwarf2/implref-const.exp: ...this.  Also add more test statements.
	* gdb.dwarf2/implref-array.c: New file.
	* gdb.dwarf2/implref-array.exp: Likewise.
	* gdb.dwarf2/implref-global.c: Likewise.
	* gdb.dwarf2/implref-global.exp: Likewise.
	* gdb.dwarf2/implref-struct.c: Likewise.
	* gdb.dwarf2/implref-struct.exp: Likewise.
2016-05-31 15:56:34 -03:00
Antoine Tremblay
825c8ef28f Add tests for 64bit values in trace-condition.exp
This patch adds tests for emit operations with 64 bit values. It takes
special care to avoid mistakes that one could make on a 32bit architecture
using 64bit values.

gdb/testsuite/ChangeLog:

	* gdb.trace/trace-condition.exp: Add 64bit tests.
2016-05-30 12:51:13 -04:00
Antoine Tremblay
2320162a62 Add variable length tests for emit_ref in trace-condition.exp
This patch add variable length tests for emit_ref by reading the variable
passed as argument of 8 to 64 bit.

gdb/testsuite/ChangeLog:

	* gdb.trace/trace-condition.c (marker): Adapt signature to 8 to 64
	bits types.
	(main): Adapt to 8 to 64 bits types.
	* gdb.trace/trace-condition.exp: Add new tests.
2016-05-30 12:51:13 -04:00
Antoine Tremblay
a781823347 Add emit_less_unsigned test in trace-condition.exp
This patch adds coverage for emit_less_unsigned.

gdb/testsuite/ChangeLog:

	* gdb.trace/trace-condition.exp: Add emit_less_unsigned test.
2016-05-30 12:51:13 -04:00
Antoine Tremblay
0d33646690 Move trace conditions tests from ftrace.exp to trace-condition.exp
This patch moves conditional tests that were done in ftrace.exp to
trace-condition.exp.

Note that emit_ref is now tested by the anarg local variable there is no
need to test the register directly.

All emit calls have been tested using asserts before / after the move, to
ensure that the tests cover the same functions.

Note that these function were not covered before and are still not:
emit_gt_goto, emit_lt_goto, emit_pop, emit_unsigned_less.

gdb/testsuite/ChangeLog:

	* gdb.trace/ftrace.exp (test_ftrace_condition): Remove.
	Move condition tests...
	* gdb.trace/trace-condition.exp: Here.
2016-05-30 12:51:13 -04:00
Antoine Tremblay
7faeb45ae3 Add counter-cases for trace-condition.exp tests
In trace-condition.exp, tests are done by doing a conditional tracepoint
and validating that the trace contains all the frames that could be
collected if that condition is true.

E.g. test_tracepoints $trace_command "21 + 21 == 42" 10

This will always return true and collect the 10 frames possible to collect
with the test program.

However, if the condition evaluation is broken such that the condition is
unconditional we will not notice this problem.

This patch adds counter-cases to such conditions like so:

$trace_command "21 + 11 == 42" 0

This way such a problem would be noticed.

gdb/testsuite/ChangeLog:

	* gdb.trace/trace-condition.exp: Add counter-case tests.
2016-05-30 12:51:13 -04:00
Jan Kratochvil
e385593eef PR 15231: import bare DW_TAG_lexical_block
Local variables in lambdas are not accessible
https://sourceware.org/bugzilla/show_bug.cgi?id=15231

GDB: read_lexical_block_scope
  /* Ignore blocks with missing or invalid low and high pc attributes.  */
[...]
  if (!dwarf2_get_pc_bounds (die, &lowpc, &highpc, cu, NULL))
    return;

But sometimes there is:

FAIL: gcc-5.3.1-6.fc23.x86_64
 <2><92>: Abbrev Number: 11 (DW_TAG_lexical_block)
 <3><9c>: Abbrev Number: 13 (DW_TAG_structure_type)
    <9d>   DW_AT_name        : (indirect string, offset: 0x3c): <lambda()>
    [...]

Where DW_TAG_lexical_block has no attributes.  Such whole subtree is currently
dropped by GDB while I think it should just import all its children DIEs.

It even XFAIL->XPASSes gdb.ada/out_of_line_in_inlined.exp:
	commit 0fa7fe506c
	Author: Joel Brobecker <brobecker@adacore.com>
	    out of line functions nested inside inline functions.
So I have removed that xfail.

gdb/ChangeLog
2016-05-30  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR c++/15231
	* dwarf2read.c (enum pc_bounds_kind): Add PC_BOUNDS_INVALID.
	(process_psymtab_comp_unit_reader, read_func_scope): Adjust callers.
	(read_lexical_block_scope): Import DIEs from bare DW_TAG_lexical_block.
	(read_call_site_scope): Adjust callers.
	(dwarf2_get_pc_bounds): Implement pc_bounds_invalid.
	(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds): Adjust callers.

gdb/testsuite/ChangeLog
2016-05-30  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR c++/15231
	* gdb.ada/out_of_line_in_inlined.exp: Remove xfails.
	* gdb.dwarf2/dw2-lexical-block-bare.exp: New file.
2016-05-30 14:14:43 +02:00
Jan Kratochvil
3a2b436ae9 Code cleanup: dwarf2_get_pc_bounds: -1/0/+1 -> enum
Make the code (maybe) more readable + primarily prepare it for [patch 2/2]
enum extension.

This change should have no code change impact.

gdb/ChangeLog
2016-05-30  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Code cleanup: dwarf2_get_pc_bounds: -1/0/+1 -> enum
	* dwarf2read.c (enum pc_bounds_kind) New.
	(dwarf2_get_pc_bounds): Use it in the declaration.
	(process_psymtab_comp_unit_reader): Adjust caller.  Rename has_pc_info
	to cu_bounds_kind.
	(read_func_scope, read_lexical_block_scope, read_call_site_scope):
	Adjust callers.
	(dwarf2_get_pc_bounds): Use enum pc_bounds_kind in the definition.
	(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds): Adjust callers.
2016-05-30 14:11:43 +02:00
Jan Kratochvil
aab3c527d7 NEWS: QCatchSyscalls: simplify
Standardize the QCatchSyscalls NEWS entry.

gdb/ChangeLog
2016-05-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* NEWS (QCatchSyscalls): Remove the parameter.  Include ...
	(QCatchSyscalls:1 in qSupported) ... this separate entry which got
	deleted.
2016-05-29 20:45:42 +02:00
Jan Kratochvil
c64e0f6165 NEWS: Remove empty line.
gdb/ChangeLog
2016-05-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* NEWS (N stop reply): Remove empty line.
2016-05-29 18:42:15 +02:00
Alan Modra
1a72702bb3 Return void from linker callbacks
The ldmain.c implementation of these linker callback functions always
return true, so any code handling a false return is dead.  What's
more, some of the bfd backends abort if ever a false return is seen,
and there seems to be some confusion in gdb's compile-object-load.c.
The return value was never meant to be "oh yes, a multiple_definition
error occurred", but rather "out of memory or other catastrophic
failure".

This patch removes the status return on the callbacks that always
return true.  I kept the return status for "notice" because that one
does happen to need to return "out of memory".

include/
	* bfdlink.h (struct bfd_link_callbacks): Update comments.
	Return void from multiple_definition, multiple_common,
	add_to_set, constructor, warning, undefined_symbol,
	reloc_overflow, reloc_dangerous and unattached_reloc.
bfd/
	* aoutx.h: Adjust linker callback calls throughout file,
	removing dead code.
	* bout.c: Likewise.
	* coff-alpha.c: Likewise.
	* coff-arm.c: Likewise.
	* coff-h8300.c: Likewise.
	* coff-h8500.c: Likewise.
	* coff-i960.c: Likewise.
	* coff-mcore.c: Likewise.
	* coff-mips.c: Likewise.
	* coff-ppc.c: Likewise.
	* coff-rs6000.c: Likewise.
	* coff-sh.c: Likewise.
	* coff-tic80.c: Likewise.
	* coff-w65.c: Likewise.
	* coff-z80.c: Likewise.
	* coff-z8k.c: Likewise.
	* coff64-rs6000.c: Likewise.
	* cofflink.c: Likewise.
	* ecoff.c: Likewise.
	* elf-bfd.h: Likewise.
	* elf-m10200.c: Likewise.
	* elf-m10300.c: Likewise.
	* elf32-arc.c: Likewise.
	* elf32-arm.c: Likewise.
	* elf32-avr.c: Likewise.
	* elf32-bfin.c: Likewise.
	* elf32-cr16.c: Likewise.
	* elf32-cr16c.c: Likewise.
	* elf32-cris.c: Likewise.
	* elf32-crx.c: Likewise.
	* elf32-d10v.c: Likewise.
	* elf32-epiphany.c: Likewise.
	* elf32-fr30.c: Likewise.
	* elf32-frv.c: Likewise.
	* elf32-ft32.c: Likewise.
	* elf32-h8300.c: Likewise.
	* elf32-hppa.c: Likewise.
	* elf32-i370.c: Likewise.
	* elf32-i386.c: Likewise.
	* elf32-i860.c: Likewise.
	* elf32-ip2k.c: Likewise.
	* elf32-iq2000.c: Likewise.
	* elf32-lm32.c: Likewise.
	* elf32-m32c.c: Likewise.
	* elf32-m32r.c: Likewise.
	* elf32-m68hc1x.c: Likewise.
	* elf32-m68k.c: Likewise.
	* elf32-mep.c: Likewise.
	* elf32-metag.c: Likewise.
	* elf32-microblaze.c: Likewise.
	* elf32-moxie.c: Likewise.
	* elf32-msp430.c: Likewise.
	* elf32-mt.c: Likewise.
	* elf32-nds32.c: Likewise.
	* elf32-nios2.c: Likewise.
	* elf32-or1k.c: Likewise.
	* elf32-ppc.c: Likewise.
	* elf32-s390.c: Likewise.
	* elf32-score.c: Likewise.
	* elf32-score7.c: Likewise.
	* elf32-sh.c: Likewise.
	* elf32-sh64.c: Likewise.
	* elf32-spu.c: Likewise.
	* elf32-tic6x.c: Likewise.
	* elf32-tilepro.c: Likewise.
	* elf32-v850.c: Likewise.
	* elf32-vax.c: Likewise.
	* elf32-visium.c: Likewise.
	* elf32-xstormy16.c: Likewise.
	* elf32-xtensa.c: Likewise.
	* elf64-alpha.c: Likewise.
	* elf64-hppa.c: Likewise.
	* elf64-ia64-vms.c: Likewise.
	* elf64-mmix.c: Likewise.
	* elf64-ppc.c: Likewise.
	* elf64-s390.c: Likewise.
	* elf64-sh64.c: Likewise.
	* elf64-x86-64.c: Likewise.
	* elflink.c: Likewise.
	* elfnn-aarch64.c: Likewise.
	* elfnn-ia64.c: Likewise.
	* elfxx-mips.c: Likewise.
	* elfxx-sparc.c: Likewise.
	* elfxx-tilegx.c: Likewise.
	* linker.c: Likewise.
	* pdp11.c: Likewise.
	* pe-mips.c: Likewise.
	* reloc.c: Likewise.
	* reloc16.c: Likewise.
	* simple.c: Likewise.
	* vms-alpha.c: Likewise.
	* xcofflink.c: Likewise.
	* elf32-rl78.c (get_symbol_value, get_romstart, get_ramstart): Delete
	status param.  Adjust calls to these and linker callbacks throughout.
	* elf32-rx.c: (get_symbol_value, get_gp, get_romstart,
	get_ramstart): Delete status param.  Adjust calls to these and
	linker callbacks throughout.
ld/
	* ldmain.c (multiple_definition, multiple_common, add_to_set,
	constructor_callback, warning_callback, undefined_symbol,
	reloc_overflow, reloc_dangerous, unattached_reloc): Return void.
	* emultempl/elf32.em: Adjust callback calls.
gdb/
	* compile/compile-object-load.c (link_callbacks_multiple_definition,
	link_callbacks_warning, link_callbacks_undefined_symbol,
	link_callbacks_undefined_symbol, link_callbacks_reloc_overflow,
	link_callbacks_reloc_dangerous,
	link_callbacks_unattached_reloc): Return void.
2016-05-28 11:17:20 +09:30
Pedro Alves
744608cc85 Skip attach-many-short-lived-threads.exp on known-broken DejaGnu versions
If the testsuite is run with a DejaGnu version that predates the fix
from last year:

  [PATCH] DejaGnu kills the wrong process due to PID-reuse races
  http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00005.html

... gdb.threads/attach-many-short-lived-threads.exp fails randomly,
often.  Other tests randomly fail due to that issue too, but this one
is _much_ more exposed.

DejaGnu 1.6 was released meanwhile, which includes that DejaGnu fix,
and also some distros backported the fix too.

So skip the test when run with older/broken DejaGnus.

gdb/testsuite/ChangeLog:
2016-05-27  Pedro Alves  <palves@redhat.com>

	* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
	New procedure.
	(top level): Call it, and bail out of DejaGnu is known to be bad.
2016-05-27 16:18:28 +01:00
Eli Zaretskii
c185ba27ca Improve documentation of general query packets
gdb/doc/ChangeLog:

	* gdb.texinfo (General Query Packets): Move the description of the
	response before the long list of the specific 'read' and 'write'
	requests.
2016-05-27 16:59:22 +03:00
Andrew Burgess
51415b9f30 gdb: Forward VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT
When evaluating an expression with EVAL_AVOID_SIDE_EFFECTS if the value
we return is forced to be of type not_lval then GDB will be unable to
take the address of the returned value.

Instead, we should properly initialise the LVAL of the returned value.

This commit builds on two previous commits 2520f728b7 (Forward
VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT) and
ac775bf4d3 (gdb: Forward VALUE_LVAL when avoiding side effects for
STRUCTOP_PTR), which in turn build on ac1ca910d7 (Fixes for PR
exp/15364).

This commit is currently untested due to my lack of access to an OpenCL
compiler, however, if follows the same pattern as the first two commits
mentioned above and so I believe that it is correct.

gdb/ChangeLog:

	* opencl-lang.c (evaluate_subexp_opencl): If
	EVAL_AVOID_SIDE_EFFECTS mode, forward the VALUE_LVAL attribute to
	the returned value in the STRUCTOP_STRUCT case.
2016-05-27 13:07:15 +01:00
Andrew Burgess
ac775bf4d3 gdb: Forward VALUE_LVAL when avoiding side effects for STRUCTOP_PTR
Assume that we have a C program like this:

  struct foo_type
  {
    int var;
  } foo;

  struct foo_type *foo_ptr = &foo;

  int
  main ()
  {
    return foo_ptr->var;
  }

Then GDB should be able to evaluate the following, however, it currently
does not:

  (gdb) start
  ...
  (gdb) whatis &(foo_ptr->var)
  Attempt to take address of value not located in memory.

The problem is that in EVAL_AVOID_SIDE_EFFECTS mode,
eval.c:evaluate_subexp_standard always returns a not_lval value as the
result for a STRUCTOP_PTR operation. As a consequence, the rest of
the code believes that one cannot take the address of the returned
value.

This patch fixes STRUCTOP_PTR handling so that the VALUE_LVAL
attribute for the returned value is properly initialized.  After this
change, the above session becomes:

  (gdb) start
  ...
  (gdb) whatis &(foo_ptr->var)
  type = int *

This commit is largely the same as commit 2520f728b7 (Forward
VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT) but applied
to STRUCTOP_PTR rather than STRUCTOP_STRUCT.  Both of these commits are
building on top of commit ac1ca910d7 (Fixes for PR exp/15364).

gdb/ChangeLog:

	* eval.c (evaluate_subexp_standard): If EVAL_AVOID_SIDE_EFFECTS
	mode, forward the VALUE_LVAL attribute to the returned value in
	the STRUCTOP_PTR case.

gdb/testsuite/ChangeLog:

	* gdb.base/whatis.c: Extend the test case.
	* gdb.base/whatis.exp: Add additional tests.
2016-05-27 13:06:25 +01:00
Tom Tromey
7bd787e877 fix spelling of HAVE_LIBPYTHON2_4 in py-value.c
Ulrich pointed out that an earlier patch had misspelled
HAVE_LIBPYTHON2_4, adding an extra "_".  This caused a build failure.
This patch fixes the bug.

2016-05-25  Tom Tromey  <tom@tromey.com>

	* python/py-value.c (value_object_as_number): Use correct spelling
	of HAVE_LIBPYTHON2_4.
2016-05-25 07:54:44 -06:00
Bernhard Heckel
2bbad2ea11 Fortran, typeprint: Forward level of details to be printed for pointers.
Variable "show" was hardcoded to zero for pointer and reference types.
This implementation didn't allow a correct "whatis" print
for those types and results in same output for "ptype" and "whatis".

Before:
(gdb) whatis t3p
type = PTR TO -> ( Type t3
    integer(kind=4) :: t3_i
    Type t2 :: t2_n
End Type t3 )

After:
(gdb) whatis t3p
type = PTR TO -> ( Type t3 )

2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/Changelog:
	* f-typeprint.c (f_type_print_base): Replace 0 by show.

gdb/testsuite/Changelog:
	* gdb.fortran/type.f90: Add pointer variable.
	* gdb.fortran/whatis_type.exp: Add whatis/ptype of pointers.
2016-05-25 08:47:18 +02:00
Bernhard Heckel
8b70175dfa Fortran, testsuite: Fix duplicate testcase name.
2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/testsuite/Changelog:
	* gdb.fortran/vla-type.exp: Fix testcase name.
2016-05-25 08:47:18 +02:00
Bernhard Heckel
86d8a84882 Fortran, testsuite: Add testcases for nested structures.
As as result of printing only the outer elements of nested structures,
some testcases have to be added to check for corner cases with VLA's.

2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/testsuite/Changelog:
	* gdb.fortran/vla-type.exp: Access elements in nested structs.
2016-05-25 08:47:18 +02:00
Bernhard Heckel
e188eb3621 Fortran, typeprint: Decrease level of details when printing elements of a structure.
According to the typeprint's description, the level of details is
decreased by one for the typeprint of elements of a structure.

Before:
(gdb) ptype t3v
type = Type t3
    integer(kind=4) :: t3_i
    Type t2
        integer(kind=4) :: t2_i
        Type t1
            integer(kind=4) :: t1_i
            real(kind=4) :: t1_r
        End Type t1 :: t1_n
    End Type t2 :: t2_n
End Type t3

After:
(gdb) ptype t3v
type = Type t3
    integer(kind=4) :: t3_i
    Type t2 :: t2_n
End Type t3

2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/Changelog:
	* f-typeprint.c (f_type_print_base): Decrease show by one.

gdb/testsuite/Changelog:
	* gdb.fortran/type.f90: Add nested structures.
	* gdb.fortran/whatis-type.exp: Whatis/ptype nested structures.
	* gdb.fortran/derived-type.exp: Adapt expected output.
	* gdb.fortran/vla-type.exp: Adapt expected output.
2016-05-25 08:47:17 +02:00
Bernhard Heckel
9b2db1fd27 Fortran, typeprint: Take level of details into account when printing elements of a structure.
According to the typeprint's description, elements of a structure
should not be printed when show is < 1.
This variable is also used to distinguish the level of details
between "ptype" and "whatis" expressions.

Before:
(gdb) whatis t1v
type = Type t1
    integer(kind=4) :: t1_i
    real(kind=4) :: t1_r
End Type t1

After:
(gdb) whatis t1v
type = Type t1

2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/Changelog:
	* f-typeprint.c (f_type_print_base): Don't print fields when show < 0.

gdb/testsuite/Changelog:
	* gdb.fortran/whatis_type.exp: Adapt expected output.
2016-05-25 08:47:17 +02:00
Bernhard Heckel
72b1705502 Fortran, typeprint: Fix wrong indentation when ptype nested structures.
Level of indentation was not proper handled when printing
the elements type's name.

Before:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1

After:
type = Type t1
    integer(kind=4) :: var_1
    integer(kind=4) :: var_2
End Type t1

2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/Changelog:
	* f-typeprint.c (f_type_print_base): Take print level into account.

gdb/testsuite/Changelog:
	* gdb.fortran/print_type.exp: Fix expected output.
	* gdb.fortran/whatis_type.exp: Fix expected output.
2016-05-25 08:47:16 +02:00
Bernhard Heckel
3cd81d8df7 Fortran, testsuite: Use multi_line in whatis_type testcase.
2016-05-25  Bernhard Heckel  <bernhard.heckel@intel.com>

gdb/testsuite/Changelog:
	* gdb.fortran/whatis_type.exp: Use multi_line.
2016-05-25 08:47:16 +02:00
Tom Tromey
ddae946278 Fix PR python/17386 - add __index__ method to gdb.Value
This patch fixes PR python/17386.

The bug is that gdb.Value does not implement the Python __index__
method.  This method is needed to convert a Python object to an index
and is used by various operations in Python, such as indexing an
array.

The fix is to implement the nb_index method for gdb.Value.

nb_index was added in Python 2.5.  I don't have a good way to test
Python 2.4, but I made an attempt to accomodate it.

I chose to use valpy_long in all cases because this simplifies porting
to Python 3, and because there didn't seem to be any harm.

Built and regtested on x86-64 Fedora 23.

2016-05-24  Tom Tromey  <tom@tromey.com>

	PR python/17386:
	* python/py-value.c (value_object_as_number): Add
	nb_inplace_floor_divide, nb_inplace_true_divide, nb_index.

2016-05-24  Tom Tromey  <tom@tromey.com>

	PR python/17386:
	* gdb.python/py-value.exp (test_value_numeric_ops): Add tests that
	use value as an index.
2016-05-24 10:05:59 -06:00
Tom Tromey
e2b7f516fc add nb_inplace_divide for python 2
Python 2's PyNumberMethods has nb_inplace_divide, but Python 3 does
not.  This patch adds it for Python 2.

This buglet didn't cause much fallout because the only non-NULL entry
in value_object_as_number after this is for valpy_divide; and the
missing slot caused it to slide up to nb_floor_divide (where
nb_true_divide was intended).

2016-05-24  Tom Tromey  <tom@tromey.com>

	* python/py-value.c (value_object_as_number): Add
	nb_inplace_divide for Python 2.
2016-05-24 10:05:58 -06:00
Tom Tromey
1957f6b89f Fix PR python/17981
PR python/17981 notes that gdb.breakpoints() returns None when there
are no breakpoints; whereas an empty list or tuple would be more in
keeping with Python and the documentation.

This patch fixes the bug by changing the no-breakpoint return to make
an empty tuple.

Built and regtested on x86-64 Fedora 23.

2016-05-23  Tom Tromey  <tom@tromey.com>

	PR python/17981:
	* python/py-breakpoint.c (gdbpy_breakpoints): Return a new tuple
	when there are no breakpoints.

2016-05-23  Tom Tromey  <tom@tromey.com>

	* python.texi (Basic Python): Document gdb.breakpoints return.

2016-05-23  Tom Tromey  <tom@tromey.com>

	PR python/17981:
	* gdb.python/py-breakpoint.exp (test_bkpt_basic): Add test for
	no-breakpoint case.
2016-05-24 09:55:01 -06:00
Tom Tromey
224f10c1ae PR gdb/19194 - fix typo in the manual
PR gdb/19194 points out a typo in the documentation.  I'm checking
this in as obvious.

2016-05-24  Tom Tromey  <tom@tromey.com>

	PR gdb/19194:
	* gdb.texinfo (gdb man): Fix typo.
2016-05-24 09:41:39 -06:00
Pedro Alves
026a917475 Fix PR gdb/19828: gdb -p <process from a container>: internal error
When GDB attaches to a process, it looks at the /proc/PID/task/ dir
for all clone threads of that process, and attaches to each of them.

Usually, if there is more than one clone thread, it means the program
is multi threaded and linked with pthreads.  Thus when GDB soon after
attaching finds and loads a libthread_db matching the process, it'll
add a thread to the thread list for each of the initially found
lower-level LWPs.

If, however, GDB fails to find/load a matching libthread_db, nothing
is adding the LWPs to the thread list.  And because of that, "detach"
hits an internal error:

  (gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
  info threads
    Id   Target Id         Frame
  * 1    LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
  (gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
  detach
  .../src/gdb/thread.c:1010: internal-error: is_executing: 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.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)

From here:

  ...
  #8  0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
      at .../src/gdb/common/errors.c:55
  #9  0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
  #10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
  #11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
  #12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
  #13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
  #14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
  #15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
  #16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
  ...

Tested on x86-64 Fedora 23.  Also confirmed the test passes against
gdbserver with "maint set target-non-stop".

gdb/ChangeLog:
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
	resumed, and add the thread to GDB's thread list.

testsuite/ChangeLog:
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* gdb.threads/clone-attach-detach.c: New file.
	* gdb.threads/clone-attach-detach.exp: New file.
2016-05-24 14:51:32 +01:00
Pedro Alves
72b049d38c Make gdb/linux-nat.c consider a waitstatus pending on the infrun side
Working on the fix for gdb/19828, I saw
gdb.threads/attach-many-short-lived-threads.exp fail once in an
unusual way.  Unfortunately I didn't keep debug logs, but it's an
issue similar to what's been fixed in remote.c a while ago --
linux-nat.c was not fetching the pending status from the right place.

gdb/ChangeLog:
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (get_pending_status): If the thread reported the
	event to the core and it's pending, use the pending status signal
	number.
2016-05-24 14:51:03 +01:00
Pedro Alves
774113b02f [Linux] Optimize PID -> struct lwp_info lookup
Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens, and running gdb under
perf, I saw that GDB was spending most of the time in find_lwp_pid:

   - captured_main
      - 93.61% catch_command_errors
         - 87.41% attach_command
            - 87.40% linux_nat_attach
               - 87.40% linux_proc_attach_tgid_threads
                  - 82.38% attach_proc_task_lwp_callback
                     - 81.01% find_lwp_pid
                          5.30% ptid_get_lwp
                        + 0.10% ptid_lwp_p
                     + 0.64% add_thread
                     + 0.26% set_running
                     + 0.24% set_executing
                       0.12% ptid_get_lwp
                     + 0.01% ptrace
                     + 0.01% add_lwp

attach_proc_task_lwp_callback is called once for each LWP that we
attach to, found by listing the /proc/PID/task/ directory.  In turn,
attach_proc_task_lwp_callback calls find_lwp_pid to check whether the
LWP we're about to try to attach to is already known.  Since
find_lwp_pid does a linear walk over the whole LWP list, this becomes
quadratic.  We do the /proc/PID/task/ listing until we get two
iterations in a row where we found no new threads.  So the second and
following times we walk the /proc/PID/task/ dir, we're going to take
an even worse find_lwp_pid hit.

Fix this by adding a hash table keyed by LWP PID, for fast lookup.

The linked list embedded in the LWP structure itself is kept, and made
a double-linked list, so that removals from that list are O(1).  An
earlier version of this patch got rid of this list altogether, but
that revealed hidden dependencies / assumptions on how the list is
sorted.  For example, killing a process and then waiting for all the
LWPs status using iterate_over_lwps only works as is because the
leader LWP is always last in the list.  So I thought it better to take
an incremental approach and make this patch concern itself _only_ with
the PID lookup optimization.

gdb/ChangeLog:
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (lwp_lwpid_htab): New htab.
	(lwp_info_hash, lwp_lwpid_htab_eq, lwp_lwpid_htab_create)
	(lwp_lwpid_htab_add_lwp): New functions.
	(lwp_list): Tweak comment.
	(lwp_list_add, lwp_list_remove, lwp_lwpid_htab_remove_pid): New
	functions.
	(purge_lwp_list): Rewrite, using htab_traverse_noresize.
	(add_initial_lwp): Add lwp to htab too.  Use lwp_list_add.
	(delete_lwp): Use lwp_list_remove.  Remove htab too.
	(find_lwp_pid): Search in htab.
	(_initialize_linux_nat): Call lwp_lwpid_htab_create.
	* linux-nat.h (struct lwp_info) <prev>: New field.
2016-05-24 14:50:37 +01:00
Pedro Alves
1ad3de988d [Linux] Avoid refetching core-of-thread if thread hasn't run
Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens, I saw GDB having trouble
keeping up with threads being spawned too fast, when it tried to stop
them all.  This was because while gdb is doing that, it updates the
thread list to make sure no new thread has sneaked in that might need
to be paused.  It does this a few times until it sees no-new-threads
twice in a row.  The thread listing update itself is not that
expensive, however, in the Linux backend, updating the threads list
calls linux_common_core_of_thread for each LWP to record on which core
each LWP was last seen running, which opens/reads/closes a /proc file
for each LWP which becomes expensive when you need to do it for
thousands of LWPs.

perf shows gdb in linux_common_core_of_thread 44% of the time, in the
stop_all_threads -> update_thread_list path in this use case.

This patch simply makes linux_common_core_of_thread avoid updating the
core the thread is bound to if the thread hasn't run since the last
time we updated that info.  This makes linux_common_core_of_thread
disappear into the noise in the perf report.

gdb/ChangeLog:
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (linux_resume_one_lwp_throw): Clear the LWP's core
	field.
	(linux_nat_update_thread_list): Don't fetch the core if already
	known.
2016-05-24 14:48:57 +01:00
Pedro Alves
95e94c3f18 [Linux] Read vDSO range from /proc/PID/task/PID/maps instead of /proc/PID/maps
... as it's _much_ faster.

Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens to stress and debug
timeout problems with gdb.threads/attach-many-short-lived-threads.exp,
I saw that GDB would spend several seconds just reading the
/proc/PID/smaps file, to determine the vDSO mapping range.  GDB opens
and reads the whole file just once, and caches the result, but even
that is too slow.  For example, with almost 8000 threads:

 $ ls /proc/3518/task/ | wc -l
 7906

reading the /proc/PID/smaps file grepping for "vdso" takes over 15
seconds :

 $ time cat /proc/3518/smaps | grep vdso
 7ffdbafee000-7ffdbaff0000 r-xp 00000000 00:00 0                          [vdso]

 real    0m15.371s
 user    0m0.008s
 sys     0m15.017s

Looking around the web for hints, I found a nice description of the
issue here:

 http://backtrace.io/blog/blog/2014/11/12/large-thread-counts-and-slow-process-maps/

The problem is that /proc/PID/smaps wants to show the mappings as
being thread stack, and that has the kernel iterating over all threads
in the thread group, for each mapping.

The fix is to use the "map" file under /proc/PID/task/PID/ instead of
the /proc/PID/ one, as the former doesn't mark thread stacks for all
threads.

That alone drops the timing to the millisecond range on my machine:

 $ time cat /proc/3518/task/3518/smaps | grep vdso
 7ffdbafee000-7ffdbaff0000 r-xp 00000000 00:00 0                          [vdso]

 real    0m0.150s
 user    0m0.009s
 sys     0m0.084s

And since we only need the vdso mapping's address range, we can use
"maps" file instead of "smaps", and it's even cheaper:

/proc/PID/task/PID/maps :

 $ time cat /proc/3518/task/3518/maps | grep vdso
 7ffdbafee000-7ffdbaff0000 r-xp 00000000 00:00 0                          [vdso]

 real    0m0.027s
 user    0m0.000s
 sys     0m0.017s

gdb/ChangeLog:
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-tdep.c (find_mapping_size): Delete.
	(linux_vsyscall_range_raw): Rewrite reading from
	/proc/PID/task/PID/maps directly instead of using
	gdbarch_find_memory_regions.
2016-05-24 14:48:34 +01:00
Pedro Alves
aa01bd3689 Linux native thread create/exit events support
A following patch (fix for gdb/19828) makes linux-nat.c add threads to
GDB's thread list earlier in the "attach" sequence, and that causes a
surprising regression on
gdb.threads/attach-many-short-lived-threads.exp on my machine.  The
extra "thread x exited" handling and traffic slows down that test
enough that GDB core has trouble keeping up with new threads that are
spawned while trying to stop existing ones.

I saw the exact same issue with remote/gdbserver a while ago and fixed
it in 65706a29ba (Remote thread create/exit events) so part of the
fix here is the exact same -- add support for thread created events to
gdb/linux-nat.c.  infrun.c:stop_all_threads enables those events when
it tries to stop threads, which ensures that new threads never get a
chance to themselves start new threads, thus fixing the race.

gdb/
2016-05-24  Pedro Alves  <palves@redhat.com>

	PR gdb/19828
	* linux-nat.c (report_thread_events): New global.
	(linux_handle_extended_wait): Report
	TARGET_WAITKIND_THREAD_CREATED if thread event reporting is
	enabled.
	(wait_lwp, linux_nat_filter_event): Report all thread exits if
	thread event reporting is enabled.  Remove comment.
	(filter_exit_event): New function.
	(linux_nat_wait_1): Use it.
	(linux_nat_thread_events): New function.
	(linux_nat_add_target): Install it as target_thread_events method.
2016-05-24 14:47:56 +01:00
Francis Ricci
e70a7231e6 Fix syntax error in annota-input-while-running.exp
This patch fixes a syntax error which caused a failure in
annota-input-while-running.exp to crash the test suite runner.

2016-05-24  Francis Ricci  <francisjricci@gmail.com>

	* gdb.base/annota-input-while-running.exp: Fix syntax error.
2016-05-24 12:11:38 +01:00
Yan-Ting Lin
00a3cb9c7c Add myself as a write-after-approval GDB maintainer
gdb/ChangeLog:

	* MAINTAINERS (Write After Approval): Add "Yan-Ting Lin".
2016-05-24 16:47:14 +08:00
Yao Qi
7eb895307f Skip unwritable frames in command "finish"
Nowadays, GDB can't insert breakpoint on the return address of the
exception handler on ARM M-profile, because the address is a magic
one 0xfffffff9,

 (gdb) bt
 #0  CT32B1_IRQHandler () at ../src/timer.c:67
 #1  <signal handler called>
 #2  main () at ../src/timer.c:127

(gdb) info frame
Stack level 0, frame at 0x200ffa8:
 pc = 0x4ec in CT32B1_IRQHandler (../src/timer.c:67); saved pc = 0xfffffff9
 called by frame at 0x200ffc8
 source language c.
 Arglist at 0x200ffa0, args:
 Locals at 0x200ffa0, Previous frame's sp is 0x200ffa8
 Saved registers:
  r7 at 0x200ffa0, lr at 0x200ffa4

(gdb) x/x 0xfffffff9
0xfffffff9:     Cannot access memory at address 0xfffffff9

(gdb) finish
Run till exit from #0  CT32B1_IRQHandler () at ../src/timer.c:67
Ed:15: Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)

Warning:
Cannot insert hardware breakpoint 0.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

Command aborted.

even some debug probe can't set hardware breakpoint on the magic
address too,

(gdb) hbreak *0xfffffff9
Hardware assisted breakpoint 2 at 0xfffffff9
(gdb) c
Continuing.
Ed:15: Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)

Warning:
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

Command aborted.

The problem described above is quite similar to PR 8841, in which GDB
can't set breakpoint on signal trampoline, which is mapped to a read-only
page by kernel.  The rationale of this patch is to skip "unwritable"
frames when looking for caller frames in command "finish", and a new
gdbarch method code_of_frame_writable is added.  This patch fixes
the problem on ARM cortex-m target, but it can be used to fix
PR 8841 too.

gdb:

2016-05-10  Yao Qi  <yao.qi@arm.com>

	* arch-utils.c (default_code_of_frame_writable): New function.
	* arch-utils.h (default_code_of_frame_writable): Declare.
	* arm-tdep.c (arm_code_of_frame_writable): New function.
	(arm_gdbarch_init): Install gdbarch method
	code_of_frame_writable if the target is M-profile.
	* frame.c (skip_unwritable_frames): New function.
	* frame.h (skip_unwritable_frames): Declare.
	* gdbarch.sh (code_of_frame_writable): New.
	* gdbarch.c, gdbarch.h: Re-generated.
	* infcmd.c (finish_command): Call skip_unwritable_frames.
2016-05-23 17:32:56 +01:00
Tom Tromey
0f6ed0e0ef Fix PR python/19438, PR python/18393 - initialize dictionaries
This fixes PR python/19438 and PR python/18393.  Both bugs are about
invoking dir() on some Python object implemented by gdb, and getting a
crash.

The crash happens because the dictionary field of these objects was
not initialized.  Apparently what happens is that this field can be
lazily initialized by Python when assigning to an attribute; and it
can also be handled ok when using dir() but without __dict__ defined;
but gdb defines __dict__ because this isn't supplied automatically by
Python.

The docs on this seem rather sparse, but this patch works ok.

An alternative might be to lazily create the dictionary in
gdb_py_generic_dict, but I went with this approach because it seemed
more straightforward.

Built and regtested on x86-64 Fedora 23.

2016-05-23  Tom Tromey  <tom@tromey.com>

	PR python/19438, PR python/18393:
	* python/py-objfile.c (objfpy_initialize): Initialize self->dict.
	* python/py-progspace.c (pspy_initialize): Initialize self->dict.

2016-05-23  Tom Tromey  <tom@tromey.com>

	PR python/19438, PR python/18393:
	* gdb.python/py-progspace.exp: Add "dir" test.
	* gdb.python/py-objfile.exp: Add "dir" test.
2016-05-23 10:08:34 -06:00
Yao Qi
ffd19d610b Use standard_testfile in gdb.arch/thumb-prologue.exp and gdb.arch/thumb2-it.exp
This patch fixes the errors below:

Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb-prologue.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb-prologue: No such file or directory
collect2: error: ld returned 1 exit status
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb2-it.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb2-it: No such file or directory

gdb/testsuite:

2016-05-23  Yao Qi  <yao.qi@linaro.org>

	* gdb.arch/thumb-prologue.exp: Use standard_testfile.
	* gdb.arch/thumb2-it.exp: Likewise.
2016-05-23 15:50:56 +01:00
Gary Benson
d0571b9934 Remove unused libthread_db td_thr_validate reference
Native GDB looks up the function td_thr_validate from libthread_db.so
on Linux, but the value is never used.  This commit removes this dead
code.

gdb/ChangeLog:

	* nat/gdb_thread_db.h (td_thr_validate_ftype): Remove typedef.
	* linux-thread-db.c (struct thread_db_info) <td_thr_validate_p>:
	Remove field.
	(try_thread_db_load_1): Remove td_thr_validate initialization.
2016-05-23 13:26:47 +01:00
Jon Boden
37773e7803 Search for libutil-freebsd as alternative to libutil
GDB needs kinfo_getvmmap() on GNU/kFreeBSD systems same as on
pure FreeBSD.  However on these systems the FreeBSD version of libutil
is renamed to libutil-freebsd.

2016-05-23  Jon Boden  <jon@ubuntubsd.org>

	* configure.ac: Search for libutil-freebsd as alternative to libutil.
	* configure: Re-generated.
2016-05-23 08:46:33 +01:00
Andreas Schwab
bfb0d950a5 Fix invalid implicit conversions from void *
* ia64-libunwind-tdep.c (libunwind_descr): Add cast from void *.
	(libunwind_frame_set_descr): Likewise.
	(libunwind_frame_cache): Likewise.
	(libunwind_frame_dealloc_cache): Likewise.
	(libunwind_frame_sniffer): Likewise.
	(libunwind_search_unwind_table): Likewise.
	(libunwind_sigtramp_frame_sniffer): Likewise.
	(libunwind_get_reg_special): Likewise.
	(libunwind_load): Likewise.
	* ia64-linux-nat.c (ia64_linux_fetch_register): Likewise.
	(ia64_linux_store_register): Likewise.
	(ia64_linux_xfer_partial): Likewise.
	* ia64-tdep.c (ia64_access_reg): Likewise.
	(ia64_access_fpreg): Likewise.
	(ia64_access_rse_reg): Likewise.
	(ia64_access_rse_fpreg): Likewise.
2016-05-19 15:31:56 +02:00
Tom Tromey
45f4ed92d1 Fix build failure with GCC 4.1.
2016-05-18  Tom Tromey  <tom@tromey.com>

	* rust-lang.c (rust_subscript): Initialize "high".
2016-05-18 11:15:31 -06:00
Simon Marchi
9e8f9b05ad Add mi-threads-interrupt.exp test (PR 20039)
Add a new test for PR 20039.  The test spawns new threads, then tries to
interrupt, continue, and interrupt again.  This use case was fixed by
commit 5fe966540d in master, but gdb 7.11
is affected (so if you try it on the gdb-7.11-branch right now, the test
will fail).

New in v2, the test now handles mi-async on mode properly.  The failure
was specific to mi-async off, but I don't think it's bad to test the
same thing under async on mode.  I added a little hack when running in
async mode to work around bug 20045.

I also removed one continue/interrupt pair, as a single one was enough to
trigger the problem.

gdb/testsuite/ChangeLog:

	* gdb.mi/mi-threads-interrupt.c: New file.
	* gdb.mi/mi-threads-interrupt.exp: New file.
2016-05-18 10:13:16 -04:00
Simon Marchi
28addb40c7 Fix double prompt output after run control MI commands with mi-async on (PR 20045)
When you use a run control command (-exec-run, -exec-continue,
-exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed:

  -exec-continue
  ^running
  *running,thread-id="all"
  (gdb)
  (gdb)

It doesn't seem to be a big problem for front-ends, since this behavior
started in gdb 7.9 and we haven't heard anything about that.  However,
it caused me some trouble while writing a test for PR 20039 [1].

The problem comes from an extra (gdb) prompt that we write when running
in mi-async off mode to emulate a past buggy behavior.  When executing a
run control command synchronously, previous gdbs always printed a prompt
right away, even though they are not ready to accept new MI commands
until the target stops.  Only at this time should they display a prompt.
But to keep backwards compatibility apparently, we print it anyway.
Since commit 198297aaf, the condition that decides whether we should
print that "bogus" prompt or not has become true, even when running with
mi-async on.  Since we already print a prompt at the end of the
asynchronous command execution, it results in two prompts for one
command.

The proposed fix is to call target_can_async_p instead of
target_is_async_p, to make the condition:

  if (!target_can_async_p () || sync_execution)
    ... show prompt ...

That shows the prompt if we are emulating a synchronous command on top
of an asynchronous target (sync_execution) or if the target simply can't
run asynchronously (!target_can_async_p ()).

Note that this code is changed and this bug fixed by Pedro's separate
console series, but I think it would be nice to have it fixed in the
mean time.

I ran the gdb.mi directory of the testsuite with mi-async on and off, I
didn't see any regressions.

gdb/ChangeLog:

	* mi/mi-main.c (mi_on_resume): Call target_can_async_p instead
	of target_is_async_p.

[1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html
2016-05-18 10:12:54 -04:00
Simon Marchi
61c6156df6 Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077)
When doing -exec-run on a freshly started GDB, the only target on the
target stack at the time the dummy one.  When mi_async_p is called to
know whether the run should be async, it queries whether the current
target (dummy) supports async, and the answer is no.  The fix is to make
the code query the target that will be used for the run, which is not
necessarily the current target.

No regressions in the gdb.mi directory using the unix, native-gdbserver
and native-extended-gdbserver boards.  The test doesn't pass when
forcing maint set target-async off, obviously, since it makes mi-async
have no effect.  It doesn't seem like other tests are checking for that
eventuality, so I didn't in the new test.

gdb/ChangeLog:

	* mi/mi-main.c (run_one_inferior): Use run target to determine
	whether to run async or not.
	(mi_cmd_exec_run): Likewise.

gdb/testsuite/ChangeLog:

	* gdb.mi/mi-async-run.exp: New file.
	* gdb.mi/mi-async-run.c: New file.
2016-05-17 16:46:18 -04:00
Tom Tromey
01739a3b6a Rename OP_F90_RANGE to OP_RANGE.
This renames OP_F90_RANGE to OP_RANGE, and similarly renames the
f90_range_type enum.

2016-05-17  Tom Tromey  <tom@tromey.com>

	* std-operator.def (OP_RANGE): Rename from OP_F90_RANGE.
	* rust-lang.c: Don't include f-lang.h.
	(rust_range, rust_compute_range, rust_subscript)
	(rust_evaluate_subexp): Update.
	* rust-exp.y: Don't include f-lang.h.
	(ast_range, convert_ast_to_expression): Update.
	* parse.c (operator_length_standard): Update.
	* f-lang.h (enum f90_range_type): Move to expression.h.
	* f-exp.y: Use OP_RANGE.
	* expression.h (enum range_type): New enum; renamed from
	f90_range_type.
	* expprint.c: Don't include f-lang.h.
	(print_subexp_standard, dump_subexp_body_standard): Use OP_RANGE.
	* eval.c (value_f90_subarray, evaluate_subexp_standard): Update.
2016-05-17 12:02:03 -06:00
Tom Tromey
0bdfa368bc Add Rust documentation
This patch adds documentation for the new Rust support in gdb.

2016-05-17  Tom Tromey  <tom@tromey.com>

	* NEWS: Add Rust item.

2016-05-17  Tom Tromey  <tom@tromey.com>

	* gdb.texinfo (Supported Languages): Mention Rust.  Update menu.
	(Rust): New node.
2016-05-17 12:02:02 -06:00
Tom Tromey
67218854b1 Update gdb test suite for Rust
This updates the gdb test suite for Rust.

2016-05-17  Tom Tromey  <tom@tromey.com>
	    Manish Goregaokar <manishsmail@gmail.com>

	* lib/rust-support.exp: New file.
	* lib/gdb.exp (skip_rust_tests): New proc.
	(build_executable_from_specs): Handle rust.
	* lib/future.exp (gdb_find_rustc): New proc.
	(gdb_default_target_compile): Handle rust.
	* gdb.rust/expr.exp: New file.
	* gdb.rust/generics.exp: New file.
	* gdb.rust/generics.rs: New file.
	* gdb.rust/methods.exp: New file.
	* gdb.rust/methods.rs: New file.
	* gdb.rust/modules.exp: New file.
	* gdb.rust/modules.rs: New file.
	* gdb.rust/simple.exp: New file.
	* gdb.rust/simple.rs: New file.
2016-05-17 12:02:01 -06:00
Tom Tromey
c44af4ebc0 Add support for the Rust language
This patch adds support for the Rust language.

2016-05-17  Tom Tromey  <tom@tromey.com>
	    Manish Goregaokar <manishsmail@gmail.com>

	* symtab.c (symbol_find_demangled_name): Handle Rust.
	* symfile.c (init_filename_language_table): Treat ".rs" as Rust.
	* std-operator.def (STRUCTOP_ANONYMOUS, OP_RUST_ARRAY): New
	constants.
	* rust-lang.h: New file.
	* rust-lang.c: New file.
	* rust-exp.y: New file.
	* dwarf2read.c (read_file_scope): Add Rust producer sniffing.
	(dwarf2_compute_name, read_func_scope, read_structure_type)
	(read_base_type, read_subrange_type, set_cu_language)
	(new_symbol_full, determine_prefix): Handle Rust.
	* defs.h (enum language) <language_rust>: New constant.
	* Makefile.in (SFILES): Add rust-exp.y, rust-lang.c.
	(COMMON_OBS): Add rust-exp.o, rust-lang.o.

2016-05-17  Tom Tromey  <tom@tromey.com>

	* gdb.base/default.exp (set language): Add rust.
2016-05-17 12:02:00 -06:00
Tom Tromey
00272ec4b0 Add array start and end strings to generic_val_print_decorations
For Rust value-printing, I wanted to use generic_val_print_array, but
I also wanted to control the starting and ending strings.

This patch adds new strings to generic_val_print_decorations, updates
generic_val_print_array to use them, and updates all the existing
instances of generic_val_print_decorations.

2016-05-17  Tom Tromey  <tom@tromey.com>

	* valprint.h (struct generic_val_print_array) <array_start,
	array_end>: New fields.
	* valprint.c (generic_val_print_array): Add "decorations"
	parameter.  Use "array_start", "array_end".
	(generic_val_print) <TYPE_CODE_ARRAY>: Update.
	* p-valprint.c (p_decorations): Update.
	* m2-valprint.c (m2_decorations): Update.
	* f-valprint.c (f_decorations): Update.
	* c-valprint.c (c_decorations): Update.
2016-05-17 12:02:00 -06:00