When searching static symbols, gdb would search over all
expanded symtabs of all objfiles, and if that fails only then
would it search all partial/gdb_index tables of all objfiles.
This means that the user could get a random instance of the
symbol depending on what symtabs have been previously expanded.
Now the search is consistent, searching each objfile completely
before proceeding to the next one.
gdb/ChangeLog:
PR symtab/17564
* symtab.c (lookup_symbol_in_all_objfiles): Delete.
(lookup_static_symbol): Move definition to new location and rewrite.
(lookup_symbol_in_objfile): New function.
(lookup_symbol_global_iterator_cb): Call it.
gdb/testsuite/ChangeLog:
PR symtab/17564
* gdb.base/symtab-search-order.exp: New file.
* gdb.base/symtab-search-order.c: New file.
* gdb.base/symtab-search-order-1.c: New file.
* gdb.base/symtab-search-order-shlib-1.c: New file.
A recent change to eval.c triggered a GCC bug that causes a false positive
"may be used uninitialized" warning in evaluate_subexp_standard. This seems
to be triggered by a specific CFG constructed via setjmp and gotos.
While the GCC bug is in the process of being fixed, there are released
compiler versions (in particular GCC 4.9) in the field that show this
problem. In order to allow compiling GDB with one of those compilers,
this commit slightly reworks the CFG (in an equivalent way) of the
affected function, so that the GCC bug is no longer triggered.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Work around GCC bug 63748.
Running gdb.base/sigstep.exp with --target=i686-pc-linux-gnu on a
64-bit kernel naturally trips on PR gdb/17511 as well, given this is a
kernel bug.
I haven't really tested a real 32-bit kernel/machine, but given the
code in question in the kernel is shared between 32-bit and 64-bit,
I'm quite sure the bug triggers in those cases as well.
So, simply xfail i?86-*-linux* too.
gdb/testsuite/
2014-11-07 Pedro Alves <palves@redhat.com>
PR gdb/17511
* gdb.base/sigstep.exp (in_handler_map) <si+advance>: xfail
i?86-*-linux*.
The in_prologue check in the nexti code is obsolete; this commit
removes that, and then removes the in_prologue function as nothing
else uses it.
Looking at the code in GDB that makes use in_prologue, all we find is
this one caller:
if ((ecs->event_thread->control.step_over_calls == STEP_OVER_NONE)
|| ((ecs->event_thread->control.step_range_end == 1)
&& in_prologue (gdbarch, ecs->event_thread->prev_pc,
ecs->stop_func_start)))
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
("stepi"). Just stop. */
/* Also, maybe we just did a "nexti" inside a prolog, so we
thought it was a subroutine call but it was not. Stop as
well. FENN */
/* And this works the same backward as frontward. MVS */
end_stepping_range (ecs);
return;
}
This was added by:
commit 100a02e1de
...
From Fernando Nasser:
* infrun.c (handle_inferior_event): Handle "nexti" inside function
prologues.
The mailing list thread is here:
https://sourceware.org/ml/gdb-patches/2001-01/msg00047.html
Not much discussion there, and no test, but looking at the code around
what was patched in that revision, we see that the checks that detect
whether the program has just stepped into a subroutine didn't rely on
the unwinders at all back then.
From 'git show 100a02e1:gdb/infrun.c':
if (stop_pc == ecs->stop_func_start /* Quick test */
|| (in_prologue (stop_pc, ecs->stop_func_start) &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!IN_SOLIB_RETURN_TRAMPOLINE (stop_pc, ecs->stop_func_name))
|| IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)
|| ecs->stop_func_name == 0)
{
/* It's a subroutine call. */
if ((step_over_calls == STEP_OVER_NONE)
|| ((step_range_end == 1)
&& in_prologue (prev_pc, ecs->stop_func_start)))
{
/* I presume that step_over_calls is only 0 when we're
supposed to be stepping at the assembly language level
("stepi"). Just stop. */
/* Also, maybe we just did a "nexti" inside a prolog,
so we thought it was a subroutine call but it was not.
Stop as well. FENN */
stop_step = 1;
print_stop_reason (END_STEPPING_RANGE, 0);
stop_stepping (ecs);
return;
}
Stripping the IN_SOLIB_RETURN_TRAMPOLINE checks for simplicity, we had:
if (stop_pc == ecs->stop_func_start /* Quick test */
|| in_prologue (stop_pc, ecs->stop_func_start)
|| ecs->stop_func_name == 0)
{
/* It's a subroutine call. */
That is, detecting a subroutine call was based on prologue detection
back then. So the in_prologue check in the current tree only made
sense back then as it was undoing a bad decision the in_prologue check
that used to exist above did.
Today, the check for a subroutine call relies on frame ids instead,
which are stable throughout the function. So we can just remove the
in_prologue check for nexti, and the whole in_prologue function along
with it.
Tested on x86_64 Fedora 20, and also by nexti-ing manually a prologue.
gdb/
2014-11-07 Pedro Alves <palves@redhat.com>
* infrun.c (process_event_stop_test) <subroutine check>: Don't
check if we did a "nexti" inside a prologue.
* symtab.c (in_prologue): Delete function.
* symtab.h (in_prologue): Delete declaration.
"aux" doesn't contribute anything to the name, and it makes the
reader wonder what it's supposed to mean.
gdb/ChangeLog:
* symtab.c (lookup_local_symbol): Renamed from lookup_symbol_aux_local.
All callers updated.
(lookup_symbol_in_all_objfiles): Renamed from
lookup_symbol_aux_symtabs. All callers updated.
(lookup_symbol_via_quick_fns): Renamed from lookup_symbol_aux_quick.
All callers updated.
(lookup_symbol_in_objfile_symtabs): Renamed from
lookup_symbol_aux_objfile. All callers updated.
and lookup_static_symbol_aux to lookup_static_symbol.
gdb/ChangeLog:
* symtab.c (lookup_static_symbol): Renamed from
lookup_static_symbol_aux. All callers updated.
(lookup_symbol_in_static_block): Renamed from lookup_symbol_static.
All callers updated.
gdb/ChangeLog:
* block.h (ALL_BLOCK_SYMBOLS_WITH_NAME): New macro.
* block.c (block_lookup_symbol): Use it.
* cp-support.c (make_symbol_overload_list_block): Use it.
* symtab.c (iterate_over_symbols): Use it.
There is another function, lookup_symbol_aux_block, and
the names lookup_block_symbol and lookup_symbol_aux_block don't
convey any real difference between them.
The difference is that lookup_block_symbol lives in the lower level
block API, and lookup_symbol_aux_block lives in the higher level symtab API.
This patch makes this distinction clear.
gdb/ChangeLog:
* symtab.c (lookup_block_symbol): Moved to ...
* block.c (block_lookup_symbol): ... here and renamed.
All callers updated.
* block.h (block_lookup_symbol): Declare.
* symtab.h (lookup_block_symbol): Delete.
Non-primary symtabs share the block vector with their primary symtabs.
In these cases there's no need to use ALL_SYMTABS.
gdb/ChangeLog:
* ada-lang.c (ada_make_symbol_completion_list): Use
ALL_PRIMARY_SYMTABS instead of ALL_SYMTABS.
* symtab.c (lookup_objfile_from_block): Ditto.
obstack_next_free is supposed to return a void*, rather than a char*
as it does currently. Avoid warning on void* arithmetic when
obstack_next_free gets it proper return type.
* cp-valprint.c (cp_print_value_fields): Cast obstack_next_free
to char* before doing pointer arithmetic.
obstack_blank isn't the correct macro to call for shrinking obstacks
since it does size checking.
* charset.c (convert_between_encodings): Shrink obstack using
obstack_blank_fast.
* minsyms.c (install_minimal_symbols): Likewise.
Older versions of ncurses' newterm can't take NULL for their ofp and ifp
parameters. Newer versions can, and they fall back on stdout/stdin if
that is the case.
This patch explicitly passes stdout/stdin to the call to newterm to
avoid segfaulting with older ncurses.
gdb/Changelog:
2014-11-04 Simon Marchi <simon.marchi@ericsson.com>
* tui/tui.c (tui_enable): Pass stdout and stdin to newterm.
Used to be necessary for the thread-hop code, but that's gone now.
Nothing uses this anymore.
gdb/
2014-11-04 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoint_thread_match): Delete function.
* breakpoint.h (breakpoint_thread_match): Delete declaration.
When evaluating method calls under EVAL_SKIP, the "object" and the
arguments to the method should also be evaluated under EVAL_SKIP,
instead of skipping to evaluate them as was being done previously.
gdb/ChangeLog:
PR c++/17494
* eval.c (evaluate_subexp_standard): Evaluate the "object" and
the method args also under EVAL_SKIP when evaluating method
calls under EVAL_SKIP.
gdb/testsuite/ChangeLog:
PR c++/17494
* gdb.cp/pr17494.cc: New file.
* gdb.cp/pr17494.exp: New file.
During armv7b testing gdb.base/store.exp test was failling with
'GDB internal error' with the following message:
Temporary breakpoint 1, wack_double (u=
../../binutils-gdb/gdb/regcache.c:177: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
It turns out that compiler generated DWARF with non-existent
register numbers. The compiler issue is present in both little endian
(armv7) and big endian (armv7b) (it is separate issue). Here is
example for one of formal parameters of wack_double function:
<2><792>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<793> DW_AT_name : u
<795> DW_AT_decl_file : 1
<796> DW_AT_decl_line : 115
<797> DW_AT_type : <0x57c>
<79b> DW_AT_location : 6 byte block: 6d 93 4 6c 93 4 (DW_OP_reg29 (r29); DW_OP_piece: 4; DW_OP_reg28 (r28); DW_OP_piece: 4)
In both big and little endian cases gdbarch_dwarf2_reg_to_regnum
returns -1 which is stored into gdb_regnum. But it causes severe
problem only in big endian case because in read_pieced_value and
write_pieced_value functions BFD_ENDIAN_BIG related processing
happen regardless of gdb_regnum value, for example register_size
function is called and in case of gdb_regnum=-1, it cause
'GDB internal error' and crash.
Solution is to move BFD_ENDIAN_BIG related processing under
(gdb_regnum != -1) branch of processing.
gdb/ChangeLog:
2014-11-02 Victor Kamensky <victor.kamensky@linaro.org>
* dwarf2loc.c (read_pieced_value): Do big endian
processing only if gdb_regnum is not -1.
(write_pieced_value): Ditto.
tdep->arm_breakpoint, tdep->thumb_breakpoint, tdep->thumb2_breakpoint
should be set le_ variants in case of arm BE8 code. Those instruciton
sequences are writen to target with simple write_memory, without
regarding gdbarch_byte_order_for_code. But in BE8 case even data
memory is in big endian form, instructions are still in little endian
form.
Because of this issue there are many issues while running gdb test
case in armv7b mode. For example gdb.arch/arm-disp-step.exp test fails
because it gets SIGILL when displaced instrucion sequence reaches
break instruction, which is in wrong byte order.
Solution is to set tdep->xxx_breakpoint sequences in BE8 case (i.e
when gdbarch_byte_order_for_code is BFD_ENDIAN_BIG.
gdb/ChangeLog:
2014-11-02 Victor Kamensky <victor.kamensky@linaro.org>
* arm-linux-tdep.c (arm_linux_init_abi): Use
info.byte_order_for_code to choose endianity of breakpoint
instructions snippets.
extract_arm_insn function needs to read instructions in
gdbarch_byte_order_for_code byte order, because in case armv7b,
even data is big endian, instructions are still little endian.
Currently function uses gdbarch_byte_order which would be
big endian in armv7b case.
Because of this issue pretty much all gdb.reverse/ tests are
failing with 'Process record does not support instruction' message.
Fix is to change gdbarch_byte_order to gdbarch_byte_order_for_code,
when passed to extract_unsigned_integer that reads instruction.
gdb/ChangeLog:
2014-11-02 Victor Kamensky <victor.kamensky@linaro.org>
* arm-tdep.c (extract_arm_insn): Use
gdbarch_byte_order_for_code to read arm instruction.
The test in gdb.python/python.exp tests "extended-prompt" and expects
working directory is printed. However, working directory on remote
host doesn't have "gdb/testsuite", so the test fails on remote host
like:
set extended-prompt \w ^M
^M
/home/yao FAIL: gdb.python/python.exp: set extended prompt working directory (timeout)
This patch is to get the working directory first, and use it to match
the output of "set extended-prompt \\w ". It works for remote host
and non remote host.
gdb/testsuite:
2014-11-02 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Get working directory and match the
output of "set extended-prompt \\w " with it.
gdb/ChangeLog:
* NEWS: Mention ability add attributes to gdb.Objfile and
gdb.Progspace objects.
* python/py-objfile.c (objfile_object): New member dict.
(objfpy_dealloc): Py_XDECREF dict.
(objfpy_initialize): Initialize dict.
(objfile_getset): Add __dict__.
(objfile_object_type): Set tp_dictoffset member.
* python/py-progspace.c (progspace_object): New member dict.
(pspy_dealloc): Py_XDECREF dict.
(pspy_initialize): Initialize dict.
(pspace_getset): Add __dict__.
(pspace_object_type): Set tp_dictoffset member.
gdb/doc/ChangeLog:
* python.texi (Progspaces In Python): Document ability to add
random attributes to gdb.Progspace objects.
(Objfiles In Python): Document ability to add random attributes to
gdb.objfile objects.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Add tests for setting random attributes
in objfiles.
* gdb.python/py-progspace.exp: Add tests for setting random attributes
in progspaces.
Several GDB tests change directory before compiling the test program
in order to test source file names that include directories. This
doesn't work on a remote host because default_target_compile in
DejaGnu's target.exp copies each source file with
"[remote_download host $x]" which uses "[file tail $file] to strip
off the directory of each file. If the source directory is remote
mounted on the host, this also leaves copied files in the source
directory.
A similar skip is already used in gdb.test/fullname.exp:
# We rely on being able to copy things around.
if { [is_remote host] } {
untested "setting breakpoints by full path"
return -1
}
This patch causes three GDB tests that use "cd" to be skipped for a
remote host. For gdb.base/fullpath-expand.exp this eliminates two
failures and prevents the test from leaving files fullpath-expand.c
and fullpath-expand-func.c in gdb/testsuite. For
gdb.base/realname-expand.exp it eliminates two failures. For
gdb.linespec/macro-relative.exp it prevents file macro-relative.c
from being left in gdb/testsuite/gdb.linespec/base/two.
gdb/testsuite/
* gdb.base/fullpath-expand.exp: Skip for a remote host.
* gdb.base/realname-expand.exp: Likewise.
* gdb.linespec/macro-relative.exp: Likewise.
In gdb/command/prompt.py:before_prompt_hook, the '\' in the new prompt
is replaced with '\\', shown as below,
> def before_prompt_hook(self, current):
> if self.value is not '':
> newprompt = gdb.prompt.substitute_prompt(self.value)
> return newprompt.replace('\\', '\\\\')
> else:
> return None
I don't see any explanations on this in comments nor email. As doc
said, "set extended-prompt \w" substitute the current working
directory, but it prints something different from what pwd or
os.getcwdu() prints on mingw32 host.
(gdb) python print os.getcwdu()^M
\\build2-lucid-cs\yqi\yqi\arm-none-eabi
(gdb) pwd^M
Working directory \\build2-lucid-cs\yqi\yqi\arm-none-eabi
(gdb) set extended-prompt \w
\\\\build2-lucid-cs\\yqi\\yqi\\arm-none-eabi
This makes me think whether the substitution in before_prompt_hook is
necessary or not. This patch is to remove this substitution.
Run gdb.python on x86_64-linux and arm-none-eabi on mingw32 host. No
regressions.
gdb:
2014-10-30 Yao Qi <yao@codesourcery.com>
* python/lib/gdb/command/prompt.py (before_prompt_hook): Don't
replace '\\' with '\\\\'.
infrun.c:
5392 /* Did we find the stepping thread? */
5393 if (tp->control.step_range_end)
5394 {
5395 /* Yep. There should only one though. */
5396 gdb_assert (stepping_thread == NULL);
5397
5398 /* The event thread is handled at the top, before we
5399 enter this loop. */
5400 gdb_assert (tp != ecs->event_thread);
5401
5402 /* If some thread other than the event thread is
5403 stepping, then scheduler locking can't be in effect,
5404 otherwise we wouldn't have resumed the current event
5405 thread in the first place. */
5406 gdb_assert (!schedlock_applies (currently_stepping (tp)));
5407
5408 stepping_thread = tp;
5409 }
Like:
gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.
The way the assertion is written is assuming that with schedlock=step
we'll always leave threads other than the one with the stepping range
locked, while that's not true with the "next" command. With schedlock
"step", other threads still run unlocked when "next" detects a
function call and steps over it. Whether that makes sense or not,
still, it's documented that way in the manual. If another thread hits
an event that doesn't cause a stop while the nexting thread steps over
a function call, we'll get here and fail the assertion.
The fix is just to adjust the assertion. Even though we found the
stepping thread, we'll still step-over the breakpoint that just
triggered correctly.
Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
steps over a function call. This commits fixes that. This ensures
that "next" doesn't switch focus to another thread, and checks whether
other threads run locked or not, depending on scheduler locking mode
and command. There's a lot of duplication in that file that this ends
cleaning up. There's more that could be cleaned up, but that would
end up an unrelated change, best done separately.
This new coverage in schedlock.exp happens to trigger the internal
error in question, like so:
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)
That's because we have more than one thread running the same loop, and
while one thread is stepping over a function call, the other thread
hits the step-resume breakpoint of the first, which needs to be
stepped over, and we end up in switch_back_to_stepped_thread exactly
in the problem case.
I think a simpler and more directed test is also useful, to not rely
on internal breakpoint magics. So this commit also adds a test that
has a thread trip on a conditional breakpoint that doesn't cause a
user-visible stop while another thread is stepping over a call. That
currently fails like this:
FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)
Tested on x86_64 Fedora 20.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
instead of assuming a thread with a stepping range is always
stepping.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* gdb.threads/schedlock.c (some_function): New function.
(call_function): New global.
(MAYBE_CALL_SOME_FUNCTION): New macro.
(thread_function): Call it.
* gdb.threads/schedlock.exp (get_args): Add description parameter,
and use it instead of a global counter. Adjust all callers.
(get_current_thread): Use "find current thread" for test message
here rather than having all callers pass down the same string.
(goto_loop): New procedure, factored out from ...
(my_continue): ... this.
(step_ten_loops): Change parameter from test message to command to
use. Adjust.
(list_count): Delete global.
(check_result): New procedure, factored out from duplicate top
level code.
(continue tests): Wrap in with_test_prefix.
(test_step): New procedure, factored out from duplicate top level
code.
(top level): Test "step" in combination with all scheduler-locking
modes. Test "next" in combination with all scheduler-locking
modes, and in combination with stepping over a function call or
not.
* gdb.threads/next-bp-other-thread.c: New file.
* gdb.threads/next-bp-other-thread.exp: New file.
This PR shows that GDB can easily trigger an assertion here, in
infrun.c:
5392 /* Did we find the stepping thread? */
5393 if (tp->control.step_range_end)
5394 {
5395 /* Yep. There should only one though. */
5396 gdb_assert (stepping_thread == NULL);
5397
5398 /* The event thread is handled at the top, before we
5399 enter this loop. */
5400 gdb_assert (tp != ecs->event_thread);
5401
5402 /* If some thread other than the event thread is
5403 stepping, then scheduler locking can't be in effect,
5404 otherwise we wouldn't have resumed the current event
5405 thread in the first place. */
5406 gdb_assert (!schedlock_applies (currently_stepping (tp)));
5407
5408 stepping_thread = tp;
5409 }
Like:
gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.
The way the assertion is written is assuming that with schedlock=step
we'll always leave threads other than the one with the stepping range
locked, while that's not true with the "next" command. With schedlock
"step", other threads still run unlocked when "next" detects a
function call and steps over it. Whether that makes sense or not,
still, it's documented that way in the manual. If another thread hits
an event that doesn't cause a stop while the nexting thread steps over
a function call, we'll get here and fail the assertion.
The fix is just to adjust the assertion. Even though we found the
stepping thread, we'll still step-over the breakpoint that just
triggered correctly.
Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
steps over a function call. This commits fixes that. This ensures
that "next" doesn't switch focus to another thread, and checks whether
other threads run locked or not, depending on scheduler locking mode
and command. There's a lot of duplication in that file that this ends
cleaning up. There's more that could be cleaned up, but that would
end up an unrelated change, best done separately.
This new coverage in schedlock.exp happens to trigger the internal
error in question, like so:
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)
That's because we have more than one thread running the same loop, and
while one thread is stepping over a function call, the other thread
hits the step-resume breakpoint of the first, which needs to be
stepped over, and we end up in switch_back_to_stepped_thread exactly
in the problem case.
I think a simpler and more directed test is also useful, to not rely
on internal breakpoint magics. So this commit also adds a test that
has a thread trip on a conditional breakpoint that doesn't cause a
user-visible stop while another thread is stepping over a call. That
currently fails like this:
FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)
Tested on x86_64 Fedora 20.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
instead of assuming a thread with a stepping range is always
stepping.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* gdb.threads/schedlock.c (some_function): New function.
(call_function): New global.
(MAYBE_CALL_SOME_FUNCTION): New macro.
(thread_function): Call it.
* gdb.threads/schedlock.exp (get_args): Add description parameter,
and use it instead of a global counter. Adjust all callers.
(get_current_thread): Use "find current thread" for test message
here rather than having all callers pass down the same string.
(goto_loop): New procedure, factored out from ...
(my_continue): ... this.
(step_ten_loops): Change parameter from test message to command to
use. Adjust.
(list_count): Delete global.
(check_result): New procedure, factored out from duplicate top
level code.
(continue tests): Wrap in with_test_prefix.
(test_step): New procedure, factored out from duplicate top level
code.
(top level): Test "step" in combination with all scheduler-locking
modes. Test "next" in combination with all scheduler-locking
modes, and in combination with stepping over a function call or
not.
* gdb.threads/next-bp-other-thread.c: New file.
* gdb.threads/next-bp-other-thread.exp: New file.
This is more of a readline/terminal issue than a Python one.
PR17372 is a regression in 7.8 caused by the fix for PR17072:
commit 0017922d02
Author: Pedro Alves <palves@redhat.com>
Date: Mon Jul 14 19:55:32 2014 +0100
Background execution + pagination aborts readline/gdb
gdb_readline_wrapper_line removes the handler after a line is
processed. Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler. But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler. So the next input wakes up the event loop and calls into
readline, which aborts.
...
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c (gdb_readline_wrapper_line): Tweak comment.
(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
the input handler callback.
The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell. Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command. Tests covering both these examples are added.
The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.
Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing. No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* event-top.c (change_line_handler): Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(callback_handler_installed): New global.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New functions.
(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
gdb_rl_callback_handler_install instead of
rl_callback_handler_remove and rl_callback_handler_install.
(gdb_disable_readline): Call gdb_rl_callback_handler_remove
instead of rl_callback_handler_remove.
* event-top.h (gdb_rl_callback_handler_remove)
(gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New declarations.
* infrun.c (reinstall_readline_callback_handler_cleanup): New
cleanup function.
(fetch_inferior_event): Install it.
* top.c (gdb_readline_wrapper_line) Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(gdb_readline_wrapper_cleanup): Don't call
rl_callback_handler_install.
gdb/testsuite/
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.
While running GDB under Valgrind, I noticed that if the very first
command entered is just <RET>, GDB accesses an uninitialized value:
$ valgrind ./gdb -q -nx
==26790== Memcheck, a memory error detector
==26790== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26790== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==26790== Command: ./gdb -q -nx
==26790==
(gdb)
==26790== Conditional jump or move depends on uninitialised value(s)
==26790== at 0x619DFC: command_line_handler (event-top.c:588)
==26790== by 0x7813D5: rl_callback_read_char (callback.c:220)
==26790== by 0x6194B4: rl_callback_read_char_wrapper (event-top.c:166)
==26790== by 0x61988A: stdin_event_handler (event-top.c:372)
==26790== by 0x61847D: handle_file_event (event-loop.c:762)
==26790== by 0x617964: process_event (event-loop.c:339)
==26790== by 0x617A2B: gdb_do_one_event (event-loop.c:403)
==26790== by 0x617A7B: start_event_loop (event-loop.c:428)
==26790== by 0x6194E6: cli_command_loop (event-top.c:181)
==26790== by 0x60F86B: current_interp_command_loop (interps.c:317)
==26790== by 0x610A34: captured_command_loop (main.c:321)
==26790== by 0x60C728: catch_errors (exceptions.c:237)
==26790==
(gdb)
It's this check here:
/* If we just got an empty line, and that is supposed to repeat the
previous command, return the value in the global buffer. */
if (repeat && p == linebuffer && *p != '\\')
{
The problem is that linebuffer's contents were never initialized at
this point.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
* event-top.c (command_line_handler): Clear the first byte of
linebuffer, when it is first allocated.
exiting instead of throwing an error. E.g.:
$ TERM=foo gdb
(gdb) layout asm
Error opening terminal: foo.
$
The problem is that we're calling initscr to initialize the screen.
As mentioned in
http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html:
If errors occur, initscr() writes an appropriate error message to
standard error and exits.
^^^^^
Instead, we should use newterm:
"A program that needs an indication of error conditions, so it can
continue to run in a line-oriented mode if the terminal cannot support
a screen-oriented program, would also use this function."
After the patch:
$ TERM=foo gdb -q -nx
(gdb) layout asm
Cannot enable the TUI: error opening terminal [TERM=foo]
(gdb)
And then PR tui/17519 is about GDB not validating whether the terminal
has the necessary capabilities when enabling the TUI. If one tries to
enable the TUI with TERM=dumb (and e.g., from a shell within emacs),
GDB ends up with a clear screen, the cursor is placed at the
bottom/right corner of the screen, there's no prompt, typing shows no
echo, and there's no indication of what's going on. c-x,a gets you
out of the TUI, but it's completely non-obvious.
After the patch, we get:
$ TERM=dumb gdb -q -nx
(gdb) layout asm
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
(gdb)
While at it, I've moved all the tui_allowed_p validation to
tui_enable, and expanded the error messages. Previously we'd get:
$ gdb -q -nx -i=mi
(gdb)
layout asm
&"layout asm\n"
&"TUI mode not allowed\n"
^error,msg="TUI mode not allowed"
and:
$ gdb -q -nx -ex "layout asm" > foo
TUI mode not allowed
While now we get:
$ gdb -q -nx -i=mi
(gdb)
layout asm
&"layout asm\n"
&"Cannot enable the TUI when the interpreter is 'mi'\n"
^error,msg="Cannot enable the TUI when the interpreter is 'mi'"
(gdb)
and:
$ gdb -q -nx -ex "layout asm" > foo
Cannot enable the TUI when output is not a terminal
Tested on x86_64 Fedora 20.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR tui/16138
PR tui/17519
* tui/tui-interp.c (tui_is_toplevel): Delete global.
(tui_allowed_p): Delete function.
* tui/tui.c: Include "interps.h".
(tui_enable): Don't use tui_allowed_p. Error out here with
detailed error messages if the TUI is the top level interpreter,
or if output is not a terminal. Use newterm instead of initscr,
and error out if initializing the terminal fails. Also error out if
the terminal doesn't support cursor addressing.
* tui/tui.h (tui_allowed_p): Delete declaration.
I noticed that with:
$ TERM=dumb ./gdb -q -nx
<c-x,a>
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
(gdb)
The next key the user types is silently eaten.
The problem is that we're throwing an exception while in a readline
callback that isn't prepared for that:
(top-gdb) bt
#0 tui_enable () at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:388
#1 0x000000000051f47b in tui_rl_switch_mode (notused1=1, notused2=1) at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:101
#2 0x0000000000768d6f in _rl_dispatch_subseq (key=1, map=0xd069c0 <emacs_ctlx_keymap>, got_subseq=0) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:774
#3 0x0000000000768acb in _rl_dispatch_callback (cxt=0x1ce6190) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:686
#4 0x000000000078120b in rl_callback_read_char () at /home/pedro/gdb/mygit/build/../src/readline/callback.c:170
#5 0x0000000000619445 in rl_callback_read_char_wrapper (client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:166
#6 0x000000000061981b in stdin_event_handler (error=0, client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:372
#7 0x000000000061840e in handle_file_event (data=...) at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:762
#8 0x00000000006178f5 in process_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:339
#9 0x00000000006179bc in gdb_do_one_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:403
#10 0x0000000000617a0c in start_event_loop () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:428
Here, in _rl_dispatch_subseq:
769
770 rl_executing_keymap = map;
771
772 rl_dispatching = 1;
773 RL_SETSTATE(RL_STATE_DISPATCHING);
774 (*map[key].function)(rl_numeric_arg * rl_arg_sign, key);
775 RL_UNSETSTATE(RL_STATE_DISPATCHING);
776 rl_dispatching = 0;
777
778 /* If we have input pending, then the last command was a prefix
779 command. Don't change the state of rl_last_func. Otherwise,
GDB is called from line 774, but longjmp'ing at that point leaves
rl_dispatching and RL_STATE_DISPATCHING set.
Fix this by wrapping tui_rl_switch_mode in a TRY_CATCH.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
* tui/tui.c (tui_rl_switch_mode): Wrap tui_enable/tui_disable in
TRY_CATCH.
PR tui/16138 is about failure to initialize curses resulting in GDB
exiting instead of throwing an error. E.g.:
$ TERM=foo gdb
(gdb) layout asm
Error opening terminal: foo.
$
The problem is that we're calling initscr to initialize the screen.
As mentioned in
http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html:
If errors occur, initscr() writes an appropriate error message to
standard error and exits.
^^^^^
Instead, we should use newterm:
"A program that needs an indication of error conditions, so it can
continue to run in a line-oriented mode if the terminal cannot support
a screen-oriented program, would also use this function."
After the patch:
$ TERM=foo gdb -q -nx
(gdb) layout asm
Cannot enable the TUI: error opening terminal [TERM=foo]
(gdb)
And then PR tui/17519 is about GDB not validating whether the terminal
has the necessary capabilities when enabling the TUI. If one tries to
enable the TUI with TERM=dumb (and e.g., from a shell within emacs),
GDB ends up with a clear screen, the cursor is placed at the
bottom/right corner of the screen, there's no prompt, typing shows no
echo, and there's no indication of what's going on. c-x,a gets you
out of the TUI, but it's completely non-obvious.
After the patch, we get:
$ TERM=dumb gdb -q -nx
(gdb) layout asm
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
(gdb)
While at it, I've moved all the tui_allowed_p validation to
tui_enable, and expanded the error messages. Previously we'd get:
$ gdb -q -nx -i=mi
(gdb)
layout asm
&"layout asm\n"
&"TUI mode not allowed\n"
^error,msg="TUI mode not allowed"
and:
$ gdb -q -nx -ex "layout asm" > foo
TUI mode not allowed
While now we get:
$ gdb -q -nx -i=mi
(gdb)
layout asm
&"layout asm\n"
&"Cannot enable the TUI when the interpreter is 'mi'\n"
^error,msg="Cannot enable the TUI when the interpreter is 'mi'"
(gdb)
and:
$ gdb -q -nx -ex "layout asm" > foo
Cannot enable the TUI when output is not a terminal
Tested on x86_64 Fedora 20.
gdb/
2014-10-29 Pedro Alves <palves@redhat.com>
PR tui/16138
PR tui/17519
* tui/tui-interp.c (tui_is_toplevel): Delete global.
(tui_allowed_p): Delete function.
* tui/tui.c: Include "interps.h".
(tui_enable): Don't use tui_allowed_p. Error out here with
detailed error messages if the TUI is the top level interpreter,
or if output is not a terminal. Use newterm instead of initscr,
and error out if initializing the terminal fails. Also error out if
the terminal doesn't support cursor addressing.
* tui/tui.h (tui_allowed_p): Delete declaration.
In gdb.base/fileio.c, some functions may depend on others. For
example, test_rename renames a file to one directory which is created
in test_system. That is means, if test_system fails, test_rename
fails too, which is not a good practise, IMO.
In test_system, system ("mkdir -p XX") is used to create directories
needed for test_rename. In this patch, we use dejagnu remote_exec
proc to create these directories on host.
In my gdb testing, mingw32 host and arm-none-eabi target, system
("mkdir -p XX") doesn't work properly (this issue can be addressed
separately), and this patch fixes the following fails.
FAIL: gdb.base/fileio.exp: Renaming a directory to a non-empty directory returns ENOTEMPTY or EEXIST
FAIL: gdb.base/fileio.exp: Unlink a file
FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES
gdb/testsuite:
2014-10-29 Yao Qi <yao@codesourcery.com>
* gdb.base/fileio.exp: Make directories on host.
I see the following fail in fileio.exp on mingw32 host gdb,
rename 1: ret = -1, errno = 13^M
^M
Breakpoint 2, stop () at fileio.c:76^M
76 static void stop () {}^M
(gdb) FAIL: gdb.base/fileio.exp: Rename a file
the test fails to rename a file which is not expected. The previous
test test_write doesn't close the file, so the rename fails as a
result on Windows. This patch fixes it by closing file in test_write,
and the fail goes away.
rename 1: ret = 0, errno = 0 OK^M
^M
Breakpoint 2, stop () at fileio.c:76^M
76 static void stop () {}^M
(gdb) PASS: gdb.base/fileio.exp: Rename a file
gdb/testsuite:
2014-10-29 Yao Qi <yao@codesourcery.com>
* gdb.base/fileio.c (test_write): Close the file.
We are trying to insert a breakpoint on line 4 for the following
Ada code.
3 procedure STR is
4 XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP
5 K : Integer;
6 begin
7 K := 13;
The code generated on ARM (-march=armv7-m) starts like this:
(gdb) disass str'address
Dump of assembler code for function _ada_str:
--# Line str.adb:3
0x08000014 <+0>: push {r4, r7, lr}
0x08000016 <+2>: sub sp, #28
0x08000018 <+4>: add r7, sp, #0
0x0800001a <+6>: mov r3, sp
0x0800001c <+8>: mov r4, r3
--# Line str.adb:4
0x0800001e <+10>: ldr r3, [pc, #84] ; (0x8000074 <_ada_str+96>)
0x08000020 <+12>: ldr r3, [r3, #0]
0x08000022 <+14>: str r3, [r7, #20]
0x08000024 <+16>: ldr r3, [r7, #20]
[...]
When computing the address related to str.adb:4, GDB correctly
resolves it to 0x0800001e first, but then considers the next
3 instructions as being part of the prologue because it thinks
they are part of stack-protector code. As a result, instead
of inserting the breakpoint at line 4, it skips those instruction
and consequently the rest of the instructions until the start
of the next line, which his line 7.
The stack-protector code is expected to start like this...
ldr Rn, .Label
....
.Lable:
.word __stack_chk_guard
... but the implementation actually accepts a sequence where
the ldr location points to an address for which there is no symbol.
It only aborts if the address points to a symbol which is not
__stack_chk_guard.
Since the __stack_chk_guard symbol is always expected to exist
when used (it lives in .dynsym), this patch fixes the issue by
requiring that the ldr gets the address of the __stack_chk_guard
symbol. If the address could not be resolved, then it rejects
the sequence as being stack-protector code.
gdb/ChangeLog:
* arm-tdep.c (arm_skip_stack_protector): Return early if
address loaded by first "ldr" instruction does not have
a corresponding minimal symbol. Update comment.
Tested on arm-eabi using AdaCore's testsuite.
Tested on arm-linux-gnueabi by Yao as well.
This patch fixes the bug in my patch skipping stack protector
https://www.sourceware.org/ml/gdb-patches/2010-12/msg00110.html
In my skipping stack protector patch, I misunderstood the constant vs.
immediate on instruction encodings, and treated immediate as constant
by mistake. The instruction 'ldr Rd, [PC, #immed]' loads the
address of __stack_chk_guard to Rd, and #immed is an offset from PC.
We should get the __stack_chk_guard from *(pc + #immed).
As a result of this mistake, arm_analyze_load_stack_chk_guard returns
the wrong address of __stack_chk_guard, and the symbol
__stack_chk_guard can't be found. However, we continue to match the
following instructions when symbol isn't found, so the code still
works. In other words, the code just matches the instruction pattern
without checking __stack_chk_guard symbol correctly.
Joel's patch <https://sourceware.org/ml/gdb-patches/2014-10/msg00605.html>
makes the heuristics stricter that we stop matching instructions if
symbol __stack_chk_guard isn't found. Then the bug is exposed. This
patch is to correct the load address computation for ldr instruction,
and it fixes some fails in gdb.mi/gdb792.exp on armv4t both arm and
thumb mode.
Regression tested on arm-linux-gnueabi target with
{armv4t, armv7-a} x {marm, mthumb} x {-fstack-protector,-fno-stack-protector}
gdb:
2014-10-29 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (arm_analyze_load_stack_chk_guard): Compute the
loaded address correctly of ldr instruction.
TL;DR - if we step an instruction that is as long as
decr_pc_after_break (1-byte on x86) right after removing the
breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the
PC, but it shouldn't.
In non-stop mode, when a breakpoint is removed, it is moved to the
"moribund locations" list. This is because other threads that are
running may have tripped on that breakpoint as well, and we haven't
heard about it. When a trap is reported, we check if perhaps it was
such a deleted breakpoint that caused the trap. If so, we also need
to adjust the PC (decr_pc_after_break).
Now, say that, on x86:
- a breakpoint was placed at an address where we have an instruction
of the same length as decr_pc_after_break on this arch (1 on x86).
- the breakpoint is removed, and thus put on the moribund locations
list.
- the thread is single-stepped.
As there's no breakpoint inserted at PC anymore, the single-step
actually executes the 1-byte instruction normally. GDB should _not_
adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break
confuses the step SIGTRAP reported for this single-step as being a
SIGTRAP for the moribund location of the breakpoint that used to be at
the previous PC, and so infrun applies the decr_pc_after_break
adjustment incorrectly.
The confusion comes from the special case mentioned in the comment:
static void
adjust_pc_after_break (struct execution_control_state *ecs)
{
...
As a special case, we could have hardware single-stepped a
software breakpoint. In this case (prev_pc == breakpoint_pc),
we also need to back up to the breakpoint address. */
if (thread_has_single_step_breakpoints_set (ecs->event_thread)
|| !ptid_equal (ecs->ptid, inferior_ptid)
|| !currently_stepping (ecs->event_thread)
|| (ecs->event_thread->stepped_breakpoint
&& ecs->event_thread->prev_pc == breakpoint_pc))
regcache_write_pc (regcache, breakpoint_pc);
The condition that incorrectly triggers is the
"ecs->event_thread->prev_pc == breakpoint_pc" one.
Afterwards, the next resume resume re-executes an instruction that had
already executed, which if you're lucky, results in the inferior
crashing. If you're unlucky, you'll get silent bad behavior...
The fix is to remember that we stepped a breakpoint. Turns out the
only case we step a breakpoint instruction today isn't covered by the
testsuite. It's the case of a 'handle nostop" signal arriving while a
step is in progress _and_ we have a software watchpoint, which forces
always single-stepping. This commit extends sigstep.exp to cover
that, and adds a new test for the adjust_pc_after_break issue.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/12623
* gdbthread.h (struct thread_info) <stepped_breakpoint>: New
field.
* infrun.c (resume) <stepping breakpoint instruction>: Set the
thread's stepped_breakpoint field. Skip if reverse debugging.
Add comment.
(init_thread_stepping_state, handle_signal_stop): Clear the
thread's stepped_breakpoint field.
gdb/testsuite/
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/12623
* gdb.base/sigstep.c (no_handler): New global.
(main): If 'no_handler is true, set the signal handlers to
SIG_IGN.
* gdb.base/sigstep.exp (breakpoint_over_handler): Add
with_sw_watch and no_handler parameters. Handle them.
(top level) <stepping over handler when stopped at a breakpoint
test>: Add a test axis for testing with a software watchpoint, and
another for testing with the signal handler set to SIG_IGN.
* gdb.base/step-sw-breakpoint-adjust-pc.c: New file.
* gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
I noticed that when I single-step into a signal handler with a
pending/queued signal, the following single-steps while the program is
in the signal handler leave $eflags.TF set. That means subsequent
continues will trap after one instruction, resulting in a spurious
SIGTRAP being reported to the user.
This is a kernel bug; I've reported it to kernel devs (turned out to
be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux
3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream.
This commit extends gdb.base/sigstep.exp to cover this use case,
xfailed.
Here's what the bug looks like:
(gdb) start
Temporary breakpoint 1, main () at si-handler.c:48
48 setup ();
(gdb) next
50 global = 0; /* set break here */
Let's queue a signal, so we can step into the handler:
(gdb) handle SIGUSR1
Signal Stop Print Pass to program Description
SIGUSR1 Yes Yes Yes User defined signal 1
(gdb) queue-signal SIGUSR1
TF is not set:
(gdb) display $eflags
1: $eflags = [ PF ZF IF ]
Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1:
(gdb) si
sigusr1_handler (sig=0) at si-handler.c:31
31 {
1: $eflags = [ PF ZF IF ]
No TF yet. But another single-step...
(gdb) si
0x0000000000400621 31 {
1: $eflags = [ PF ZF TF IF ]
... ends up with TF left set. This results in PTRACE_CONTINUE
trapping after each instruction is executed:
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31
31 {
1: $eflags = [ PF ZF TF IF ]
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
sigusr1_handler (sig=10) at si-handler.c:32
32 global = 0;
1: $eflags = [ PF ZF TF IF ]
(gdb)
Note that even another PTRACE_SINGLESTEP does not fix it:
(gdb) si
33 }
1: $eflags = [ PF ZF TF IF ]
(gdb)
Eventually, it gets "fixed" by the rt_sigreturn syscall, when
returning out of the handler:
(gdb) bt
#0 sigusr1_handler (sig=10) at si-handler.c:33
#1 <signal handler called>
#2 main () at si-handler.c:50
(gdb) set disassemble-next-line on
(gdb) si
0x0000000000400632 33 }
0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp
=> 0x0000000000400632 <sigusr1_handler+18>: c3 retq
1: $eflags = [ PF ZF TF IF ]
(gdb)
<signal handler called>
=> 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax
1: $eflags = [ PF ZF TF IF ]
(gdb) si
<signal handler called>
=> 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall
1: $eflags = [ PF ZF TF IF ]
(gdb)
main () at si-handler.c:50
50 global = 0; /* set break here */
=> 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global>
1: $eflags = [ PF ZF IF ]
(gdb)
The bug doesn't happen if we instead PTRACE_CONTINUE into the signal
handler -- e.g., set a breakpoint in the handler, queue a signal, and
"continue".
gdb/testsuite/
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/17511
* gdb.base/sigstep.c (handler): Add a few more writes to 'done'.
* gdb.base/sigstep.exp (other_handler_location): New global.
(advance): Support stepping into the signal handler, and running
commands while in the handler.
(in_handler_map): New global.
(top level): In the advance test, add combinations for getting
into the handler with stepping commands, and for running commands
in the handler. Add comment descripting the advancei tests.
Hacking on sigstep.exp, I found it harder to understand and extend
than ideal.
- GDB is currently not restarted between the different
tests/combinations in the file, and some parts of the tests' setup
are done on the top level, and shared between tests. It's not
trivial to understand which breakpoints each test procedure expects
to be set or not set. And it's not trivial to disable parts of the
test if you want quickly try out just a subset of the tests
(running the whole file takes a bit).
- Because GDB is currently not restarted between tests, if some test
triggers a ptrace/kernel bug, the following tests may end up with
cascading fails. That makes it hard to add a test to cover a
kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note
how with kernels with bug gdb/8744 (stepi over sigreturn syscall
exits program) the test program exits, and nothing restarts it
afterwards...
- The manual test message prefix management gets a bit in the way.
Nowadays, we have with_test_prefix which makes it simpler.
- 'i' is used as parameter name in the various procedures, meaning
'the command the test', which isn't as obvious as it could.
This commit addresses all that.
gdb/testsuite/
2014-10-28 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.exp: Use build_executable instead of
prepare_for_testing.
(top level): Move code that starts GDB, runs to main and creates a
display to ...
(restart): ... this new procedure.
(top level): Move backtrace from signal handler test to ...
(validate_backtrace): ... this new procedure.
(advance, advancei): Rename parameter from 'i' to 'cmd'. Use
with_test_prefix. Always restart GDB.
(skip_to_handler): Rename parameter from 'i' to 'cmd'. Use
with_test_prefix. Always restart GDB. No need to delete
breakpoints after the test.
(test_skip_handler): Remove prefix parameter.
(skip_over_handler, breakpoint_to_handler)
(breakpoint_to_handler_entry, breakpoint_over_handler): Rename
parameter from 'i' to 'cmd'. Use with_test_prefix. Always
restart GDB. No need to delete breakpoints after the test.
(top level): Use foreach to call the test procedures with
different commands.
This makes it easier to find the bugs in Bugzilla.
gdb/testsuite/
2014-10-28 Pedro Alves <palves@redhat.com>
* gdb.base/sigaltstack.exp: Update to use Bugzilla bug numbers
instead of GNATS numbers.
* gdb.base/sigbpt.exp: Likewise.
* gdb.base/siginfo.exp: Likewise.
* gdb.base/sigstep.exp: Likewise.
In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
shows a target that was broken by the recent update_thread_list
optimization:
(gdb) target remote qa8-centos32-cs:10514
...
(gdb) continue
Continuing.
Cannot execute this command without a live selected thread.
(gdb)
The error means that the current thread is in "exited" state when the
continue command is processed. The root of the problem was found
here:
> Sending packet: $Hg0#df...Packet received:
...
> Sending packet: $?#3f...Packet received: S00
> Sending packet: $qfThreadInfo#bb...Packet received: l
> Sending packet: $Hc-1#09...Packet received:
> Sending packet: $qC#b4...Packet received: unset
This target doesn't really support threads (no thread indication in
stop reply packets; no support for qC), but then supports
qfThreadInfo, and returns an empty thread list to GDB.
See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
why the target does that.
As remote_update_thread_list deletes threads from GDB's list that are
not found in the thread list that the target reports, the result is
that GDB deletes the "fake" main thread that GDB added itself. (As
that thread is currently selected, it is marked "exited" instead of
being deleted straight away.)
This commit avoids deleting the main thread in this scenario.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* remote.c (remote_thread_alive): New, factored out from ...
(remote_thread_alive): ... this.
(remote_update_thread_list): Bail out before deleting threads if
the target returned an empty list, and, the current thread has a
magic/fake ptid.
I noticed that "si" behaves differently when a "handle nostop" signal
arrives while the step is in progress, depending on whether the
program was stopped at a breakpoint when "si" was entered.
Specifically, in case GDB needs to step off a breakpoint, the handler
is skipped and the program stops in the next "mainline" instruction.
Otherwise, the "si" stops in the first instruction of the signal
handler.
I was surprised the testsuite doesn't catch this difference. Turns
out gdb.base/sigstep.exp covers a bunch of cases related to stepping
and signal handlers, but does not test stepi nor nexti, only
step/next/continue.
My first reaction was that stopping in the signal handler was the
correct thing to do, as it's where the next user-visible instruction
that is executed is. I considered then "nexti" -- a signal handler
could be reasonably considered a subroutine call to step over, it'd
seem intuitive to me that "nexti" would skip it.
But then, I realized that signals that arrive while a plain/line
"step" is in progress _also_ have their handler skipped. A user might
well be excused for being confused by this, given:
(gdb) help step
Step program until it reaches a different source line.
And the signal handler's sources will be in different source lines,
after all.
I think that having to explain that "stepi" steps into handlers, (and
that "nexti" wouldn't according to my reasoning above), while "step"
does not, is a sign of an awkward interface.
E.g., if a user truly is interested in stepping into signal handlers,
then it's odd that she has to either force the signal to "handle
stop", or recall to do "stepi" whenever such a signal might be
delivered. For that use case, it'd seem nicer to me if "step" also
stepped into handlers.
This suggests to me that we either need a global "step-into-handlers"
setting, or perhaps better, make "handle pass/nopass stop/nostop
print/noprint" have have an additional axis - "handle
stepinto/nostepinto", so that the user could configure whether
handlers for specific signals should be stepped into.
In any case, I think it's simpler (and thus better) for all step
commands to behave the same. This commit thus makes "si/ni" skip
handlers for "handle nostop" signals that arrive while the command was
already in progress, like step/next do.
To be clear, nothing changes if the program was stopped for a signal,
and the user enters a stepping command _then_ -- GDB still steps into
the handler. The change concerns signals that don't cause a stop and
that arrive while the step is in progress.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Also skip handlers when a random
signal arrives while handling a "stepi" or a "nexti". Set the
thread's 'step_after_step_resume_breakpoint' flag.
gdb/doc/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Continuing and Stepping): Add cross reference to
info on stepping and signal handlers.
(Signals): Explain stepping and signal handlers. Add context
index entry, and cross references.
gdb/testsuite/
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
I see the following fails on powerpc64-linux,
(gdb) target tfile tfile-basic.tf^M
warning: Uploaded tracepoint 1 has no source location, using raw address^M
Tracepoint 1 at 0x10012358^M
Created tracepoint 1 for target's tracepoint 1 at 0x10012358.^M
(gdb) PASS: gdb.trace/tfile.exp: target tfile tfile-basic.tf
info trace^M
Num Type Disp Enb Address What^M
1 tracepoint keep y 0x0000000010012358 <write_basic_trace_file>^M
installed on target^M
(gdb) FAIL: gdb.trace/tfile.exp: info tracepoints on trace file
-target-select tfile tfile-basic.tf^M
=thread-group-started,id="i1",pid="1"^M
=thread-created,id="1",group-id="i1"^M
&"warning: Uploaded tracepoint 1 has no source location, using raw address\n"^M
=breakpoint-created,bkpt={number="1",type="tracepoint",disp="keep",enabled="y",
addr="0x0000000010012358",at="<write_basic_trace_file>",thread-groups=["i1"],
times="0",installed="y",original-location="*0x10012358"}^M
~"Created tracepoint 1 for target's tracepoint 1 at 0x10012358.\n"^M
^connected^M
(gdb) ^M
FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: select trace file
These fails are caused by writing function descriptor address into trace
file instead of function address. This patch is to teach tfile.c to
write function address on powerpc64 target. With this patch applied,
fails in tfile.exp and mi-traceframe-changed.exp are fixed. Is it
OK?
gdb/testsuite:
2014-10-27 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.c (adjust_function_address)
[__powerpc64__ && _CALL_ELF != 2]: Get function address from
function descriptor.
When running GDB's reverse debugging testsuite against a few ARM
multilibs, i noticed failures in the machinestate* testcases.
Further investigation showed that push and pop instruction encodings
A1 and A2 were not being handled properly, thus we missed saving
important contents from registers and memory. When going backwards,
such contents were not restored and thus we ended up with a corrupted
state that did not correspond to the real values we had at a
particular point in time.
Attached is a patch that fixes around 36 failures for both
gdb.reverse/machinestate.exp and
gdb.reverse/machinestate-precsave.exp testcases, making them fully
pass. This is for both armv7 and armv4. I still see failures for
armv4 thumb though, so it needs a bit more investigation.
I see no regressions due to this patch for armv7, armv7 thumb, armv4
and armv4 thumb.
gdb/ChangeLog:
* arm-tdep.c (INSN_S_L_BIT_NUM): Document.
(arm_record_ld_st_imm_offset): Reimplement to cover all
load/store cases for ARM opcode 010.
(arm_record_ld_st_multiple): Reimplement to cover all
load/store cases for ARM opcode 100.
This commit modifies the code that prints attach and detach messages
related to following fork and vfork. The changes include using
target_terminal_ours_for_output instead of target_terminal_ours,
printing "vfork" instead of "fork" for all vfork-related messages,
and using _() for the format strings of all of the messages.
We also add a "detach" message for when a fork parent is detached.
Previously in this case the only message was notification of attaching
to the child. We still do not print any messages when following the
parent and detaching the child (the default). The rationale for this
is that from the user's perspective the new child was never attached.
Note that all of these messages are only printed when 'verbose' is set
or when debugging is turned on.
The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were
modified to check for the new message.
Tested on x64 Ubuntu Lucid, native only.
gdb/ChangeLog:
* infrun.c (follow_fork_inferior): Update fork message printing
to use target_terminal_ours_for_output instead of
target_terminal_ours, to use _() for all format strings, to print
"vfork" instead of "fork" for vforks, and to add a detach message.
(handle_vfork_child_exec_or_exit): Update message printing to use
target_terminal_ours_for_output instead of target_terminal_ours, to
use _() for all format strings, and to fix some formatting.
gdb/testsuite/ChangeLog:
* gdb.base/foll-fork.exp (test_follow_fork,
catch_fork_child_follow): Check for updated fork messages emitted
from infrun.c.
* gdb.base/foll-vfork.exp (vfork_parent_follow_through_step,
vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp,
vfork_and_exec_child_follow_through_step): Check for updated vfork
messages emitted from infrun.c.
gdb/ChangeLog:
* gnu-v3-abi.c (gnuv3_pass_by_reference): Call TYPE_TARGET_TYPE
on the arg type of a constructor only if it is of reference type.
gdb/testsuite/ChangeLog:
* gdb.cp/non-trivial-retval.cc: Add a test case.
* gdb.cp/non-trivial-retval.exp: Add a test.
First:
"Breakpoint.delete" is missing parenthesis.
Second:
Someone on IRC asked, how come there is no disable() method in the
Breakpoint object. It turns out you have to do "bp.enabled = False".
Since every normal person would probably search for "disable" in that page
if their intent is to disable a python breakpoint, I thought it would be
useful if the description contained "disable" so it would be easy to find.
The result might seem a bit silly and redundant, so I am open to
suggestions.
gdb/doc/ChangeLog:
* python.texi (Breakpoints In Python): Add parenthesis after
Breakpoint.delete. Clarify Breakpoint.enabled description so
that it contains "disable".
Patch <https://sourceware.org/ml/gdb-patches/2011-07/msg00225.html> was
to fix the problem that py-objfile-script-gdb.py is removed after an
in-tree build and test. As a result of the previous patch (we don't
remove files copied to host any more), this patch is no longer needed.
This patch is to revert it logically.
gdb/testsuite:
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.python/py-objfile-script-gdb.py.in: Rename it to ...
* gdb.python/py-objfile-script-gdb.py: New file.
* gdb.python/py-objfile-script.exp: Update reference to
py-objfile-script-gdb.py.in. Use gdb_remote_donwload instead
of remote_download. Remove the dest file.
Nowadays, if we do in-tree build and run tests sequentially, some source
files are removed, due to the following pattern:
set pi_txt [gdb_remote_download host ${srcdir}/${subdir}/pi.txt]
remote_exec host "rm -f $pi_txt"
If testing is run sequentially, file ${srcdir}/${subdir}/pi.txt is
copied to ${objdir}/${subdir}/pi.txt. However, ${objdir} is ${srcdir}
in the in-tree build/test, so the file is coped to itself, as a nop.
As a result, the file in source is removed at the end of test.
This patch fixes this problem by not removing files copied to host in
each test. This patch also addresses the question we've had that why
don't we keep files copied to host because they are needed to reproduce
certain fails.
gdb/testsuite:
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.base/checkpoint.exp: Don't remove file copied on host.
* gdb.base/step-line.exp: Likewise.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
* gdb.dwarf2/dw2-basic.exp: Likewise.
* gdb.dwarf2/dw2-compressed.exp: Likewise.
* gdb.dwarf2/dw2-filename.exp: Likewise.
* gdb.dwarf2/dw2-intercu.exp: Likewise.
* gdb.dwarf2/dw2-intermix.exp: Likewise.
* gdb.dwarf2/dw2-producer.exp: Likewise.
* gdb.dwarf2/mac-fileno.exp: Likewise.
* gdb.python/py-frame-args.exp: Likewise.
* gdb.python/py-framefilter.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
* gdb.python/py-objfile-script.exp: Likewise
* gdb.python/py-pp-integral.exp: Likewise.
* gdb.python/py-pp-re-notag.exp: Likewise.
* gdb.python/py-prettyprint.exp: Likewise.
* gdb.python/py-section-script.exp: Likewise.
* gdb.python/py-typeprint.exp: Likewise.
* gdb.python/py-xmethods.exp: Likewise.
* gdb.stabs/weird.exp: Likewise.
* gdb.xml/tdesc-regs.exp: Likewise.
This patch fixes the failures that occur with the
gdb.dwarf2/dw2-dir-file-name.exp test on 64-bit MIPS and compressed
MIPS ISAs (i.e. MIPS16 and microMIPS).
The failures on 64-bit occur because the generated DWARF address
information is always 32-bit, which causes the upper 32-bits of
addresses to be truncated and causes breakpoints to be set on the
wrong address if any of the upper 32-bits are non-zero. I suspect
that other 64-bit architectures get away with it because they
place all their instructions at a VMA lower than 2^32 by default.
This patch causes 64-bit addresses to be generated if a 64-bit
target is detected.
The failures on MIPS16 and microMIPS occur because the breakpoint
address needs to have the LSB set to 1 (used to indicate that the
code is compressed). However, the function name is interpreted as
a data label, causing GDB to set breakpoints at even addresses.
This is fixed by explicitly adding a '.insn' directive (see
https://sourceware.org/binutils/docs/as/MIPS-insn.html) after the
label on MIPS only.
gdb/testsuite/
2014-10-18 Kwok Cheung Yeung <kcy@codesourcery.com>
* gdb.dwarf2/dw2-dir-file-name.exp (addr_len): New.
(out_cu): Use addr_len for the size of addresses.
(out_line): Likewise. Size DW_LNE_set_address instruction
according to addr_len.
* gdb.dwarf2/dw2-dir-file-name.c (START_INSNS): New.
(FUNC): Add START_INSNS to definition.
I see the following two fails on arm-none-eabi target, because argv[0]
isn't available.
print argv[0]^M
$1 = 0x1f78 "/dev/null"^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name
print argv[0]^M
$1 = 0x1f78 "/dev/null"^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept directory symbolic link name
My first thought is to check [target_info exists noargs], and skip the
test if it returns true. However, noargs is set in gdbserver board
files, so argv0-symlink.exp will be skipped on gdbserver board file.
The change is too aggressive.
When the program is running with gdbserver, argv[1] to argv[N] aren't
available, but argv[0] is. Fortunately, argv0-symlink.exp only
requires argv[0]. argv0-symlink.exp can be run with gdbserver board
file, as what we do now.
What we need to check is whether argv[0] is available, so I add a new
proc gdb_has_argv0 to do so by starting a program, and check
argc/argv[0] to see whether argv[0] is available.
Dan fixed the similar problem by checking noargs, which is too strong.
https://sourceware.org/ml/gdb-patches/2010-02/msg00398.html as a
result, the test is skipped on gdbserver. This patch fixed it too.
gdb/testsuite:
2014-10-18 Yao Qi <yao@codesourcery.com>
* gdb.base/argv0-symlink.exp: Check argv[0] value if
gdb_has_argv0 return true.
* gdb.guile/scm-value.exp (test_value_in_inferior): Don't
check [target_info exists noargs], check [gdb_has_argv0]
instead.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* lib/gdb.exp (gdb_has_argv0, gdb_has_argv0_1): New
procedures.
If one is watching new_objfile events in python, it helps to know
when the list of objfiles is cleared. This patch adds a new
clear_objfiles event to support this.
This patch is all just cut-n-paste-n-tweak derived from
the new_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new event gdb.clear_objfiles.
* python/py-event.h (emit_clear_objfiles_event): Clear
* python/py-events.h (events_object): New member clear_objfiles.
* python/py-evts.c (gdbpy_initialize_py_events): Add clear_objfiles
event.
* python/py-inferior.c (python_new_objfile): If objfile is NULL,
emit clear_objfiles event.
* python/py-newobjfileevent.c (create_clear_objfiles_event_object): New
function.
(emit_clear_objfiles_event): New function.
(clear_objfiles): New event.
* python/python-internal.h (gdbpy_initialize_clear_objfiles_event):
Declare.
* python/python.c (_initialize_python): Call
gdbpy_initialize_clear_objfiles_event.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document clear_objfiles event.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.exp: Update expected output for clear_objfiles
event.
* gdb.python/py-events.py: Add clear_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new gdb.Objfile.progspace attribute.
* python/py-objfile.c (objfpy_get_progspace): New function.
(objfile_getset): New entry for "progspace".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document new progspace attribute.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test progspace attribute.
Some testcases, mostly gdb.reverse ones, assume the presence of a
'/' directory separator before the source file name. This is
incorrect for mingw32 hosts, generating false failures for those
tests.
I attempted to catch most of the occurrences of the pattern
".*/$srcfile" and replaced them with ".*$srcfile". The latter
is used elsewhere in the testsuite. The resulting patch is attached.
I also see other occurrences of the same assumption throughout the
testsuite, but usually they are arguments for function calls and i
seem to recall either the test harness or GDB deals with those
paths properly.
gdb/testsuite:
2014-10-17 Luis Machado <lgustavo@codesourcery.com>
* gdb.guile/scm-breakpoint.exp: Do not assume any
directory separators when matching source file paths.
* gdb.python/py-breakpoint.exp: Likewise.
* gdb.reverse/break-precsave.exp: Likewise.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse-bkpt.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/i387-env-reverse.exp: Likewise.
* gdb.reverse/i387-stack-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
When I run test with board file local-remote-host-native.exp, I see
the following warning,
$ make check RUNTESTFLAGS="--host_board=local-remote-host-native
--target_board=local-remote-host-native tdesc-arch.exp
HOST_DIR=/tmp/foo/"
(gdb) set tdesc filename ../../../../git/gdb/testsuite/gdb.xml/trivial.xml^M
warning: Could not open "../../../../git/gdb/testsuite/gdb.xml/trivial.xml"
(gdb) quit^
because "${srcdir}/gdb.xml/trivial.xml" doesn't exist on host. This
patch is to copy trivial.xml to host and the warning goes away.
(gdb) set tdesc filename /tmp/foo/trivial.xml^M
(gdb) quit^
tdesc-regs.exp has the similar problem that single-reg.xml may not
exist on host at all, and it should be copied to host too.
gdb/testsuite:
2014-10-17 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (gdb_skip_xml_test): Copy trivial.xml to host.
* gdb.xml/tdesc-regs.exp: Copy single-reg.xml to host.
When we repeat a command, by just pressing <ret>, the input from the
previous command is reused for the new command invocation.
When an execution command strips the "&" out of its incoming argument
string, to detect background execution, we poke a '\0' directly to the
incoming argument string.
Combine both, and a repeat of a background command loses the "&".
This is actually only visible if args other than "&" are specified
(e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&"
alone (e.g. "c&") doesn't actually clobber the incoming string.
Fix this by making strip_bg_char return a new string instead of poking
a hole in the input string.
New test included.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* infcmd.c (strip_bg_char): Change prototype and rewrite. Now
returns a copy of the input.
(run_command_1, continue_command, step_1, jump_command)
(signal_command, until_command, advance_command, finish_command)
(attach_command): Adjust and install a cleanup to free the
stripped args.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* gdb.base/bg-execution-repeat.c: New file.
* gdb.base/bg-execution-repeat.exp: New file.
If all threads in the target were already running when the user does
"c -a", nothing puts the inferior's terminal settings in effect and
removes stdin from the event loop, which we must when running a
foreground command. The result is that user input afterwards crashes
readline/gdb:
(gdb) start
Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23.
Starting program: continue-all-already-running
Temporary breakpoint 1, main () at continue-all-already-running.c:23
23 sleep (10);
(gdb) c -a&
Continuing.
(gdb) c -a
Continuing.
p 1
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
$
Backtrace:
Program received signal SIGABRT, Aborted.
0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(top-gdb) p 1
$1 = 1
(top-gdb) bt
#0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x0000003b36a36f68 in __GI_abort () at abort.c:89
#2 0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116
#3 0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167
#4 0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373
#5 0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763
#6 0x0000000000617631 in process_event () at gdb/event-loop.c:340
#7 0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404
#8 0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429
#9 0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182
#10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318
#11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323
#12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
at gdb/exceptions.c:237
#13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151
#14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
at gdb/exceptions.c:237
#15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159
#16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32
(top-gdb)
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* infcmd.c (continue_1): If continuing all threads in the
foreground, make sure the inferior's terminal settings are put in
effect.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* gdb.base/continue-all-already-running.c: New file.
* gdb.base/continue-all-already-running.exp: New file.
Jan caught an intermittent GDB crash with the annota1.exp test:
Starting program: .../gdb/testsuite/gdb.base/annota1 ^M
[...]
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
[...]
readline: readline_callback_read_char() called with no handler!^M
ERROR: Process no longer exists
All we need to is to continue the inferior in the foreground, and type
a command while the inferior is running. E.g.:
(gdb) set annotate 2
▒▒pre-prompt
(gdb)
▒▒prompt
c
▒▒post-prompt
Continuing.
▒▒starting
▒▒frames-invalid
*inferior is running now*
p 1<ret>
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
$
When we run a foreground execution command we call
target_terminal_inferior to stop GDB from processing input, and to put
the inferior's terminal settings in effect. Then we tell readline to
hide the prompt with display_gdb_prompt, which clears readline's input
callback too. When the target stops, we call target_terminal_ours,
which re-installs stdin in the event loop, and then we redisplay the
prompt, reinstalling the readline callbacks.
However, when annotations are in effect, the "frames-invalid"
annotation code calls target_terminal_ours after 'resume' had already
called target_terminal_inferior:
(top-gdb) bt
#0 0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219
#1 0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705
#2 0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612
#3 0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136
#4 0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263
#5 0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613
And then once we hide the prompt and remove readline's input handler
callback, we're in a bad state. We end up with the target running
supposedly in the foreground, but with stdin still installed on the
event loop. Any input then calls into readline, which aborts because
no rl_linefunc callback handler is installed:
Program received signal SIGABRT, Aborted.
0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(top-gdb) bt
#0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x0000003b36a36f68 in __GI_abort () at abort.c:89
During symbol reading, debug info gives source 9 included from file at zero line 0.
During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1.
#2 0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116
#3 0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167
#4 0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373
#5 0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763
#6 0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340
#7 0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404
#8 0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429
#9 0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182
#10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318
#11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323
#12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
at src/gdb/exceptions.c:237
#13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151
#14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
at src/gdb/exceptions.c:237
#15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159
#16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32
The fix is to make the annotation code call target_terminal_inferior
again after printing, if the inferior's settings were in effect.
While at it, when we're doing output only, instead of
target_terminal_ours, we should call target_terminal_ours_for_output.
The latter doesn't actually remove stdin from the event loop, and also
leaves SIGINT forwarded to the target.
New test included.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* annotate.c (annotate_breakpoints_invalid): Use
target_terminal_our_for_output instead of target_terminal_ours.
Give back the terminal to the target.
(annotate_frames_invalid): Likewise.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* gdb.base/annota-input-while-running.c: New file.
* gdb.base/annota-input-while-running.exp: New file.
I found a place that should be giving back the terminal to the target,
but only if the target was already owning it. So I need to add a
getter for who owns the terminal.
The trouble is that several places/target have their own globals to
track this state:
- inflow.c:terminal_is_ours
- remote.c:remote_async_terminal_ours_p
- linux-nat.c:async_terminal_is_ours
- go32-nat.c:terminal_is_ours
While one might think of adding a new target_ops method to query this,
conceptually, this state isn't really part of a particular target_ops.
Considering multi-target, the core shouldn't have to ask all targets
to know whether it's GDB that owns the terminal. There's only one GDB
(or rather, only one top level interpreter).
So what this comment does is add a new global that is tracked by the
core instead. A subsequent pass may later remove the other globals.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* target.c (enum terminal_state): New enum.
(terminal_state): New global.
(target_terminal_init): New function.
(target_terminal_inferior): Skip if inferior already owns the
terminal.
(target_terminal_ours, target_terminal_ours_for_output): New
functions.
* target.h (target_terminal_init): Convert to function prototype.
(target_terminal_ours_for_output): Convert to function prototype
and tweak comment.
(target_terminal_ours): Convert to function prototype and tweak
comment.
* windows-nat.c (do_initial_windows_stuff): Call
target_terminal_init instead of child_terminal_init_with_pgrp.
This commit does most of the mechanical removal. IOW, the easy part.
procfs.c isn't touched beyond removing a couple obvious bits that are
guarded by a couple macros defined in config/alpha/nm-osf3.h. Going
beyond that for procfs.c & co would be a harder excision that
potentially affects Solaris.
Some comments in the generic alpha code ABIs that may still be
relevant and I wouldn't know what to do with them. That can always be
done on a separate pass, preferably by someone who can test on alpha.
A couple other spots have references to OSF/Tru64 and related files
being removed, but it felt like removing them would make things worse,
not better. We can revisit those when we next need to touch that
code.
I didn't remove a reference to osf in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=alpha-osf3 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration alpha-unknown-osf3 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `build-osf'
make: *** [all] Error 2
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_64_TARGET_OBS): Remove alpha-osf1-tdep.o.
(HFILES_NO_SRCDIR): Remove config/alpha/nm-osf3.h.
(ALLDEPFILES): Remove alpha-nat.c, alpha-osf1-tdep.c and
solib-osf.c.
* NEWS: Mention that support for alpha*-*-osf* has been removed.
* ada-lang.h [__alpha__ && __osf__]
(ADA_KNOWN_RUNTIME_FILE_NAME_PATTERNS): Delete.
* alpha-nat.c, alpha-osf1-tdep.c: Delete files.
* alpha-tdep.c (alpha_gdbarch_init): Remove reference to
GDB_OSABI_OSF1.
* config/alpha/alpha-osf3.mh, config/alpha/nm-osf3.h: Delete
files.
* config/djgpp/fnchange.lst (config/alpha/alpha-osf1.mh)
(config/alpha/alpha-osf2.mh, config/alpha/alpha-osf3.mh): Delete.
* configure: Regenerate.
* configure.ac: Remove references to osf.
* configure.host: Handle alpha*-*-osf* in the obsolete hosts
section. Remove all other references to osf.
* configure.tgt: Add alpha*-*-osf* to the obsolete targets section.
Remove all other references to osf.
* dec-thread.c: Delete file.
* defs.h (GDB_OSABI_OSF1): Delete.
* inferior.h (START_INFERIOR_TRAPS_EXPECTED): New unconditionally
defined.
* osabi.c (gdb_osabi_names): Delete "OSF/1".
* procfs.c (procfs_debug_inferior) [PROCFS_DONT_TRACE_FAULTS]:
Delete code.
(unconditionally_kill_inferior)
[PROCFS_NEED_CLEAR_CURSIG_FOR_KILL]: Delete code.
* solib-osf.c: Delete file.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.base/callfuncs.exp: emove references to osf.
* gdb.base/sigall.exp: Likewise.
* gdb.gdb/selftest.exp: Likewise.
* gdb.hp/gdb.base-hp/callfwmall.exp: Likewise.
* gdb.mi/non-stop.c: Likewise.
* gdb.mi/pthreads.c: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.threads/pthreads.c: Likewise.
* gdb.threads/pthreads.exp: Likewise.
gdb/doc/
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Ada Tasks and Core Files): Delete mention of Tru64.
(SVR4 Process Information): Delete mention of OSF/1.
clear_threads_listing_context is used for thread listing methods other
than the xml based, but it's only defined when HAVE_LIBEXPAT is defined.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* remote.c (clear_threads_listing_context): Move higher up, out of
the HAVE_LIBEXPAT guard.
I am confused by the noargs checking at each proc in commands.exp,
if [target_info exists noargs] {
verbose "Skipping progvar_simple_while_test because of noargs."
return
}
gdb_test_no_output "set args 5" "set args in progvar_simple_while_test"
if { ![runto factorial] } then { gdb_suppress_tests }
# Don't depend upon argument passing, since most simulators don't
# currently support it. Bash value variable to be what we want.
gdb_test "p value=5" ".*" "set value to 5 in progvar_simple_if_test #2"
They are conflicting to me. If the argument passing can't be done on
the target, we skip this test, why do we still have to set value below?
On the other hand, the test case is compiled with -DFAKEARGV, it doesn't
get anything from argv[1], why do we need to skip it if noargs is true?
I don't find any useful clues from the git log, as the code is quite
old, predating import to sourceware cvs. However, I find something
useful from the ChangeLog.
Thu Jul 20 13:28:36 1995 Jeffrey A. Law <law@rtl.cygnus.com>
.....
* gdb.base/commands.exp: Protect tests which need arguments with
$noargs conditionals.
Mon Apr 21 13:38:58 1997 Fred Fish <fnf@cygnus.com>
* gdb.base/run.c: Use FAKEARGV to build test executable that
does not require a command line arg, since most simulators
don't currently support passing such an arg into the simulated
program.
* gdb.base/commands.exp: Change tests to insert the proper
value as the arg to the first recursive factorial call. Change
compilation line to define FAKEARGV at compile time.
Jeff added noargs checking as argument is passed to the inferior. Then,
I presume Fred wanted to run this test on simulators which don't support
argument passing, and change the code not get input from argv. (I guess)
noargs wasn't set in simulator board files at that moment.
Since Fred changed test to set input by gdb, instead of getting input
from argv, the test should be able to run on target doesn't support
argument passing, such as simulator and gdbserver.
This patch is to remove these checks to noargs and "set args". I run
commands.exp with these board files, and no fail is found
- unix and native-gdbserver
- arm-none-eabi with qemu
- gdbserver on arm-linux-gnueabi with qemu
gdb/testsuite:
2014-10-17 Yao Qi <yao@codesourcery.com>
* gdb.base/commands.exp (gdbvar_complex_if_while_test): Don't check
'target_info exists noargs'.
(test_command_prompt_position): Likewise.
(progvar_simple_if_test): Don't check 'target_info exists noargs'.
Remove "set args".
(progvar_simple_while_test): Likewise.
(progvar_complex_if_while_test): Likewise.
(if_while_breakpoint_command_test): Likewise.
(infrun_breakpoint_command_test): Likewise.
(breakpoint_command_test): Likewise.
(watchpoint_command_test): Likewise.
(bp_deleted_in_command_test): Likewise.
(temporary_breakpoint_commands): Likewise.
Some Darwin kernels return values out of bounds for gs and fs segments.
With this commit, they are masked to avoid garbage.
gdb/ChangeLog:
* i386-darwin-nat.c (i386_darwin_fetch_inferior_registers)
(i386_darwin_store_inferior_registers): Sanitize gs and fs values
on amd64.
The condition [target_info exists noargs] is checked when
remotetimeout.exp was added
https://sourceware.org/ml/gdb-patches/2005-02/msg00052.html
noargs means GDB does not support argument passing for inferior,
rather than doesn't support argument passing to GDB. remotetimeout.exp
passes -l to GDB only, doesn't pass any arguments to the inferior.
This patch is to remove such unnecessary checking, and
remotetimeout.exp then can be run with native-gdbserver board file.
gdb/testsuite:
2014-10-16 Yao Qi <yao@codesourcery.com>
* gdb.base/remotetimeout.exp: Remove noargs checking.
Seems to me that we can simplify DEC thread's
target_update_thread_list implementation, avoiding the need to build
the array of GDB threads.
I have no way to test this, but then again support for Tru64 is about
to be removed.
Pushing anyway to have the last version in git be the cleanest one
should start from, if this file turns out to be resurrected in the
future.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* dec-thread.c (dec_thread_count_gdb_threads)
(dec_thread_add_gdb_thread): Delete.
(dec_thread_update_thread_list): Delete.
(dec_thread_find_new_threads): Rename to ...
(dec_thread_update_thread_list): ... this. Delete GDB-size
threads that are no longer found in dec_thread_list.
(resync_thread_list): Delete.
(dec_thread_wait): Call dec_thread_update_thread_list instead of
resync_thread_list.
This commit avoids the prune_threads call in the remote target's
target_update_thread_list's implementation, eliminating all the "thread
alive" RSP traffic (one packet per thread) whenever we fetch the
thread list.
IOW, this:
Sending packet: $Tp2141.2150#82...Packet received: OK
Sending packet: $Tp2141.214f#b7...Packet received: OK
Sending packet: $Tp2141.2141#82...Packet received: OK
... more T packets; it's one per previously known live thread ...
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n<thread id="p2141.2141" core="2"/>\n<thread id="p2141.214f" core="1"/>\n<thread id="p2141.2150" core="2"/>\n</threads>\n
Becomes:
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n<thread id="p2141.2141" core="2"/>\n<thread id="p2141.214f" core="1"/>\n<thread id="p2141.2150" core="2"/>\n</threads>\n
Tested on x86_64 Fedora 20, native gdbserver:
- tests the qXfer:threads:read method.
Tested on x86_64 Fedora 20, native gdbserver with qXfer:threads:read
force-disabled in gdbserver:
- So that GDB falls back to the qfThreadInfo/qsThreadInfo method.
And also manually smoked tested force disabling both
qXfer:threads:read and qfThreadInfo/qsThreadInfo in gdbserver.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): New macro.
* remote.c (remote_update_thread_list): Skip calling prune_threads
if any thread listing method is supported, and instead walk over
the set of remote threads listed, deleting those that are not
found in GDB's thread list.
When GDB wants to sync the thread list with the target's (e.g., due to
"info threads"), it calls update_thread_list:
update_thread_list (void)
{
prune_threads ();
target_find_new_threads ();
update_threads_executing ();
}
And then prune_threads does:
prune_threads (void)
{
struct thread_info *tp, *next;
for (tp = thread_list; tp; tp = next)
{
next = tp->next;
if (!thread_alive (tp))
delete_thread (tp->ptid);
}
}
Calling thread_live on each thread one by one is expensive.
E.g., on Linux, it ends up doing kill(SIG0) once for each thread. Not
a big deal, but still a bunch of syscalls...
With the remote target, it's cumbersome. That thread_alive call ends
up generating one T packet per thread:
Sending packet: $Tp2141.2150#82...Packet received: OK
Sending packet: $Tp2141.214f#b7...Packet received: OK
Sending packet: $Tp2141.2141#82...Packet received: OK
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n<thread id="p2141.2141" core="2"/>\n<thread id="p2141.214f" core="1"/>\n<thread id="p2141.2150" core="2"/>\n</threads>\n
That seems a bit silly when target_find_new_threads method
implementations will always fetch the whole current set of target
threads, and then add those that are not in GDB's thread list, to
GDB's thread list.
This patch thus pushes down the responsibility of pruning dead threads
to the target_find_new_threads method instead, so a target may
implement pruning dead threads however it wants.
Once we do that, target_find_new_threads becomes a misnomer, so the
patch renames it to target_update_thread_list.
The patch doesn't attempt to do any optimization to any target yet.
It simply exports prune_threads, and makes all implementations of
target_update_thread_list call that. It's meant to be a no-op.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* ada-tasks.c (print_ada_task_info, task_command_1): Adjust.
* bsd-uthread.c (bsd_uthread_find_new_threads): Rename to ...
(bsd_uthread_update_thread_list): ... this. Call prune_threads.
(bsd_uthread_target): Adjust.
* corelow.c (core_open): Adjust.
* dec-thread.c (dec_thread_find_new_threads): Update comment.
(dec_thread_update_thread_list): New function.
(init_dec_thread_ops): Adjust.
* gdbthread.h (prune_threads): New declaration.
* linux-thread-db.c (thread_db_find_new_threads): Rename to ...
(thread_db_update_thread_list): ... this. Call prune_threads.
(init_thread_db_ops): Adjust.
* nto-procfs.c (procfs_find_new_threads): Rename to ...
(procfs_update_thread_list): ... this. Call prune_threads.
(procfs_attach, procfs_create_inferior, init_procfs_targets):
Adjust.
* obsd-nat.c (obsd_find_new_threads): Rename to ...
(obsd_update_thread_list): ... this. Call prune_threads.
(obsd_add_target): Adjust.
* procfs.c (procfs_target): Adjust.
(procfs_notice_thread): Update comment.
(procfs_find_new_threads): Rename to ...
(procfs_update_thread_list): ... this. Call prune_threads.
* ravenscar-thread.c (ravenscar_update_inferior_ptid): Update
comment.
(ravenscar_wait): Adjust.
(ravenscar_find_new_threads): Rename to ...
(ravenscar_update_thread_list): ... this. Call prune_threads.
(init_ravenscar_thread_ops): Adjust.
* record-btrace.c (record_btrace_find_new_threads): Rename to ...
(record_btrace_update_thread_list): ... this. Adjust comment.
(init_record_btrace_ops): Adjust.
* remote.c (remote_threads_info): Rename to ...
(remote_update_thread_list): ... this. Call prune_threads.
(remote_start_remote, extended_remote_attach_1, init_remote_ops):
Adjust.
* sol-thread.c (check_for_thread_db): Adjust.
(sol_find_new_threads_callback): Rename to ...
(sol_update_thread_list_callback): ... this.
(sol_find_new_threads): Rename to ...
(sol_update_thread_list): ... this. Call prune_threads. Adjust.
(sol_get_ada_task_ptid, init_sol_thread_ops): Adjust.
* target-delegates.c: Regenerate.
* target.c (target_find_new_threads): Rename to ...
(target_update_thread_list): ... this.
* target.h (struct target_ops): Rename to_find_new_threads field
to to_update_thread_list.
(target_find_new_threads): Rename to ...
(target_update_thread_list): ... this.
* thread.c (prune_threads): Make extern.
(update_thread_list): Adjust.
We have three methods to list the current remote thread list:
1. The qXfer:threads:read method (the preferred one nowadays), builds a
remote thread list while parsing the XML, and then after the XML
parsing is done, goes over the built list and adds threads GDB doesn't
know about yet to GDB's list.
2. If the qXfer method isn't available, we fallback to using the
qfThreadInfo/qsThreadInfo packets. When we do this, we adds threads
to GDB's list immediately as we parse the qfThreadInfo/qsThreadInfo
packet replies.
3. And then if the previous method isn't available either, we try the
old deprecated qL packet. This path is already looking somewhat
broken for not using remote_notice_new_inferior to add threads to
GDB's list.
This patch makes all variants work in two passes, like the qXfer
method, and then makes all variants share the code path that adds
threads to GDB's list.
Tested on x86_64 Fedora 20 with native gdbserver.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* remote.c (remote_get_threadlist, remote_threadlist_iterator):
Add describing comment. Return -1 if the qL packet is not
supported.
(struct thread_item, thread_item_t): Move higher up in
the file. Add comments.
(struct threads_parsing_context): Move higher up in
the file, add comments, and remote to ...
(struct threads_listing_context): ... this.
(remote_newthread_step): Don't add the thread to GDB's thread
database here. Instead push it to the thread_listing_context
list.
(remote_find_new_threads): Rename to ...
(remote_get_threads_with_ql): ... this. Add target_ops and
targets_listing_context parameters. Pass down context.
(start_thread): Adjust.
(clear_threads_parsing_context): Rename to ...
(clear_threads_listing_context): ... this.
(remote_get_threads_with_qxfer): New, with parts salvaged from old
remote_threads_info.
(remote_get_threads_with_qthreadinfo): Ditto.
(remote_threads_info): Reimplement.
This finally reverts this bit of commit 929dfd4f:
2009-07-31 Pedro Alves <pedro@codesourcery.com>
Julian Brown <julian@codesourcery.com>
...
(resume): If this is a software single-stepping arch, and
displaced-stepping is enabled, use it for all single-step
requests.
...
That means that in non-stop (or really displaced-stepping) mode, on
software single-step archs - even those that only use sss breakpoints
to deal with atomic sequences, like PPC - if we have more than one
thread single-stepping, we'll always serialize the threads'
single-steps, as only one thread may be displaced stepping at a given
time, because there's only one scratch pad.
We originally did that because GDB didn't support having multiple
threads software-single-stepping simultaneously. The previous patches
fixed that limitation, so we can now finally revert this too.
Tested on:
- x86_64 Fedora 20, on top of the 'software single-step on x86'
series.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Don't force displaced-stepping for all
single-steps on software single-stepping archs.
This patch finally makes each thread have its own set of single-step
breakpoints. This paves the way to have multiple threads software
single-stepping, though this patch doesn't flip that switch on yet.
That'll be done on a subsequent patch.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (single_step_breakpoints): Delete global.
(insert_single_step_breakpoint): Adjust to store the breakpoint
pointer in the current thread.
(single_step_breakpoints_inserted, remove_single_step_breakpoints)
(cancel_single_step_breakpoints): Delete functions.
(breakpoint_has_location_inserted_here): Make extern.
(single_step_breakpoint_inserted_here_p): Adjust to walk the
breakpoint list.
* breakpoint.h (breakpoint_has_location_inserted_here): New
declaration.
(single_step_breakpoints_inserted, remove_single_step_breakpoints)
(cancel_single_step_breakpoints): Remove declarations.
* gdbthread.h (struct thread_control_state)
<single_step_breakpoints>: New field.
(delete_single_step_breakpoints)
(thread_has_single_step_breakpoints_set)
(thread_has_single_step_breakpoint_here): New declarations.
* infrun.c (follow_exec): Also clear the single-step breakpoints.
(singlestep_breakpoints_inserted_p, singlestep_ptid)
(singlestep_pc): Delete globals.
(infrun_thread_ptid_changed): Remove references to removed
globals.
(resume_cleanups): Delete the current thread's single-step
breakpoints.
(maybe_software_singlestep): Remove references to removed globals.
(resume): Adjust to use thread_has_single_step_breakpoints_set and
delete_single_step_breakpoints.
(init_wait_for_inferior): Remove references to removed globals.
(delete_thread_infrun_breakpoints): Delete the thread's
single-step breakpoints too.
(delete_just_stopped_threads_infrun_breakpoints): Don't delete
single-step breakpoints here.
(delete_stopped_threads_single_step_breakpoints): New function.
(adjust_pc_after_break): Adjust to use
thread_has_single_step_breakpoints_set.
(handle_inferior_event): Remove references to removed globals.
Use delete_stopped_threads_single_step_breakpoints.
(handle_signal_stop): Adjust to per-thread single-step
breakpoints. Swap test order to do cheaper tests first.
(switch_back_to_stepped_thread): Extend debug output. Remove
references to removed globals.
* record-full.c (record_full_wait_1): Adjust to per-thread
single-step breakpoints.
* thread.c (delete_single_step_breakpoints)
(thread_has_single_step_breakpoints_set)
(thread_has_single_step_breakpoint_here): New functions.
(clear_thread_inferior_resources): Also delete the thread's
single-step breakpoints.
A little refactoring to reduce duplicate code.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* thread.c (delete_thread_breakpoint): New function.
(delete_step_resume_breakpoint)
(delete_exception_resume_breakpoint): Use it.
(delete_at_next_stop): New function.
(clear_thread_inferior_resources): Use delete_at_next_stop.
There are no users of deprecated_{insert,remove}_raw_breakpoint left.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (regular_breakpoint_inserted_here_p): Inline ...
(breakpoint_inserted_here_p): ... here. Remove special case for
software single-step breakpoints.
(find_non_raw_software_breakpoint_inserted_here): Inline ...
(software_breakpoint_inserted_here_p): ... here. Remove special
case for software single-step breakpoints.
(bp_target_info_copy_insertion_state)
(deprecated_insert_raw_breakpoint)
(deprecated_remove_raw_breakpoint): Delete functions.
* breakpoint.h (deprecated_insert_raw_breakpoint)
(deprecated_remove_raw_breakpoint): Remove declarations.
This patch makes single-step breakpoints "real" breakpoints on the
global location list.
There are several benefits to this:
- It removes the currently limitation that only 2 single-step
breakpoints can be inserted. See an example here of a discussion
around a case that wants more than 2, possibly unbounded:
https://sourceware.org/ml/gdb-patches/2014-03/msg00663.html
- makes software single-step work on read-only code regions.
The logic to convert a software breakpoint to a hardware breakpoint
if the memory map says the breakpoint address is in read only memory
is in insert_bp_location. Because software single-step breakpoints
bypass all that go and straight to target_insert_breakpoint, we
can't software single-step over read only memory. This patch
removes that limitation, and adds a test that makes sure that works,
by forcing a code region to read-only with "mem LOW HIGH ro" and
then stepping through that.
- Fixes PR breakpoints/9649
This is an assertion failure in insert_single_step_breakpoint in
breakpoint.c, because we may leave stale single-step breakpoints
behind on error.
The tests for stepping through read-only regions exercise the root
cause of the bug, which is that we leave single-step breakpoints
behind if we fail to insert any single-step breakpoint. Deleting
the single-step breakpoints in resume_cleanups,
delete_just_stopped_threads_infrun_breakpoints, and
fetch_inferior_event fixes this. Without that, we'd no longer hit
the assertion, as that code is deleted, but we'd instead run into
errors/warnings trying to insert/remove the stale breakpoints on
next resume.
- Paves the way to have multiple threads software single-stepping at
the same time, leaving update_global_location_list to worry about
duplicate locations.
- Makes the moribund location machinery aware of software single-step
breakpoints, paving the way to enable software single-step on
non-stop, instead of forcing serialized displaced stepping for all
single steps.
- It's generaly cleaner.
We no longer have to play games with single-step breakpoints
inserted at the same address as regular breakpoints, like we
recently had to do for 7.8. See this discussion:
https://sourceware.org/ml/gdb-patches/2014-06/msg00052.html.
Tested on x86_64 Fedora 20, on top of my 'single-step breakpoints on
x86' series.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* breakpoint.c (single_step_breakpoints, single_step_gdbarch):
Delete array globals.
(single_step_breakpoints): New global.
(breakpoint_xfer_memory): Remove special handling for single-step
breakpoints.
(update_breakpoints_after_exec): Delete bp_single_step
breakpoints.
(detach_breakpoints): Remove special handling for single-step
breakpoints.
(breakpoint_init_inferior): Delete bp_single_step breakpoints.
(bpstat_stop_status): Add comment.
(bpstat_what, bptype_string, print_one_breakpoint_location)
(adjust_breakpoint_address, init_bp_location): Handle
bp_single_step.
(new_single_step_breakpoint): New function.
(set_momentary_breakpoint, bkpt_remove_location): Remove special
handling for single-step breakpoints.
(insert_single_step_breakpoint, single_step_breakpoints_inserted)
(remove_single_step_breakpoints, cancel_single_step_breakpoints):
Rewrite.
(detach_single_step_breakpoints, find_single_step_breakpoint):
Delete functions.
(breakpoint_has_location_inserted_here): New function.
(single_step_breakpoint_inserted_here_p): Rewrite.
* breakpoint.h: Remove FIXME.
(enum bptype) <bp_single_step>: New enum value.
(insert_single_step_breakpoint): Update comment.
* infrun.c (resume_cleanups)
(delete_step_thread_step_resume_breakpoint): Remove single-step
breakpoints.
(fetch_inferior_event): Install a cleanup that removes infrun
breakpoints.
(switch_back_to_stepped_thread) <expect thread advanced also>:
Clear step-over info.
gdb/testsuite/
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* gdb.base/breakpoint-in-ro-region.c (main): Add more instructions.
* gdb.base/breakpoint-in-ro-region.exp
(probe_target_hardware_step): New procedure.
(top level): Probe hardware stepping and hardware breakpoint
support. Test stepping through a read-only region, with both
"breakpoint auto-hw" on and off and both "always-inserted" on and
off.
This is a preparatory/cleanup patch that does two things:
- Renames 'delete_step_thread_step_resume_breakpoint'. The
"step_resume" part is misnomer these days, as the function deletes
other kinds of breakpoints, not just the step-resume breakpoint. A
following patch will want to make it delete yet another kind of
breakpoint, even.
- Splits out the logic of which threads get those breakpoints deleted
to a separate "for_each"-style function, so that the same following
patch may use it with a different callback.
Tested on x86_64 Fedora 20.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (delete_step_resume_breakpoint_callback): Delete.
(delete_thread_infrun_breakpoints): New function, with parts
salvaged from delete_step_resume_breakpoint_callback.
(delete_step_thread_step_resume_breakpoint): Delete.
(for_each_just_stopped_thread_callback_func): New typedef.
(for_each_just_stopped_thread): New function.
(delete_just_stopped_threads_infrun_breakpoints): New function.
(delete_step_thread_step_resume_breakpoint_cleanup): Rename to ...
(delete_just_stopped_threads_infrun_breakpoints_cleanup):
... this. Adjust.
(wait_for_inferior, fetch_inferior_event): Adjust to renames.
When GDB finds out the target triggered a watchpoint, and the target
has non-continuable watchpoints, GDB sets things up to step past the
instruction that triggered the watchpoint. This is just like stepping
past a breakpoint, but goes through a different mechanism - it resumes
only the thread that needs to step past the watchpoint, but also
switches a "infwait state" global, that has the effect that the next
target_wait only wait for events only from that thread.
This forcing of a ptid to pass to target_wait obviously becomes a
bottleneck if we ever support stepping past different watchpoints
simultaneously (in separate processes).
It's also unnecessary -- the target should only return events for
threads that have been resumed; if no other thread than the one we're
stepping past the watchpoint has been resumed, then those other
threads should not report events. If we couldn't assume that, then
stepping past regular breakpoints would be broken for not likewise
forcing a similar infwait_state.
So this patch eliminates infwait_state, and instead teaches keep_going
to mark step_over_info in a way that has the breakpoints module skip
inserting watchpoints (because we're stepping past one), like it skips
breakpoints when we're stepping past one.
Tested on:
- x86_64 Fedora 20 (continuable watchpoints)
- PPC64 Fedora 18 (non-steppable watchpoints)
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* breakpoint.c (should_be_inserted): Don't insert watchpoints if
trying to step past a non-steppable watchpoint.
* gdbthread.h (struct thread_info) <stepping_over_watchpoint>: New
field.
* infrun.c (struct step_over_info): Add new field
'nonsteppable_watchpoint_p' and adjust comments.
(set_step_over_info): New 'nonsteppable_watchpoint_p' parameter.
Adjust.
(clear_step_over_info): Clear nonsteppable_watchpoint_p as well.
(stepping_past_nonsteppable_watchpoint): New function.
(step_over_info_valid_p): Also return true if stepping past a
nonsteppable watchpoint.
(proceed): Adjust call to set_step_over_info. Remove reference to
init_infwait_state.
(init_wait_for_inferior): Remove reference to init_infwait_state.
(waiton_ptid): Delete global.
(struct execution_control_state)
<stepped_after_stopped_by_watchpoint>: Delete field.
(wait_for_inferior, fetch_inferior_event): Always pass
minus_one_ptid to target_wait.
(init_thread_stepping_state): Clear 'stepping_over_watchpoint'
field.
(init_infwait_state): Delete function.
(handle_inferior_event): Remove infwait_state handling.
(handle_signal_stop) <watchpoints handling>: Adjust after
stepped_after_stopped_by_watchpoint removal. Don't remove
breakpoints here nor set infwait_state. Set the thread's
stepping_over_watchpoint flag, and call keep_going instead.
(keep_going): Handle stepping_over_watchpoint. Adjust
set_step_over_info calls.
* infrun.h (stepping_past_nonsteppable_watchpoint): Declare
function.