public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp
@ 2015-08-18 14:03 sergiodj+buildbot
  2015-08-18 14:03 ` Failures on RHEL-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
                   ` (22 more replies)
  0 siblings, 23 replies; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-18 14:03 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 37419df723ec96b600030970e0fe97aaa82fa2e1 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.10-branch
Commit: 37419df723ec96b600030970e0fe97aaa82fa2e1

PR record/18691: Fix fails in solib-precsave.exp

We see the following regressions in testing on x86_64-linux,

 reverse-step^M
 Cannot access memory at address 0x2aaaaaed26c0^M
 (gdb) FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one

when GDB reverse step into a function, GDB wants to skip prologue so
it requests TARGET_OBJECT_CODE_MEMORY to read some code memory in
memory_xfer_partial_1.  However in dcache_read_memory_partial, the object
becomes TARGET_OBJECT_MEMORY

      return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL,
                                   myaddr, NULL, memaddr, len,
                                   xfered_len);

in reverse debugging, ops->to_xfer_partial is record_full_core_xfer_partial
and it will return TARGET_XFER_E_IO because it can't find any records.
The test fails.

At this moment, the delegate relationship is like

  dcache -> record-core -> core -> exec

and we want to GDB read memory across targets, which means if the
requested memory isn't found in record-core, GDB can read memory from
core, and exec even further if needed.  I find raw_memory_xfer_partial
is exactly what I want.

gdb:

2015-08-18  Yao Qi  <yao.qi@linaro.org>

	PR record/18691
	* dcache.c (dcache_read_memory_partial): Call
	raw_memory_xfer_partial.
	* target.c (raw_memory_xfer_partial): Make it non-static.
	* target.h (raw_memory_xfer_partial): Declare.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion
@ 2016-02-11 15:36 sergiodj+buildbot
  2016-02-12  3:20 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2016-02-11 15:36 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 718b36fead887693158396b948d7f409b987c053 ***

Author: Don Breazeal <donb@codesourcery.com>
Branch: gdb-7.10-branch
Commit: 718b36fead887693158396b948d7f409b987c053

Fix '-data-read-memory-bytes' typo/assertion

Backported to the 7.10 branch per this thread:
https://www.sourceware.org/ml/gdb-patches/2016-02/msg00134.html

This patch fixes a typo in target.c:read_memory_robust, where
it calls read_whatever_is_readable with the function arguments
in the wrong order.  Depending on the address being read, it
can cause an xmalloc with a huge size, resulting in an assertion
failure, or just read something other than what was requested.

The problem only arises when GDB is handling an MI
"-data-read-memory-bytes" request and the initial target_read returns
an error status.  Note that read_memory_robust is only called from
the MI code.

gdb/ChangeLog:

	* gdb/target.c (read_memory_robust): Call
	read_whatever_is_readable with arguments in the correct order.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Set GDB version number to 7.10.1.
@ 2015-12-05 15:33 sergiodj+buildbot
  2015-12-05 16:27 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-12-05 15:33 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT c2bb526a220f4d79f698fca33ba57fe1f81aba9f ***

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

Set GDB version number to 7.10.1.

gdb/ChangeLog:

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


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix regression by Do not skip prologue for asm (.S) files
@ 2015-12-02  9:47 sergiodj+buildbot
  2015-12-02 13:57 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-12-02  9:47 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 87a8c81ef09b8f86844924c71b2d886b58991c60 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.10-branch
Commit: 87a8c81ef09b8f86844924c71b2d886b58991c60

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.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters
@ 2015-11-28 20:37 sergiodj+buildbot
  2015-11-29  8:41 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 20:37 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 49037e4a1249890812a8d4995c7592774e99c399 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 49037e4a1249890812a8d4995c7592774e99c399

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


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Implement N4514, C++ Extensions for Transactional Memory.
@ 2015-11-28 20:05 sergiodj+buildbot
  2015-11-29  7:41 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 20:05 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT d65faac094af199ce4f9c8c0bbd062f668979431 ***

Author: Jason Merrill <jason@redhat.com>
Branch: gdb-7.10-branch
Commit: d65faac094af199ce4f9c8c0bbd062f668979431

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


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Demangler: Fix constructor names with ABI tags
@ 2015-11-28 19:19 sergiodj+buildbot
  2015-11-29  6:41 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 19:19 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 99eda040d8214d2d691ba804d6354c99b6df5269 ***

Author: Ian Lance Taylor <iant@google.com>
Branch: gdb-7.10-branch
Commit: 99eda040d8214d2d691ba804d6354c99b6df5269

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.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] btrace: diagnose "record btrace pt" without libipt
@ 2015-11-26 12:29 sergiodj+buildbot
  2015-11-26 15:49 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-11-26 12:29 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT bab694b7f968cc5703a69df694b5968384d6c0b4 ***

Author: Markus Metzger <markus.t.metzger@intel.com>
Branch: gdb-7.10-branch
Commit: bab694b7f968cc5703a69df694b5968384d6c0b4

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.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] remote: allow aborting long operations (e.g., file transfers)
@ 2015-08-25 18:44 sergiodj+buildbot
  2015-08-27 12:33 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-25 18:44 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 026ca0231ae6dcc107ec496ed677bd1b00474a2f ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 026ca0231ae6dcc107ec496ed677bd1b00474a2f

remote: allow aborting long operations (e.g., file transfers)

Currently, when remote debugging, if you type Ctrl-C just while the
target stopped for an internal event, and GDB is busy doing something
that takes a while (e.g., fetching chunks of a shared library off of
the target, with vFile, to process ELF headers and debug info), the
Ctrl-C is lost.

The patch hooks up the QUIT macro to a new target method that lets the
target react to the double-Ctrl-C before the event loop is reached,
which allows reacting to a double-Ctrl-C even when GDB is busy doing
some long operation and not waiting for a stop reply.  That end result
is:

 (gdb) c
 Continuing.
 ^C
 ^C
 Interrupted while waiting for the program.
 Give up waiting? (y or n) y
 Quit
 (gdb) info threads
   Id   Target Id         Frame
 * 1    Thread 11673      0x00007ffff7deb240 in _dl_debug_state () from target:/lib64/ld-linux-x86-64.so.2
 (gdb)

If, however, GDB is waiting for a stop reply (because the target has
been resumed, with e.g., vCont;c), but the target isn't responding, we
now get:

 (gdb) c
 Continuing.
 ^C
 ^C
 The target is not responding to interrupt requests.
 Stop debugging it? (y or n) y
 Disconnected from target.
 (gdb) info threads
 No threads.

This offers to disconnect, because when we're waiting for a stop
reply, there's nothing else we can send the target other than an
interrupt request.  And if that doesn't work, there's nothing else we
can do.

The Ctrl-C is presently lost because until we get to a user-visible
stop, the SIGINT handler that is installed is the one that forwards
the interrupt to the remote side, with the \003 "packet" [1].  But,
gdbserver ignores an interrupt request if the program is stopped.
Still, even if it didn't, the server can only report back a
stop-because-of-SIGINT when the program is next resumed.  And it may
take a while to actually re-resume the target.

[1] - In the old sync days, the remote target would react to a
double-Ctrl-C by asking users whether they wanted to give up waiting
and disconnect.  The code is still there, but it it isn't reacheable
on most hosts, which support serial connections in async mode
(probably only DJGPP doesn't).  Even then, in sync mode, remote.c's
SIGINT handler is only installed while the target is resumed, and is
removed as soon as the target sends back a stop reply.  That means
that a Ctrl-C just while GDB is processing an internal event can end
up with an odd "Quit" at the prompt instead of "Program stopped by
SIGINT".  In contrast, in async mode, remote.c's SIGINT handler is set
up as long as target_terminal_inferior or
target_terminal_ours_for_output are in effect (IOW, until we get a
user-visible stop and call target_terminal_ours), so the user
shouldn't get back a spurious Quit.  However, it's still desirable to
be able to interrupt a long-running GDB operation, if GDB takes a
while to re-resume the target or get back to the event loop.

Tested on x86_64 Fedora 20.

gdb/ChangeLog:
2015-08-24  Pedro Alves  <palves@redhat.com>

	PR gdb/18804
	* defs.h (maybe_quit): Declare.
	(QUIT): Now calls maybe_quit.
	* event-loop.c (clear_async_signal_handler)
	(async_signal_handler_is_marked): New functions.
	* event-loop.h (async_signal_handler_is_marked)
	(clear_async_signal_handler): New declarations.
	* remote.c (remote_check_pending_interrupt): New function.
	(interrupt_query): Use make_cleanup_restore_target_terminal.  No
	longer check whether the target is async.  If waiting for a stop
	reply, and a Ctrl-C as been sent to the target, offer to
	disconnect, and throw TARGET_CLOSE_ERROR instead of a quit.
	Otherwise do not disconnect and throw a quit.
	(_initialize_remote): Install remote_check_pending_interrupt as
	to_check_pending_interrupt.
	* target.c (target_check_pending_interrupt): New function.
	* target.h (struct target_ops) <to_check_pending_interrupt>: New
	field.
	(target_check_pending_interrupt): New declaration.
	* utils.c (maybe_quit): New function.
	* target-delegates.c: Regenerate.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] signal_command: Leftover cleanup chain regression
@ 2015-08-25 17:11 sergiodj+buildbot
  2015-08-27 17:20 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-25 17:11 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3ba0344e56ef739808615be5ca319f82c2a83855 ***

Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.10-branch
Commit: 3ba0344e56ef739808615be5ca319f82c2a83855

signal_command: Leftover cleanup chain regression

gdb/ChangeLog
2015-08-04  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* infcmd.c (signal_command): Call do_cleanups for args_chain.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Warn when accessing binaries from remote targets
@ 2015-08-21 17:54 sergiodj+buildbot
  2015-08-22  5:39 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 17:54 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 290f582b49a81b7fa01fc430bad1a7f9af21c922 ***

Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: 290f582b49a81b7fa01fc430bad1a7f9af21c922

Warn when accessing binaries from remote targets

GDB provides no indicator of progress during file operations, and can
appear to have locked up during slow remote transfers.  This commit
updates GDB to print a warning each time a file is accessed over RSP.
An additional message detailing how to avoid remote transfers is
printed for the first transfer only.

gdb/ChangeLog:

	* target.h (struct target_ops) <to_fileio_open>: New argument
	warn_if_slow.  Update comment.  All implementations updated.
	(target_fileio_open_warn_if_slow): New declaration.
	* target.c (target_fileio_open): Renamed as...
	(target_fileio_open_1): ...this.  New argument warn_if_slow.
	Pass warn_if_slow to implementation.  Update debug printing.
	(target_fileio_open): New function.
	(target_fileio_open_warn_if_slow): Likewise.
	* gdb_bfd.c (gdb_bfd_iovec_fileio_open): Use new function
	target_fileio_open_warn_if_slow.

gdb/testsuite/ChangeLog:

	* gdb.trace/pending.exp: Cope with remote transfer warnings.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix stale cleanup left by linux_mntns_access_fs
@ 2015-08-21 16:39 sergiodj+buildbot
  2015-08-21 23:04 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 16:39 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 23778dcc5bb92541850e239d10bf19eb311a57b6 ***

Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: 23778dcc5bb92541850e239d10bf19eb311a57b6

Fix stale cleanup left by linux_mntns_access_fs

This commit fixes a stale cleanup left by linux_mntns_access_fs.

gdb/ChangeLog:

	* nat/linux-namespaces.c (linux_mntns_access_fs):
	Do not overwrite old_chain.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] procfs.c: Include "filestuff.h"
@ 2015-08-21  8:52 sergiodj+buildbot
  2015-08-21 11:53 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-21  8:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 44d0cad3c4c67d21a50974bc8ef6d350ba32172d ***

Author: Marcin Cieslak <saper@saper.info>
Branch: gdb-7.10-branch
Commit: 44d0cad3c4c67d21a50974bc8ef6d350ba32172d

procfs.c: Include "filestuff.h"

Fixes implicit function declaration
error in gdb/procfs.c:4927 about undeclared
make_cleanup_close().

gdb/ChangeLog:

	PR build/18843
	* procfs.c: Include "filestuff.h".


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp: Improve testcase documentation.
@ 2015-08-13 20:06 sergiodj+buildbot
  2015-08-14 21:55 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-13 20:06 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3d1e2b37751fed4e014d52ce858bcb6b147c475a ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: 3d1e2b37751fed4e014d52ce858bcb6b147c475a

gdb.base/dso2dso.exp: Improve testcase documentation.

gdb/testsuite/ChangeLog:

        * gdb.base/dso2dso.exp: Improve the testcase's documentation.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp sometimes broken
@ 2015-08-13 19:48 sergiodj+buildbot
  2015-08-14 20:31 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-13 19:48 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 01653c39b80c69ae02396f16cc3306ab8eb8ace0 ***

Author: Keith Seitz <keiths@redhat.com>
Branch: gdb-7.10-branch
Commit: 01653c39b80c69ae02396f16cc3306ab8eb8ace0

gdb.base/dso2dso.exp sometimes broken

Keith reported that gdb.base/dso2dso.exp is broken, with the following
error:

| $ make check RUNTESTFLAGS=dso2dso.exp
| [snip]
| Running ../../../src/gdb/testsuite/gdb.base/dso2dso.exp ...
| ERROR: tcl error sourcing ../../../src/gdb/testsuite/gdb.base/dso2dso.exp.
| ERROR: couldn't open
| "../../../src/gdb/testsuite/gdb.base/../../../src/gdb/testsuite/gdb.base/dso2dso-dso1.c":
| no such file or directory
|     while executing
| "error "$message""
|     (procedure "gdb_get_line_number" line 14)
|     invoked from within
| "gdb_get_line_number "STOP HERE" $srcfile_libdso1"
|     (file "../../../src/gdb/testsuite/gdb.base/dso2dso.exp" line 60)
|     invoked from within
| "source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
|     ("uplevel" body line 1)
|     invoked from within
| "uplevel #0 source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
|     invoked from within
| "catch "uplevel #0 source $test_file_name""

This happens because gdb_get_line_number will prepend $srcdir/$subdir
if the given filename does not start with "/", and this happens when
GDB was configured using a relative path to the configure script.
When using an absolute path like I do, we avoid the pre-pending that
Keith is seeing.

gdb/testsuite/ChangeLog:

        Keith Seitz  <keiths@redhat.com>:
        * gdb.base/dso2dso.exp: Pass basename of source file in call
        to gdb_get_line_number.

Tested on x86_64-linux with both scenarios.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] [regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint
@ 2015-08-12  9:20 sergiodj+buildbot
  2015-08-13  6:51 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-12  9:20 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 835001623351330d49678d215d1338c0ce35c1f9 ***

Author: Luis Machado <lgustavo@codesourcery.com>
Branch: gdb-7.10-branch
Commit: 835001623351330d49678d215d1338c0ce35c1f9

[regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint

While running bare-metal tests with GDB i noticed some failures in
gdb.base/break.exp, related to the use of the catch commands.

It turns out GDB tries to access memory address 0x0 whenever one tries
to insert a catchpoint, which should obviously not happen.

This was introduced with the changes for permanent breakpoints. In special,
bp_loc_is_permanent tries to check if there is a breakpoint inserted at
the same address as the current breakpoint's location's address. In the
case of catchpoints, this is 0x0.

(top-gdb) catch fork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 4 (fork)

(top-gdb) catch vfork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 5 (vfork)

It is not obvious to detect because this fails silently for Linux. For our
bare-metal testing, though, this fails with a clear error message from the
target about not being able to read such address.

The attached patch addresses this by bailing out of bp_loc_is_permanent (...)
if the location address is not meaningful. I also took the opportunity to
update the comment for breakpoint_address_is_meaningful, which mentioned
breakpoint addresses as opposed to their locations' addresses.

gdb/ChangeLog:

2015-08-11  Luis Machado  <lgustavo@codesourcery.com>

	* breakpoint.c (bp_loc_is_permanent): Return 0 when breakpoint
	location address is not meaningful.
	(breakpoint_address_is_meaningful): Update comment.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdbserver: Fix non-stop / fork / step-over issues
@ 2015-08-06 12:22 sergiodj+buildbot
  2015-08-06 22:35 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 12:22 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 3a3f16c0cf0fa5a555a688e119bb8b363a2e7d59 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 3a3f16c0cf0fa5a555a688e119bb8b363a2e7d59

gdbserver: Fix non-stop / fork / step-over issues
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html

This adds a test that has a multithreaded program have several threads
continuously fork, while another thread continuously steps over a
breakpoint.

This exposes several intertwined issues, which this patch addresses:

 - When we're stopping and suspending threads, some thread may fork,
   and we missed setting its suspend count to 1, like we do when a new
   clone/thread is detected.  When we next unsuspend threads, the fork
   child's suspend count goes below 0, which is bogus and fails an
   assertion.

 - If a step-over is cancelled because a signal arrives, but then gdb
   is not interested in the signal, we pass the signal straight back
   to the inferior.  However, we miss that we need to re-increment the
   suspend counts of all other threads that had been paused for the
   step-over.  As a result, other threads indefinitely end up stuck
   stopped.

 - If a detach request comes in just while gdbserver is handling a
   step-over (in the test at hand, this is GDB detaching the fork
   child), gdbserver internal errors in stabilize_thread's helpers,
   which assert that all thread's suspend counts are 0 (otherwise we
   wouldn't be able to move threads out of the jump pads).  The
   suspend counts aren't 0 while a step-over is in progress, because
   all threads but the one stepping past the breakpoint must remain
   paused until the step-over finishes and the breakpoint can be
   reinserted.

 - Occasionally, we see "BAD - reinserting but not stepping." being
   output (from within linux_resume_one_lwp_throw).  That was because
   GDB pokes memory while gdbserver is busy with a step-over, and that
   suspends threads, and then re-resumes them with proceed_one_lwp,
   which missed another reason to tell linux_resume_one_lwp that the
   thread should be set back to stepping.

 - In a couple places, we were resuming threads that are meant to be
   suspended.  E.g., when a vCont;c/s request for thread B comes in
   just while gdbserver is stepping thread A past a breakpoint.  The
   resume for thread B must be deferred until the step-over finishes.

 - The test runs with both "set detach-on-fork" on and off.  When off,
   it exercises the case of GDB detaching the fork child explicitly.
   When on, it exercises the case of gdb resuming the child
   explicitly.  In the "off" case, gdb seems to exponentially become
   slower as new inferiors are created.  This is _very_ noticeable as
   with only 100 inferiors gdb is crawling already, which makes the
   test take quite a bit to run.  For that reason, I've disabled the
   "off" variant for now.

gdb/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

	* target/waitstatus.h (enum target_stop_reason)
	<TARGET_STOPPED_BY_SINGLE_STEP>: New value.

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

	* linux-low.c (handle_extended_wait): Set the fork child's suspend
	count if stopping and suspending threads.
	(check_stopped_by_breakpoint): If stopped by trace, set the LWP's
	stop reason to TARGET_STOPPED_BY_SINGLE_STEP.
	(linux_detach): Complete an ongoing step-over.
	(lwp_suspended_inc, lwp_suspended_decr): New functions.  Use
	throughout.
	(resume_stopped_resumed_lwps): Don't resume a suspended thread.
	(linux_wait_1): If passing a signal to the inferior after
	finishing a step-over, unsuspend and re-resume all lwps.  If we
	see a single-step event but the thread should be continuing, don't
	pass the trap to gdb.
	(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use
	internal_error instead of gdb_assert.
	(enqueue_pending_signal): New function.
	(check_ptrace_stopped_lwp_gone): Add debug output.
	(start_step_over): Use internal_error instead of gdb_assert.
	(complete_ongoing_step_over): New function.
	(linux_resume_one_thread): Don't resume a suspended thread.
	(proceed_one_lwp): If the LWP is stepping over a breakpoint, reset
	it stepping.

gdb/testsuite/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

	* gdb.threads/forking-threads-plus-breakpoint.exp: New file.
	* gdb.threads/forking-threads-plus-breakpoint.c: New file.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Linux gdbserver confused when event randomization picks process exit event
@ 2015-08-06 11:58 sergiodj+buildbot
  2015-08-06 20:28 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 11:58 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 91da80b56eb52209fb8b366aca9519eb6e488397 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 91da80b56eb52209fb8b366aca9519eb6e488397

Linux gdbserver confused when event randomization picks process exit event
The tail end of linux_wait_1 isn't expecting that the select_event_lwp
machinery can pick a whole-process exit event to report to GDB.  When
that happens, both gdb and gdbserver end up quite confused:

 ...
 (gdb)
 [Thread 24971.24971] #1 stopped.
 0x0000003615a011f0 in ?? ()
 c&
 Continuing.
 (gdb) [New Thread 24971.24981]
 [New Thread 24983.24983]
 [New Thread 24971.24982]

 [Thread 24983.24983] #3 stopped.
 0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130
 130       pid = ARCH_FORK ();
 [New Thread 24984.24984]
 Error in re-setting breakpoint -16: PC register is not available
 Error in re-setting breakpoint -17: PC register is not available
 Error in re-setting breakpoint -18: PC register is not available
 Error in re-setting breakpoint -19: PC register is not available
 Error in re-setting breakpoint -24: PC register is not available
 Error in re-setting breakpoint -25: PC register is not available
 Error in re-setting breakpoint -26: PC register is not available
 Error in re-setting breakpoint -27: PC register is not available
 Error in re-setting breakpoint -28: PC register is not available
 Error in re-setting breakpoint -29: PC register is not available
 Error in re-setting breakpoint -30: PC register is not available
 PC register is not available
 (gdb)

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

	* linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE.
	(linux_thread_alive): Use lwp_is_marked_dead.
	(extended_event_reported): Delete.
	(linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE
	instead of extended_event_reported.
	(mark_lwp_dead): Don't set the 'dead' flag.  Store the waitstatus
	as well.
	(lwp_is_marked_dead): New function.
	(lwp_running): Use lwp_is_marked_dead.
	* linux-low.h: Delete 'dead' field, and update 'waitstatus's
	comment.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] stepping is disturbed by setjmp/longjmp | try/catch in other threads
@ 2015-08-05 19:50 sergiodj+buildbot
  2015-08-06  2:22 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-08-05 19:50 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT ad90a3f54869130ed7bada84e5bf6e71bd3a0c35 ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: ad90a3f54869130ed7bada84e5bf6e71bd3a0c35

stepping is disturbed by setjmp/longjmp | try/catch in other threads
At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel
observed that trying to next/step a program on GNU/Linux sometimes
results in the following failed assertion:

	% gdb -q .obj/gprof/main
    (gdb) start
    (gdb) n
    (gdb) step
    [...]/infrun.c:2391: internal-error:
    resume: Assertion `sig != GDB_SIGNAL_0' failed.

What happened is that, during the "next" operation, GDB hit a
longjmp/exception/step-resume breakpoint but failed to see that this
breakpoint was set for a different thread than the one being stepped.

Joel's detailed analysis follows:

More precisely, at the end of the "start" command, we are stopped at
the start of function Main in main.adb; there are 4 threads in total,
and we are in the main thread (which is thread 1):

    (gdb) info thread
      Id   Target Id         Frame
      4    Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall ()
      3    Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall ()
      2    Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall ()
    * 1    Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57

All the logs below reference Thread ID/LWP, but it'll be easier to
talk about the threads by GDB thread number.  For instance, thread 1
is LWP 28370 while thread 3 is LWP 28378.  So, the explanations below
translate the LWPs into thread numbers.

Back to what happens while we are trying to "next' our program:
    (gdb) n
    infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379))
    infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378))
    infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377))
    infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370))
    infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x8054523

We've resumed thread 1 (LWP 28370), and received in return a signal
that the same thread stopped slightly further.  It's still in the
range of instructions for the line of source we started the "next"
from, as evidenced by the following trace...

    infrun: stepping inside range [0x805451e-0x8054531]

... and thus, we decide to continue stepping the same thread:

    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
    infrun: prepare_to_wait

That's when we get an event from a different thread (thread 3)...

    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x80782d0
    infrun: context switch
    infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)

... which we find to be at the address where we set a breakpoint on
"the unwinder debug hook" (namely "_Unwind_DebugHook").  But GDB fails
to notice that the breakpoint was inserted for thread 1 only, and so
decides to handle it as...

    infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME

... and inserts a breakpoint at the corresponding resume address, as
evidenced by this the next log:

    infrun: exception resume at 80542a2

That breakpoint seems innocent right now, but will play a role fairly
quickly.  But for now, GDB has inserted the exception-resume
breakpoint, and needs to single-step thread 3 past the breakpoint it
just hit.  Thus, it temporarily disables the exception breakpoint, and
requests a step of that thread:

    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0
    infrun: prepare_to_wait

We then get a notification, still from thread 3, that it's now past
that breakpoint...

    infrun: prepare_to_wait
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x8078424

... so we can resume what we were doing before, which is single-stepping
thread 1 until we get to a new line of code:

    infrun: switching back to stepped thread
    infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370)
    infrun: expected thread still hasn't advanced
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523

The "resume" log above shows that we're resuming thread 1 from where
we left off (0x8054523).  We get one more stop at 0x8054529, which is
still inside our stepping range so we go again.  That's when we get
the following event, from thread 3:

    infrun: prepare_to_wait
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x80542a2

Now the stop_pc address is interesting, because it's the address of
"exception resume" breakpoint...

    infrun: context switch
    infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)
    infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME

... and since that location is at a different line of code, this is
where it decides the "next" operation should stop:

    infrun: stop_waiting
    [Switching to Thread 0xb7c5aba0 (LWP 28378)]
    0x080542a2 in inte_tache_rt.ttache_rt (
        <_task>=0x80968ec <inte_tache_rt_inst.tache2>)
        at /[...]/inte_tache_rt.adb:54
    54            end loop;

However, what GDB should have noticed earlier that the exception
breakpoint we hit was for a different thread, thus should have
single-stepped that thread out of the breakpoint _without_ inserting
the exception-return breakpoint, and then resumed the single-stepping
of the initial thread (thread 1) until that thread stepped out of its
stepping range.

This is what this patch does, and after applying it, GDB now correctly
stops on the next line of code.

The patch adds a C++ test that exercises this, both for setjmp/longjmp
and exception breakpoints.  With an unpatched GDB it shows:

 (gdb) next
 [Switching to Thread 22445.22455]
 thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59
 59            catch (...)
 (gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1
 next
 /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa
 iled.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error)
 Resyncing due to internal error.
 n

Tested on x86_64-linux, no regressions.

gdb/ChangeLog:
2015-08-05  Pedro Alves  <palves@redhat.com>
	    Joel Brobecker  <brobecker@adacore.com>

        * breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy>
	<bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the
	case where BS->STOP is not set.

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

	* gdb.threads/next-while-other-thread-longjmps.c: New file.
	* gdb.threads/next-while-other-thread-longjmps.exp: New file.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdbserver/Linux: internal error when killing a process that is already gone
@ 2015-07-14 10:30 sergiodj+buildbot
  2015-07-14 12:37 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-07-14 10:30 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 68988aba52a4c6355b03834f70bcebbd114be2cd ***

Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 68988aba52a4c6355b03834f70bcebbd114be2cd

gdbserver/Linux: internal error when killing a process that is already gone
If the process disappears (e.g., killed with "kill -9" from the shell)
while it was stopped under GDBserver's control, and the GDBserver
tries to kill it, GDBserver asserts:

 (gdb) shell kill -9 23084
 (gdb) kill
 ...
 Killing process(es): 23084
 /home/pedro/gdb/mygit/src/gdb/gdbserver/linux-low.c:972: A problem internal to GDBserver has been detected.
 kill_wait_lwp: Assertion `res > 0' failed.
 ...

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

	* linux-low.c (kill_wait_lwp): Don't assert if waitpid fails.
	Instead, ignore ECHILD, and throw an error for other errnos.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] record: set stop_pc in "record goto" command
@ 2015-07-14  7:24 sergiodj+buildbot
  2015-07-14  9:05 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-07-14  7:24 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 0900c4cec7f75a00cccb3537d754c20f99096686 ***

Author: Markus Metzger <markus.t.metzger@intel.com>
Branch: gdb-7.10-branch
Commit: 0900c4cec7f75a00cccb3537d754c20f99096686

record: set stop_pc in "record goto" command
When navigating in the recorded execution trace via "record goto", we do not
set stop_pc.  This may trigger an internal error in infrun.c when stepping
from that location.  Set it.

(gdb) rec full
(gdb) c
Continuing.

Breakpoint 1, foo (void) at foo.c:42
42             x = y
(gdb) rn
foo (void)
    at foo.c:41
41             y = x
(gdb) rec go end
Go forward to insn number 98724
    at foo.c:42
42             x = y
(gdb) n
infrun.c:2382: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

This happens because there's a breakpoint at PC when the "next"
is issued, so that breapoint should be immediately stepped over.
That should have been detected/done by proceed, here:

  if (addr == (CORE_ADDR) -1)
    {
      if (pc == stop_pc
	  && breakpoint_here_p (aspace, pc) == ordinary_breakpoint_here
	  && execution_direction != EXEC_REVERSE)
	/* There is a breakpoint at the address we will resume at,
	   step one instruction before inserting breakpoints so that
	   we do not stop right away (and report a second hit at this
	   breakpoint).

	   Note, we don't do this in reverse, because we won't
	   actually be executing the breakpoint insn anyway.
	   We'll be (un-)executing the previous instruction.  */
	tp->stepping_over_breakpoint = 1;

But since stop_pc was stale, the pc == stop_pc check failed, and left the
breakpont at PC inserted.

gdb/
	* record-btrace.c (record_btrace_goto_begin, record_btrace_goto_end)
	record_btrace_goto): Move call to print_stack_frame ...
	(record_btrace_set_replay): ... here.  Set stop_pc.
	* record-full.c (record_full_goto_entry): Set stop_pc.

testsuite/
	* gdb.btrace/record_goto-step.exp: New.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] btrace: fix build fail with 32-bit BFD
@ 2015-07-14  6:52 sergiodj+buildbot
  2015-07-14  8:03 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-07-14  6:52 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT 77116e10e2eb48425af3fe860b5dc8faa71de16a ***

Author: Markus Metzger <markus.t.metzger@intel.com>
Branch: gdb-7.10-branch
Commit: 77116e10e2eb48425af3fe860b5dc8faa71de16a

btrace: fix build fail with 32-bit BFD
When compiling GDB with 32-bit BFD, the build fails with:

In file included from btrace.h:33:0,
                 from btrace.c:23:
/usr/include/intel-pt.h:1643:51: note: expected 'int (*)(uint8_t *, size_t,
 const struct pt_asid *, uint64_t, void *)' but argument is of type 'int
 (*)(gdb_byte *, size_t, const struct pt_asid *, CORE_ADDR, void *)' extern
 pt_export int pt_image_set_callback(struct pt_image *image, ^

gdb/
	* btrace.c (btrace_pt_readmem_callback): Change type of PC argument.


^ permalink raw reply	[flat|nested] 46+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions
@ 2015-07-08 10:51 sergiodj+buildbot
  2015-07-08 13:06 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
  0 siblings, 1 reply; 46+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 10:51 UTC (permalink / raw)
  To: gdb-testers

*** TEST RESULTS FOR COMMIT cc1259417e727c47e58cea1bb4a148974689ad8e ***

Author: Robert O'Callahan <robert@ocallahan.org>
Branch: gdb-7.10-branch
Commit: cc1259417e727c47e58cea1bb4a148974689ad8e

PR18617 - Incorrect expression bytecode generated for narrowing conversions
The existing code preserves 'from' bits, which is incorrect.  E.g.

 (gdb) maint agent-eval (char)255L
 Scope: 0x4008d6
 Reg mask: 00
   0  const16 255
   3  ext 64
   5  end

'ext 64' should be 'ext 8'; this bytecode evaluates to 255 instead of
the correct result of -1.  The fix is simple.  I ran the entire test
suite on x86-64 and there were no new test failures.

gdb/ChangeLog:
2015-07-08  Robert O'Callahan  <robert@ocallahan.org>

	PR exp/18617
	* ax-gdb.c (gen_conversion): Extend to 'to' bits, not 'from'.

gdb/testsuite/ChangeLog:
2015-07-08  Robert O'Callahan  <robert@ocallahan.org>

	PR exp/18617
	* gdb.trace/ax.exp: Add test.


^ permalink raw reply	[flat|nested] 46+ messages in thread
end of thread, other threads:[~2016-02-12  3:20 UTC | newest]

Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-18 14:03 [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp sergiodj+buildbot
2015-08-18 14:03 ` Failures on RHEL-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-18 14:49 ` Failures on Fedora-i686, " sergiodj+buildbot
2015-08-18 15:01 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot
2015-08-18 15:04 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2015-08-18 15:07 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2015-08-18 15:07 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2015-08-18 15:11 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-18 15:18 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2015-08-18 15:21 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2015-08-18 15:27 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2015-08-18 15:50 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2015-08-18 18:27 ` Failures on Fedora-ppc64be-cc-with-index, " sergiodj+buildbot
2015-08-18 18:47 ` Failures on Fedora-ppc64be-m64, " sergiodj+buildbot
2015-08-18 19:03 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj+buildbot
2015-08-18 19:24 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-18 19:30 ` Failures on Debian-x86_64-m64, " sergiodj+buildbot
2015-08-18 19:48 ` Failures on Debian-i686, " sergiodj+buildbot
2015-08-18 20:01 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2015-08-18 20:06 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-08-18 20:16 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot
2015-08-18 20:42 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot
2015-08-18 20:52 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot
2015-08-18 21:02 ` Failures on Fedora-ppc64le-m64, " sergiodj+buildbot
  -- strict thread matches above, loose matches on Subject: below --
2016-02-11 15:36 [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion sergiodj+buildbot
2016-02-12  3:20 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-12-05 15:33 [binutils-gdb/gdb-7.10-branch] Set GDB version number to 7.10.1 sergiodj+buildbot
2015-12-05 16:27 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-12-02  9:47 [binutils-gdb/gdb-7.10-branch] Fix regression by Do not skip prologue for asm (.S) files sergiodj+buildbot
2015-12-02 13:57 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 20:37 [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters sergiodj+buildbot
2015-11-29  8:41 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 20:05 [binutils-gdb/gdb-7.10-branch] Implement N4514, C++ Extensions for Transactional Memory sergiodj+buildbot
2015-11-29  7:41 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 19:19 [binutils-gdb/gdb-7.10-branch] Demangler: Fix constructor names with ABI tags sergiodj+buildbot
2015-11-29  6:41 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-26 12:29 [binutils-gdb/gdb-7.10-branch] btrace: diagnose "record btrace pt" without libipt sergiodj+buildbot
2015-11-26 15:49 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-25 18:44 [binutils-gdb/gdb-7.10-branch] remote: allow aborting long operations (e.g., file transfers) sergiodj+buildbot
2015-08-27 12:33 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-25 17:11 [binutils-gdb/gdb-7.10-branch] signal_command: Leftover cleanup chain regression sergiodj+buildbot
2015-08-27 17:20 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 17:54 [binutils-gdb/gdb-7.10-branch] Warn when accessing binaries from remote targets sergiodj+buildbot
2015-08-22  5:39 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 16:39 [binutils-gdb/gdb-7.10-branch] Fix stale cleanup left by linux_mntns_access_fs sergiodj+buildbot
2015-08-21 23:04 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21  8:52 [binutils-gdb/gdb-7.10-branch] procfs.c: Include "filestuff.h" sergiodj+buildbot
2015-08-21 11:53 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-13 20:06 [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp: Improve testcase documentation sergiodj+buildbot
2015-08-14 21:55 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-13 19:48 [binutils-gdb/gdb-7.10-branch] gdb.base/dso2dso.exp sometimes broken sergiodj+buildbot
2015-08-14 20:31 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-12  9:20 [binutils-gdb/gdb-7.10-branch] [regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint sergiodj+buildbot
2015-08-13  6:51 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 12:22 [binutils-gdb/gdb-7.10-branch] gdbserver: Fix non-stop / fork / step-over issues sergiodj+buildbot
2015-08-06 22:35 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 11:58 [binutils-gdb/gdb-7.10-branch] Linux gdbserver confused when event randomization picks process exit event sergiodj+buildbot
2015-08-06 20:28 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-05 19:50 [binutils-gdb/gdb-7.10-branch] stepping is disturbed by setjmp/longjmp | try/catch in other threads sergiodj+buildbot
2015-08-06  2:22 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-14 10:30 [binutils-gdb/gdb-7.10-branch] gdbserver/Linux: internal error when killing a process that is already gone sergiodj+buildbot
2015-07-14 12:37 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-14  7:24 [binutils-gdb/gdb-7.10-branch] record: set stop_pc in "record goto" command sergiodj+buildbot
2015-07-14  9:05 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-14  6:52 [binutils-gdb/gdb-7.10-branch] btrace: fix build fail with 32-bit BFD sergiodj+buildbot
2015-07-14  8:03 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-08 10:51 [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions sergiodj+buildbot
2015-07-08 13:06 ` Failures on Debian-x86_64-native-gdbserver-m64, branch gdb-7.10-branch sergiodj+buildbot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).