Set GDB version number to 7.10.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.10.1.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix regression by Do not skip prologue for asm (.S) files

Patch "Do not skip prologue for asm (.S) files" [1] changes GDB's
behaviour on which test gdb.arch/thumb-singlestep.exp depends, so
it causes the fail below:

 (gdb) si^M
 37              blx     foo^M
 (gdb) FAIL: gdb.arch/thumb-singlestep.exp: step into foo

the test assumes the program will stop at the instruction after "push"
but it doesn't.  The fix to this fail is to do one more single step.

[1] https://sourceware.org/ml/gdb-patches/2015-06/msg00561.html

gdb/testsuite:

2015-12-02  Yao Qi  <yao.qi@linaro.org>

* gdb.arch/thumb-singlestep.exp: Do one more single step.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Adjust GDB to demangler API change

Before commit 3a8724032abf, DEMANGLE_COMPONENT_CAST was used for both
casts and conversion operators.  We now have
DEMANGLE_COMPONENT_CONVERSION for the latter.

gdb/ChangeLog:
2014-11-28  Pedro Alves  <palves@redhat.com>

* cp-name-parser.y (conversion_op): Use
DEMANGLE_COMPONENT_CONVERSION instead of DEMANGLE_COMPONENT_CAST.

PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template<int> struct A {};
 template <typename Y> void function_temp(A<sizeof ((Y)(999))>) {}
 template void function_temp<int>(A<sizeof (int)>);

The 'function_temp<int>' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
    name 'function_temp'
    template argument list
      builtin type int
  function type
    builtin type void
    argument list
      template                          (*)
        name 'A'
        template argument list
          unary operator
            operator sizeof
            unary operator
              cast
                template parameter 0    (**)
              literal
                builtin type int
                name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
       const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
      the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
     {
       dpt.next = dpi->templates;
       dpi->templates = &dpt;
       dpt.template_decl = dpi->current_template;
     }

when printing the template argument list of A (what should be "<sizeof
(int)>"), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template <typename U> explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int options,
        d_print_comp (dpi, options, dc->u.s_extended_operator.name);
        return;

     case DEMANGLE_COMPONENT_CAST:
       d_append_string (dpi, "operator ");
 -     d_print_cast (dpi, options, dc);
 +     d_print_conversion (dpi, options, dc);
       return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  <palves@redhat.com>

        PR other/61321
        PR other/61233
        * demangle.h (enum demangle_component_type)
        <DEMANGLE_COMPONENT_CONVERSION>: New value.
        * cp-demangle.c (d_demangle_callback, d_make_comp): Handle
        DEMANGLE_COMPONENT_CONVERSION.
        (is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
        instead of DEMANGLE_COMPONENT_CAST.
        (d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
        component if handling a conversion.
        (d_count_templates_scopes, d_print_comp_inner): Handle
        DEMANGLE_COMPONENT_CONVERSION.
        (d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
        of DEMANGLE_COMPONENT_CAST.
        (d_print_cast): Rename as ...
        (d_print_conversion): ... this.  Adjust comments.
        (d_print_cast): Rewrite - simply print the left subcomponent.
        * cp-demint.c (cplus_demangle_fill_component): Handle
        DEMANGLE_COMPONENT_CONVERSION.

        * testsuite/demangle-expected: Add tests.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231020 138bc75d-0d04-0410-961f-82ee72b054a4

Implement N4514, C++ Extensions for Transactional Memory.

gcc/
* builtins.def (BUILT_IN_ABORT): Add transaction_pure attribute.
gcc/c-family/
* c-common.c (c_common_reswords): Add C++ TM TS keywords.
(c_common_attribute_table): Add transaction_safe_dynamic.
transaction_safe now affects type identity.
(handle_tm_attribute): Handle transaction_safe_dynamic.
* c-common.h (enum rid): Add RID_ATOMIC_NOEXCEPT,
RID_ATOMIC_CANCEL, RID_SYNCHRONIZED.
(OBJC_IS_CXX_KEYWORD): Add RID_SYNCHRONIZED.
(D_TRANSMEM): New.
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_transactional_memory.
* c-pretty-print.c (pp_c_attributes_display): Don't print
transaction_safe in C++.
gcc/c/
* c-parser.c (c_lex_one_token): Handle @synchronized.
* c-decl.c (match_builtin_function_types): A declaration of a built-in
can change whether the function is transaction_safe.
gcc/cp/
* cp-tree.h (struct cp_declarator): Add tx_qualifier field.
(BCS_NORMAL, BCS_TRANSACTION): New enumerators.
* lex.c (init_reswords): Limit TM kewords to -fgnu-tm.
* parser.c (cp_lexer_get_preprocessor_token): Fix @synchronized.
(make_call_declarator): Take tx_qualifier.
(cp_parser_tx_qualifier_opt): New.
(cp_parser_lambda_declarator_opt): Use it.
(cp_parser_direct_declarator): Likewise.
(cp_parser_statement): Handle atomic_noexcept, atomic_cancel.
(cp_parser_compound_statement): Change in_try parameter to bcs_flags.
(cp_parser_std_attribute): Map optimize_for_synchronized to
transaction_callable.
(cp_parser_transaction): Take the token.  Handle atomic_noexcept.
* lambda.c (maybe_add_lambda_conv_op): Handle transaction-safety.
* call.c (enum conversion_kind): Add ck_tsafe.
(standard_conversion): Handle transaction-safety conversion.
(convert_like_real, resolve_address_of_overloaded_function): Likewise.
(check_methods): Diagnose transaction_safe_dynamic on non-virtual
function.
(look_for_tm_attr_overrides): Don't inherit transaction_safe_dynamic.
* cvt.c (tx_safe_fn_type_p, tx_unsafe_fn_variant)
(can_convert_tx_safety): New.
* typeck.c (composite_pointer_type): Handle transaction-safety.
* name-lookup.h (enum scope_kind): Add sk_transaction.
* name-lookup.c (begin_scope): Handle it.
* semantics.c (begin_compound_stmt): Pass it.
* decl.c (check_previous_goto_1): Check it.
(struct named_label_entry): Add in_transaction_scope.
(poplevel_named_label_1): Set it.
(check_goto): Check it.
(duplicate_decls): A specialization can be transaction_safe
independently of its template.
(grokdeclarator): Handle tx-qualifier.
* rtti.c (ptr_initializer): Handle transaction-safe.
* search.c (check_final_overrider): Check transaction_safe_dynamic.
Don't check transaction_safe.
* mangle.c (write_function_type): Mangle transaction_safe here.
(write_CV_qualifiers_for_type): Not here.
(write_type): Preserve transaction_safe when stripping attributes.
* error.c (dump_type_suffix): Print transaction_safe.
libiberty/
* cp-demangle.c (d_cv_qualifiers): Dx means transaction_safe.
(cplus_demangle_type): Let d_cv_qualifiers handle it.
(d_dump, d_make_comp, has_return_type, d_encoding)
(d_count_templates_scopes, d_print_comp_inner)
(d_print_mod_list, d_print_mod, d_print_function_type)
(is_ctor_or_dtor): Handle DEMANGLE_COMPONENT_TRANSACTION_SAFE.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228462 138bc75d-0d04-0410-961f-82ee72b054a4

Demangler: Fix constructor names with ABI tags

The symbol _ZNSt8ios_base7failureB5cxx11C1EPKcRKSt10error_code, which
appears in libstdc++, was being demangled as

std::ios_base::failure[abi:cxx11]::cxx11(char const*, std::error_code const&)

That is clearly incorrect: std::ios_base::failure does not have a
method cxx11, and anyhow if you look closely at the mangled name you
will see that it is supposed to be a constructor.  This patch fixes
the demangler to generate the correct demangling, namely

std::ios_base::failure[abi:cxx11]::failure(char const*, std::error_code const&)

Bootstrapped and ran libiberty and libstdc++-v3 tests on
x86_64-unknown-linux-gnu.

2015-08-15  Ian Lance Taylor  <iant@google.com>

* cp-demangle.c (d_abi_tags): Preserve di->last_name across any
ABI tags.

Fix several crashes of C++ demangler on fuzzed input.

libiberty/
* cp-demangle.c (d_dump): Fix syntax error.
(d_identifier): Adjust type of len to match d_source_name.
(d_expression_1): Fix out-of-bounds access.  Check code variable for
NULL before dereferencing it.
(d_find_pack): Do not recurse for FIXED_TYPE, DEFAULT_ARG and NUMBER.
(d_print_comp_inner): Add NULL pointer check.
* cp-demangle.h (d_peek_next_char): Define as inline function when
CHECK_DEMANGLER is defined.
(d_advance): Likewise.
* testsuite/demangle-expected: Add new testcases.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225727 138bc75d-0d04-0410-961f-82ee72b054a4

Automatic date update in version.in

Automatic date update in version.in

btrace: diagnose "record btrace pt" without libipt

If GDB has been configured without libipt support, i.e. HAVE_LIBIPT is
undefined, and is running on a system that supports Intel(R) Processor Trace,
GDB will run into an internal error when trying to decode the trace.

    (gdb) record btrace
    (gdb) s
    usage (name=0x7fffffffe954 "fib-64")
        at src/fib.c:12
    12          fprintf(stderr, "usage: %s <num>\n", name);
    (gdb) info record
    Active record target: record-btrace
    Recording format: Intel(R) Processor Trace.
    Buffer size: 16kB.
    gdb/btrace.c:971: internal-error: Unexpected branch trace format.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

This requires a system with Linux kernel 4.1 or later running on a 5th
Generation Intel Core processor or later.

The issue is documented as PR 19297.

When trying to enable branch tracing, in addition to checking the target
support for the requested branch tracing format, also check whether GDB
supports. it.

gdb/
* btrace.c (btrace_enable): Check whether HAVE_LIBIPT is defined.

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

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

gdb/doc: revert previous vforkdone change

The previous manual change was wrong.  The vfork parent thread ID
should be reported with the usual "thread" magic register:

   Sending packet: $vCont;c:p7260.7260#1e...Packet received: OK
 -   Notification received: Stop:T05vforkdone:;
 +   Notification received: Stop:T05vforkdone:;thread:p7260.7260
                                               ^^^^^^^^^^^^^^^^^

This is already how the parent is reported in the vfork/fork events,
and is actually what the fix made gdbserver do.  Following the
documentation change, the event would have been reported like this
instead:

    Notification received: Stop:T05vforkdone:p7260.7260

gdb/doc/ChangeLog:
2015-09-15  Pedro Alves  <palves@redhat.com>

PR remote/18965
* gdb.texinfo (Stop Reply Packets): Revert previous change to
the vforkdone description.

PR remote/18965: vforkdone stop reply should indicate parent PID

The vforkdone stop reply misses indicating the thread ID of the vfork
parent which the event relates to:

 @cindex vfork events, remote reply
 @item vfork
 The packet indicates that @code{vfork} was called, and @var{r}
 is the thread ID of the new child process. Refer to
 @ref{thread-id syntax} for the format of the @var{thread-id}
 field.  This packet is only applicable to targets that support
 vfork events.

 @cindex vforkdone events, remote reply
 @item vforkdone
 The packet indicates that a child process created by a vfork
 has either called @code{exec} or terminated, so that the
 address spaces of the parent and child process are no longer
 shared. The @var{r} part is ignored.  This packet is only
 applicable to targets that support vforkdone events.

Unfortunately, this is not just a documentation issue.  GDBserver
is really not specifying the thread ID.  I noticed because
in non-stop mode, gdb complains:

 [Thread 6089.6089] #1 stopped.
 #0  0x0000003615a011f0 in ?? ()
 0x0000003615a011f0 in ?? ()
 (gdb) set debug remote 1
 (gdb) c
 Continuing.
 Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK
 Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
   Notification received: Stop:T05vfork:p17ce.17ce;06:40d7ffffff7f0000;07:30d7ffffff7f0000;10:e4c9eb1536000000;thread:p17c9.17c9;core:2;
 Sending packet: $vStopped#55...Packet received: OK
 Sending packet: $D;17ce#af...Packet received: OK
 Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
   Notification received: Stop:T05vforkdone:;
 No process or thread specified in stop reply: T05vforkdone:;
 (gdb)

This is not non-stop-mode-specific, however.  Consider e.g., that in
all-stop, you may be debugging more than one process at the same time.
You continue, and both processes vfork.  So when you next get a
T05vforkdone, there's no way to tell which of the parent processes is
done with the vfork.

Tests will be added later.

Tested on x86_64 Fedora 20.

gdb/gdbserver/ChangeLog:
2015-09-15  Pedro Alves  <palves@redhat.com>

PR remote/18965
* remote-utils.c (prepare_resume_reply): Merge
TARGET_WAITKIND_VFORK_DONE switch case with the
TARGET_WAITKIND_FORKED case.

gdb/doc/ChangeLog:
2015-09-15  Pedro Alves  <palves@redhat.com>

PR remote/18965
* gdb.texinfo (Stop Reply Packets): Explain that vforkdone's 'r'
part indicates the thread ID of the parent process.

Automatic date update in version.in

Fix build issue with nat/linux-namespaces.c

This commit fixes a build issue on systems with a prototype for setns
in their header files but no working setns is detected by configure.

gdb/ChangeLog:

PR gdb/18957
* nat/linux-namespaces.c (setns): Rename from this ...
(do_setns): ... to this.  Support calling setns if it exists.
(mnsh_handle_setns): Call do_setns.

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