No longer used since the non-continuable watchpoints handling rework.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* infrun.c (enum infwait_states, infwait_state): Delete.
The gdb.arch/i386-bp_permanent.exp test is currently failing an
assertion recently added:
(gdb) stepi
../../src/gdb/infrun.c:2237: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.arch/i386-bp_permanent.exp: Single stepping past permanent breakpoint. (GDB internal error)
The assertion expects that the only reason we currently need to step a
breakpoint instruction is when we have a signal to deliver. But when
stepping a permanent breakpoint (with or without a signal) we also
reach this code.
The assertion is correct and the permanent breakpoints skipping code
is wrong.
Consider the case of the user doing "step/stepi" when stopped at a
permanent breakpoint. GDB's `resume' calls the
gdbarch_skip_permanent_breakpoint hook and then happily continues
stepping:
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent
breakpoints can't be removed. So we have to test for it here. */
if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
{
gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
}
But since gdbarch_skip_permanent_breakpoint already advanced the PC
manually, this ends up executing the instruction that is _after_ the
breakpoint instruction. The user-visible result is that a single-step
steps two instructions.
The gdb.arch/i386-bp_permanent.exp test is actually ensuring that
that's indeed how things work. It runs to an int3 instruction, does
"stepi", and checks that "leave" was executed with that "stepi". Like
this:
(gdb) b *0x0804848c
Breakpoint 2 at 0x804848c
(gdb) c
Continuing.
Breakpoint 2, 0x0804848c in standard ()
(gdb) disassemble
Dump of assembler code for function standard:
0x08048488 <+0>: push %ebp
0x08048489 <+1>: mov %esp,%ebp
0x0804848b <+3>: push %edi
=> 0x0804848c <+4>: int3
0x0804848d <+5>: leave
0x0804848e <+6>: ret
0x0804848f <+7>: nop
(gdb) si
0x0804848e in standard ()
(gdb) disassemble
Dump of assembler code for function standard:
0x08048488 <+0>: push %ebp
0x08048489 <+1>: mov %esp,%ebp
0x0804848b <+3>: push %edi
0x0804848c <+4>: int3
0x0804848d <+5>: leave
=> 0x0804848e <+6>: ret
0x0804848f <+7>: nop
End of assembler dump.
(gdb)
One would instead expect that a stepi at 0x0804848c stops at
0x0804848d, _before_ the "leave" is executed. This commit changes GDB
this way. Care is taken to make stepping into a signal handler when
the step starts at a permanent breakpoint instruction work correctly.
The patch adjusts gdb.arch/i386-bp_permanent.exp in this direction,
and also makes it work on x86_64 (currently it only works on i*86).
The patch also adds a new gdb.base/bp-permanent.exp test that
exercises many different code paths related to stepping permanent
breakpoints, including the stepping with signals cases. The test uses
"hack/trick" to make it work on all (or most) platforms -- it doesn't
really hard code a breakpoint instruction.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Clear the thread's 'stepped_breakpoint' flag.
Rewrite stepping over a permanent breakpoint.
(thread_still_needs_step_over, proceed): Don't set
stepping_over_breakpoint for permanent breakpoints.
(handle_signal_stop): Don't clear stepped_breakpoint. Also pull
single-step breakpoints out of the target on hardware step
targets.
(process_event_stop_test): If stepping a permanent breakpoint
doesn't hit the step-resume breakpoint, delete the step-resume
breakpoint.
(switch_back_to_stepped_thread): Also check if the stepped thread
has advanced already on hardware step targets.
(currently_stepping): Return true if the thread stepped a
breakpoint.
gdb/testsuite/
2014-11-12 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-bp_permanent.c: New file.
* gdb.arch/i386-bp_permanent.exp: Don't skip on x86_64.
(srcfile): Set to i386-bp_permanent.c.
(top level): Adjust to work in both 32-bit and 64-bit modes. Test
that stepi does not execute the 'leave' instruction, instead of
testing it does execute.
* gdb.base/bp-permanent.c: New file.
* gdb.base/bp-permanent.exp: New file.
"permanent"-ness is currently a property of the breakpoint. But, it
should actually be an implementation detail of a _location_. Consider
this bit in infrun.c:
/* Normally, by the time we reach `resume', the breakpoints are either
removed or inserted, as appropriate. The exception is if we're sitting
at a permanent breakpoint; we need to step over it, but permanent
breakpoints can't be removed. So we have to test for it here. */
if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
{
if (gdbarch_skip_permanent_breakpoint_p (gdbarch))
gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
else
error (_("\
The program is stopped at a permanent breakpoint, but GDB does not know\n\
how to step past a permanent breakpoint on this architecture. Try using\n\
a command like `return' or `jump' to continue execution."));
}
This will wrongly skip a non-breakpoint instruction if we have a
multiple location breakpoint where the whole breakpoint was set to
"permanent" because one of the locations happened to be permanent,
even if the one GDB is resuming from is not.
Related, because the permanent breakpoints are only marked as such in
init_breakpoint_sal, we currently miss marking momentary breakpoints
as permanent. A test added by a following patch trips on that.
Making permanent-ness be per-location, and marking locations as such
in add_location_to_breakpoint, the natural place to do this, fixes
this issue...
... and then exposes a latent issue with mark_breakpoints_out. It's
clearing the inserted flag of permanent breakpoints. This results in
assertions failing like this:
Breakpoint 1, main () at testsuite/gdb.base/callexit.c:32
32 return 0;
(gdb) call callexit()
[Inferior 1 (process 15849) exited normally]
gdb/breakpoint.c:12854: internal-error: allegedly permanent breakpoint is not actually inserted
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The call dummy breakpoint, which is a momentary breakpoint, is set on
top of a manually inserted breakpoint instruction, and so is now
rightfully marked as a permanent breakpoint. See "Write a legitimate
instruction at the point where the infcall breakpoint is going to be
inserted." comment in infcall.c.
Re. make_breakpoint_permanent. That's only called by solib-pa64.c.
Permanent breakpoints were actually originally invented for HP-UX [1].
I believe that that call (the only one in the tree) is unnecessary
nowadays, given that nowadays the core breakpoints code analyzes the
instruction under the breakpoint to automatically detect whether it's
setting a breakpoint on top of a breakpoint instruction in the
program. I know close to nothing about HP-PA/HP-UX, though.
[1] https://sourceware.org/ml/gdb-patches/1999-q3/msg00245.html, and
https://sourceware.org/ml/gdb-patches/1999-q3/msg00242.html
In addition to the per-location issue, "permanent breakpoints" are
currently always displayed as enabled=='n':
(gdb) b main
Breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num Type Disp Enb Address What
3 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
But OTOH they're always enabled; there's no way to disable them...
In turn, this means that if one adds commands to such a breakpoint,
they're _always_ run:
(gdb) start
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
...
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29 int3
(gdb) b main
Breakpoint 2 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>echo "hello!"
>end
(gdb) disable 2
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29 int3
"hello!"(gdb)
IMO, one should be able to disable such a breakpoint, and GDB should
then behave just like if the user hadn't created the breakpoint in the
first place (that is, report a SIGTRAP).
By making permanent-ness a property of the location, and eliminating
the bp_permanent enum enable_state state ends up fixing that as well.
No tests are added for these changes yet; they'll be added in a follow
up patch, as skipping permanent breakpoints is currently broken and
trips on an assertion in infrun.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2014-11-12 Pedro Alves <palves@redhat.com>
Mark locations as permanent, not the whole breakpoint.
* breakpoint.c (remove_breakpoint_1, remove_breakpoint): Adjust.
(mark_breakpoints_out): Don't mark permanent breakpoints as
uninserted.
(breakpoint_init_inferior): Use mark_breakpoints_out.
(breakpoint_here_p): Adjust.
(bpstat_stop_status, describe_other_breakpoints): Remove handling
of permanent breakpoints.
(make_breakpoint_permanent): Mark each location as permanent,
instead of marking the breakpoint.
(add_location_to_breakpoint): If the location is permanent, mark
it as such, and as inserted.
(init_breakpoint_sal): Don't make the breakpoint permanent here.
(bp_location_compare, update_global_location_list): Adjust.
(update_breakpoint_locations): Don't make the breakpoint permanent
here.
(disable_breakpoint, enable_breakpoint_disp): Don't skip permanent
breakpoints.
* breakpoint.h (enum enable_state) <bp_permanent>: Delete field.
(struct bp_location) <permanent>: New field.
* guile/scm-breakpoint.c (bpscm_enable_state_to_string): Remove
reference to bp_permanent.
breakpoint.c uses gdbarch_breakpoint_from_pc to determine whether a
breakpoint location points at a permanent breakpoint:
static int
bp_loc_is_permanent (struct bp_location *loc)
{
...
addr = loc->address;
bpoint = gdbarch_breakpoint_from_pc (loc->gdbarch, &addr, &len);
...
if (target_read_memory (loc->address, target_mem, len) == 0
&& memcmp (target_mem, bpoint, len) == 0)
retval = 1;
...
So I think we should default the gdbarch_skip_permanent_breakpoint
hook to advancing the PC by the length of the breakpoint instruction,
as determined by gdbarch_breakpoint_from_pc. I believe that simple
implementation does the right thing for most architectures. If
there's an oddball architecture where that doesn't work, then it
should override the hook, just like it should be overriding the hook
if there was no default anyway.
The only two implementation of skip_permanent_breakpoint are
i386_skip_permanent_breakpoint, for x86, and
hppa_skip_permanent_breakpoint, for PA-RISC/HP-UX
The x86 implementation is trivial, and can clearly be replaced by the
new default.
I don't know about the HP-UX one though, I know almost nothing about
PA. It may well be advancing the PC ends up being equivalent.
Otherwise, it must be that "jump $pc_after_bp" doesn't work either...
Tested on x86_64 Fedora 20 native and gdbserver.
gdb/
2014-11-12 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_skip_permanent_breakpoint): New function.
* arch-utils.h (default_skip_permanent_breakpoint): New
declaration.
* gdbarch.sh (skip_permanent_breakpoint): Now an 'f' function.
Install default_skip_permanent_breakpoint as default method.
* i386-tdep.c (i386_skip_permanent_breakpoint): Delete function.
(i386_gdbarch_init): Don't install it.
* infrun.c (resume): Assume there's always a
gdbarch_skip_permanent_breakpoint implementation.
* gdbarch.h, gdbarch.c: Regenerate.
Linux supports multiple "PID namespaces". Processes in different PID
namespaces have different views of the system process list. Sometimes,
a single process can appear in more than one PID namespace, but with a
different PID in each. When GDB and its target are in different PID
namespaces, various features can break due to the mismatch between
what the target believes its PID to be and what GDB believes its PID
to be. The most visible broken functionality is thread enumeration
silently failing.
This patch explicitly warns users against trying to debug across PID
namespaces.
The patch introduced no new failures in my test suite run on an x86_64
installation of Ubuntu 14.10. It doesn't include a test: writing an
automated test that exercises this code would be very involved because
CLONE_NEWNS requires CAP_SYS_ADMIN; the easier way to reproduce the
problem is to start a new lxc container.
gdb/
2014-11-11 Daniel Colascione <dancol@dancol.org>
Warn about cross-PID-namespace debugging.
* nat/linux-procfs.h (linux_proc_pid_get_ns): New prototype.
* nat/linux-procfs.c (linux_proc_pid_get_ns): New function.
* linux-thread-db.c (check_pid_namespace_match): New function.
(thread_db_inferior_created): Call it.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
... instead of trap_expected.
Gets rid of one singlestep_breakpoints_inserted_p reference, and is
generally more to the point.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* infrun.c (step_over_info_valid_p): New function.
(resume): Use step_over_info_valid_p instead of checking the
threads's trap_expected flag.
gdb/ChangeLog:
* python/lib/gdb/__init__.py (packages): Add "printer".
* python/lib/gdb/command/bound_registers.py: Moved to ...
* python/lib/gdb/printer/bound_registers.py: ... here.
Add printer to global set of builtin printers. Rename printer from
"bound" to "mpx_bound128".
* python/lib/gdb/printing.py (_builtin_pretty_printers): New global,
registered as global "builtin" printer.
(add_builtin_pretty_printer): New function.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Update, and add
gdb/printer/__init__.py.
On 32-bit S390 targets the longjmp target address "naturally" has the
most significant bit set. That bit indicates the addressing mode and
is not part of the address itself. Thus, in analogy with similar
cases (like when computing the caller PC in
insert_step_resume_breakpoint_at_caller), this change removes
non-address bits from the longjmp target address before using it as a
breakpoint address.
Note that there are two ways for determining the longjmp target
address: via a probe or via a gdbarch method. This change only
affects the probe method, because it is assumed that the address
returned by the gdbarch method is usable as-is.
This change was tested together with a patch that enables longjmp
probes in glibc for S/390:
https://sourceware.org/ml/libc-alpha/2014-10/msg00277.html
gdb/ChangeLog:
* gdb/infrun.c (process_event_stop_test): Apply
gdbarch_addr_bits_remove to longjmp resume address.
This file:
- Isn't used by GDBserver currently.
- Isn't included in the WHICH list in features/Makefile, so hasn't
been regenerated to pick the latest microblaze or generic fixes.
Just delete it.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
* regformats/microblaze.dat: Delete file.
The Microblaze PC register is called "rpc", not "pc", as can be seen
in microblaze-core.xml. Fix this, so GDBserver can find the register in
the regcache.
gdb/
2014-10-15 Ajit Agarwal <ajitkum@xilinx.com>
* features/Makefile (microblaze-expedite): Replace pc with rpc.
* regformats/microblaze-with-stack-protect.dat: Regenerate.
Before this, a copy constructor declared as in the following snippet was
not being treated as a copy constructor.
class A
{
public:
A (A &); // OK.
A (const A &); // Not being treated as a copy constructor because of the
// 'const' qualifier.
};
gdb/ChangeLog:
PR c++/13403
PR c++/15154
* gnu-v3-abi.c (gnuv3_pass_by_reference): Lookup copy constructors
with qualified args.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:
(gdb) p something'address + 0
$1 = (system.address) 0x613418 <pck.something>
(gdb) p 0 + something'address
Argument to arithmetic operation not a number or boolean.
Same issue when doing subtractions:
(gdb) p something'address - 0
$2 = (system.address) 0x613418 <pck.something>
(gdb) p 0 - something'address
Argument to arithmetic operation not a number or boolean.
This patch enhances the Ada expression evaluator to handle
these two situations.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
of the case where the second operand is a pointer.
<BINOP_SUB>: Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/addr_arith: New testcase.
Tested on x86_64-linux.
This patch is a response to what I commented on:
<https://sourceware.org/ml/gdb-patches/2014-10/msg00046.html>
When reviewing Jose's USDT probe support patches. Basically, in his
patch he had to create dummy functions for the set_semaphore and the
clear_semaphore methods of probe_ops (gdb/probe.h), because those
functions were called inconditionally from inside gdb/breakpoint.c and
gdb/tracepoint.c. However, the semaphore concept may not apply to all
types of probes, and this is the case here: USDT probes do not have
semaphores (although SDT probes do).
Anyway, this is a simple (almost obvious) patch to guard the call to
{set,clear}_semaphore. It does not introduce any regression on a
Fedora 20 x86_64.
I will apply it in a few days in case there is no comment.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* breakpoint.c (bkpt_probe_insert_location): Call set_semaphore
only if it is not NULL.
(bkpt_probe_remove_location): Likewise, for clear_semaphore.
* probe.h (struct probe_ops) <set_semaphore>: Update comment.
(struct probe_ops) <clear_semaphore>: Likewise.
* tracepoint.c (start_tracing): Call set_semaphore only if it is
not NULL.
(stop_tracing): Likewise, for clear_semaphore.
Joel contacted me offlist with a question about a warning that one of
his customers was seeing. The message came from the new
linker-debugger interface, which uses SDT probes internally. The
warning said:
(gdb) run
[...]
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Argument to arithmetic operation not a number or boolean.
This should not have happened in the environment the customer was
using (RHEL-6.x), so I found it strange. Another thing caught my
attention: the last message, saying "Argument to arithmetic operation
not a number or boolean.".
Joel kindly investigated the issue further, and found the answer for
this. To quote him:
(gdb) set lang c
(gdb) p 48+$ebp
$4 = (void *) 0xffffd0f8
So far so good. But...
(gdb) set lang ada
(gdb) p 48+$ebp
Argument to arithmetic operation not a number or boolean.
Ooops! Interestingly, if you revert the order of the operands...
(gdb) p $ebp+48
$5 = (access void) 0xffffd0f8
So the problem is doing pointer arithmetics when the language is set
to Ada.
I remembered that, during the parsing and the evaluation of SDT probe
arguments, the code sets the language as current_language, because, at
that time, I thought it was not necessary to worry about the language
given that the code implements its own parser. I was wrong. So here
is a patch to fix that, by setting the language as C, which should
guarantee that the maths are done in the right way (TM).
It was somewhat hard to find a reproducer for this issue. In the end,
what I had to do was to create a testcase that used the %ebp register
on some displacement (e.g., "-4(%ebp)"), which finally triggered the
bug. I am not sure why I could not trigger it when using other
registers, but I did not want to spend too much time investigating
this issue, which seemed like an Ada issue. Also, because of this
peculiar way to trigger the problem, the testcase only covers x86-like
targets (i.e., i*86 and x86_64 with -m32).
Joel kindly tested this for me, and it worked. I also ran a full
regression test here on my Fedora 20 x86_64, and everything is fine.
I will push this patch in a few days if there are no comments.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_argument): Initialize expout explicitly
using language_c, instead of current_language.
gdb/testsuite/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/stap-eval-lang-ada.S: Likewise.
* gdb.arch/stap-eval-lang-ada.c: Likewise.
* gdb.arch/stap-eval-lang-ada.exp: New file.
gdb/ChangeLog:
* py-objfile.c (objfpy_initialize): New function.
(objfpy_new, objfile_to_objfile_object): Call it.
* py-progspace.c (pspy_initialize): New function.
(pspy_new, pspace_to_pspace_object): Call it.
gdb/ChangeLog
2014-10-13 Miroslav Franc <mfranc@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "save breakpoints" for "catch" command.
* break-catch-sig.c (signal_catchpoint_print_recreate): Add trailing
newline.
gdb/testsuite/ChangeLog
2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Yao Qi <yao@codesourcery.com>
Fix "save breakpoints" for "catch" command.
* gdb.base/catch-signal.exp: Add gdb_breakpoint "main".
Remove -nonewline. Match also the added "main" line.
This does most of the mechanical removal. IOW, the easy part.
This doesn't touch procfs.c as that'd be a harder excision,
potentially affecting Solaris.
mips-tdep.c is left alone. E.g., I didn't delete the GDB_OSABI_IRIX
enum value, nor references to it in mips-tdep.c. Some comments
mentioning IRIX ABIs may still be relevant and I wouldn't know what to
do with them. in That can always be done on a separate pass,
preferably by someone who can test on MIPS.
I didn't remove a reference to IRIX 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=mips-sgi-irix6 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 mips-sgi-irix6 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix'
make: *** [all] Error 2
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o.
(ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c.
(HFILES_NO_SRCDIR): Remove solib-irix.h.
* NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6*
and been removed.
* config/mips/irix5.mh, config/mips/irix6.mh: Delete files.
* configure.ac: Remove references to IRIX.
* configure.host: Add *-*-irix* to the obsolete hosts section.
Remove all other references to irix.
* irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h:
Delete files.
gdb/testsuite/
2014-10-10 Pedro Alves <palves@redhat.com>
* gdb.base/bigcore.exp: Remove references to IRIX.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/mips_pro.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/setvar.exp: Likewise.
* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
We currently validate the target description, but then forget to
reject it if found invalid.
Tested that incorrect descriptions are rejected and GDB warns about
them.
Tested the Microblaze Design with and without stack-protect registers.
The gdb command "info registers" displayed the register correctly. If
a stack protect design is not selected, only core registers are
displayed. When the stack-protect registers are selected in the
design, the core registers along with stack-protect registers are
displayed.
gdb/
2014-10-10 Ajit Agarwal <ajitkum@xilinx.com>
* microblaze-tdep.c (microblaze_gdbarch_init): If the description
isn't valid, release the tdesc arch data and return NULL.
We're now doing a vsyscall/vDSO address range lookup whenever we fetch
shared libraries, either through an explicit "info shared", or when
the target reports new libraries have been loaded, in order to filter
out the vDSO from glibc's DSO list. Before we started doing that, GDB
would only ever lookup the vsyscall's address range once in the
process's lifetime.
Looking up the vDSO address range requires an auxv lookup (which is
already cached, so no problem), but also reading the process's
mappings from /proc to find out the vDSO's mapping's size. That
generates extra RSP traffic when remote debugging. Particularly
annoying when the process's mappings grow linearly as more libraries
are mapped in, and we went through the trouble of making incremental
DSO list updates work against gdbserver (when the probes-based dynamic
linker interface is available).
The vsyscall/vDSO is mapped by the kernel when the process is
initially mapped in, and doesn't change throughout the process's
lifetime, so we can cache its address range.
Caching at this level brings GDB back to one and only one vsyscall
address range lookup per process.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* linux-tdep.c: Include observer.h.
(linux_inferior_data): New global.
(struct linux_info): New structure.
(invalidate_linux_cache_inf, linux_inferior_data_cleanup)
(get_linux_inferior_data): New functions.
(linux_vsyscall_range): Rename to ...
(linux_vsyscall_range_raw): ... this.
(linux_vsyscall_range): New function; handles caching.
(_initialize_linux_tdep): Register linux_inferior_data. Install
inferior_exit and inferior_appeared observers.
With upstream glibc, GDB prints:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
A bug's been filed for glibc a few years back:
http://sourceware.org/bugzilla/show_bug.cgi?id=13097
but it's still not resolved. It's not clear whether there's even
consensus that this is indeed a glibc bug. It would actually be nice
if GDB also listed the vDSO in the shared library list, but there are
some design considerations with that:
- the vDSO is mapped by the kernel, not userspace, therefore we
should load its symbols right from the process's start of life,
even before glibc / the userspace loader sets up the initial DSO
list. The program might even be using a custom loader or no
loader.
- that kind of hints at that solib.c should handle retrieving shared
library lists from more than one source, and that symfile-mem.c's
loading of the vDSO would be converted to load and relocate the
vDSO's bfd behind the target_so_ops interface.
- and then, once glibc links in the vDSO to its DSO list, we'd need
to either:
a) somehow hand over the vDSO from one target_so_ops to the other
b) simply keep hiding glibc's entry.
And then b) seems the simplest.
With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.
We can match the vDSO address range with the addresses found iterating
the dynamic linker list, to tell which dynamic linker entry is the
vDSO.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* solib-svr4.c (svr4_read_so_list): Rename to ...
(svr4_current_sos_1): ... this and change the function comment.
(svr4_current_sos): New function.
gdb/testsuite/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* gdb.base/vdso-warning.c: New file.
* gdb.base/vdso-warning.exp: New file.
We have a case in solib-svr4.c where we could reuse symfile-mem.c's
vDSO range lookup. Since symfile-mem.c is not present in all
configurations solib-svr4.c is, move that lookup to a gdbarch hook.
This has the minor (good) side effect that we stop even trying the
target_auxv_search lookup against targets that don't have a concept of
a vDSO, in case symfile-mem.c happens to be linked in the build
(--enable-targets=all).
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* arch-utils.c (default_vsyscall_range): New function.
* arch-utils.h (default_vsyscall_range): New declaration.
* gdbarch.sh (vsyscall_range): New hook.
* gdbarch.h, gdbarch.c: Regenerate.
* linux-tdep.c (linux_vsyscall_range): New function.
(linux_init_abi): Install linux_vsyscall_range as
vsyscall_range gdbarch hook.
* memrange.c (address_in_mem_range): New function.
* memrange.h (address_in_mem_range): New declaration.
* symfile-mem.c (find_vdso_size): Delete function.
(add_vsyscall_page): Use gdbarch_vsyscall_range.
This patch fixes the bug described in PR tdep/9390, which is about a
wrong check in the following code:
...
/* optional copying of args in r2-r7 to r10-r13. */
/* Probably only in optimized case but legal action for prologue. */
else if ((inst & 0xff00) == 0x4600 /* 46SD mov rD, rS */
&& (inst & 0x00f0) >= 0x0020 && (inst & 0x00f0) <= 0x0070
&& (inst & 0x000f) >= 0x00a0 && (inst & 0x000f) <= 0x000d)
^^^^^^^^^^^^^^^^^^^^^^^^^
...
This condition will never trigger, and the fix proposed in the bug
(which made sense to me) was to test against 0x000a. I tried finding
documentation about this target, but couldn't find anything. I don't
even know if it is still used, but decided to submit the fix anyway.
Tested on my x86_64 Fedora 20 GNU/Linux.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/9390
* xstorxstormy16-tdep.c (xstormy16_analyze_prologue): Fix possible
typo when using logical AND to determine instruction type.
As a result of commit b57bacec, local variable 'printed' is no longer
used. This patch is to remove it.
gdb:
2014-10-09 Yao Qi <yao@codesourcery.com>
* infrun.c (handle_signal_stop): Remove local variable 'printed'.
This commit makes fbsd-tdep.c not include string.h or gdb_assert.h
as both are already included by defs.h.
gdb/ChangeLog:
* fbsd-tdep.c: Do not include string.h or gdb_assert.h.
This commit includes common-exceptions.h in common-defs.h and removes
all other inclusions.
gdb/ChangeLog:
* common/common-defs.h: Include common-exceptions.h.
* exceptions.h: Do not include common-exceptions.h.
gdb/gdbserver/ChangeLog:
* server.h: Do not include common-exceptions.h.
This commit includes cleanups.h in common-defs.h and removes all other
inclusions.
gdb/ChangeLog:
* common/common-defs.h: Include cleanups.h.
* common/common-exceptions.c: Do not include cleanups.h.
* utils.h: Likewise.
gdb/gdbserver/ChangeLog:
* server.h: Do not include cleanups.h.
A helper function called `add_offset_16' is used by
`extended_mips16_next_pc' to calculate branch destinations. Weirdly
enough the helper does not do what the name suggests and rather than
doing its work for a 16-bit immediate branch offset it makes its
calculations on a 26-bit immediate target used by JAL and JALX
instructions. Furthermore the JAL/JALX calculation is only needed once
by `extended_mips16_next_pc' while a 16-bit branch offset calculation
is made inline several times across `extended_mips16_next_pc'.
This change therefore replaces the contents of `add_offset_16' with the
16-bit branch offset calculation and updates `extended_mips16_next_pc'
accordingly.
* mips-tdep.c (add_offset_16): Rewrite to implement what the
name implies.
(extended_mips16_next_pc): Update accordingly.
This change addresses a regression in gdb.dwarf2/dw2-skip-prologue.exp
across MIPS16 multilibs:
(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
Breakpoint 1 at 0x400721
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x00400725 to 0x00400721.
warning: Breakpoint 1 address previously adjusted from 0x00400725 to
0x00400721.
Breakpoint 1, 0x00400721 in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
warning: GDB can't find the start of the function at 0x4006dd.
GDB is unable to find the start of the function at 0x4006dd
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x4006dd for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
Program received signal SIGBUS, Bus error.
0x0040072b in main ()
(gdb) FAIL: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func
-- notice the breakpoint adjustment messages that are already a bad
sign. These happen when a breakpoint is requested in a branch delay
slot and are not supposed to happen unless explicitly requested with an
address pointing to a branch delay slot instruction. No symbol or line
debug information is supposed to direct GDB to place a breakpoint in a
delay slot.
Here's how `main' looks like:
00400718 <main>:
400718: 64f5 save 40,ra,s0-s1
40071a: 1a00 01a8 jal 4006a0 <func>
40071e: 0104 addiu s1,sp,16
400720: 1a00 01b7 jal 4006dc <func+0x3c>
400724: 6702 move s0,v0
400726: e049 addu v0,s0,v0
400728: 65b9 move sp,s1
40072a: 6473 restore 24,ra,s0-s1
40072c: e8a0 jrc ra
40072e: 6500 nop
-- so 0x400725 is the MIPS16 instruction address of the first MOVE
instruction seen above, in a delay slot of the preceding JAL instruction
indeed. This test case arranges for `main' to have no debug information
so it is one of the heuristic prologue scanners, `mips16_scan_prologue'
specifically in this case, that is responsible for finding the right
location for the breakpoint to place.
In this case the prologue really ends with the ADDIU instruction,
reordered into the delay slot of the first JAL instruction. Of course
we can't place the breakpoint for `main' after it as by doing so we'll
let `func' to be called before hitting this breakpoint. So the
breakpoint has to go at the JAL instruction instead, or 0x40071b.
To make a general case out of it we must never consider any jump or
branch instruction to be a part of a function's prologue. In the
presence of a jump or branch at the beginning of a function the furthest
instruction examined for the purpose of constructing frame information
can be one in the delay slot of that jump or branch if present, and
otherwise -- that is when the jump or branch is compact and has no delay
slot -- the instruction immediately preceding the jump or branch.
This change implements that approach across prologue scanners for the
three instruction ISAs. In implementing it I have factored out code
from the existing `*_instruction_has_delay_slot' handlers to be shared
and a side effect for the microMIPS implementation is it now always
fetches the second 16-bit halfword of 32-bit instructions even if it
eventually is not going to be needed. I think it's an acceptable
tradeoff for the purpose of code sharing.
To make things more consistent I also carried logic from
`micromips_scan_prologue' over to the other two scanners to accept (and
ignore) a single non-prologue non-control transfer instruction reordered
by the compiler into the prologue. While doing this I simplified the
exit path from the scan loop such that `end_prologue_addr' is set only
once. This made some concerns expressed in comments no longer
applicable, although even before they were not valid.
I have not fixed the logic around `load_immediate_bytes' in
`mips32_scan_prologue' though, it remains broken, although I took care
not to break it more. An approach similar to one taken for handling
larger stack adjustments in `micromips_scan_prologue' will have to be
eventually implemented here.
For regression testing I used my usual choice of the mips-linux-gnu
target and the following multilibs:
-EB
-EB -msoft-float
-EB -mips16
-EB -mips16 -msoft-float
-EB -mmicromips
-EB -mmicromips -msoft-float
-EB -mabi=n32
-EB -mabi=n32 -msoft-float
-EB -mabi=64
-EB -mabi=64 -msoft-float
and the -EL variants of same.
That removed gdb.dwarf2/dw2-skip-prologue.exp failures across MIPS16
multilibs, the test log now shows:
(gdb) file .../gdb.dwarf2/dw2-skip-prologue
Reading symbols from .../gdb.d/gdb.dwarf2/dw2-skip-prologue...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x40071b
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, 0x0040071b in main ()
(gdb) break func
Breakpoint 2 at 0x4006a1: func. (2 locations)
(gdb) continue
Continuing.
Breakpoint 2, func (param=0) at main.c:5
5 This program is free software; you can redistribute it and/or modify
(gdb) PASS: gdb.dwarf2/dw2-skip-prologue.exp: continue to breakpoint: func
-- so things look like intended.
That also did regress, again across MIPS16 multilibs, another test case,
gdb.base/step-symless.exp:
(gdb) file .../gdb.d/gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x4006d3
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, 0x004006d3 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
warning: GDB can't find the start of the function at 0x4006b9.
GDB is unable to find the start of the function at 0x4006b9
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x4006b9 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
0x004006b9 in ?? ()
(gdb) FAIL: gdb.base/step-symless.exp: step
-- but that is actually a good sign. Here `main', again, has no debug
information and code involved looks like:
004006a0 <symful>:
4006a0: 6491 save 8,s1
4006a2: 673d move s1,sp
4006a4: b204 lw v0,4006b4 <symful+0x14>
4006a6: 9a40 lw v0,0(v0)
4006a8: 4261 addiu v1,v0,1
4006aa: b203 lw v0,4006b4 <symful+0x14>
4006ac: da60 sw v1,0(v0)
4006ae: 65b9 move sp,s1
4006b0: 6411 restore 8,s1
4006b2: e8a0 jrc ra
4006b4: 0041 addiu s0,sp,260
4006b6: 0860 la s0,400834 <__libc_start_main@mips16plt+0x54>
4006b8: 6491 save 8,s1
4006ba: 673d move s1,sp
4006bc: b204 lw v0,4006cc <symful+0x2c>
4006be: 9a40 lw v0,0(v0)
4006c0: 4261 addiu v1,v0,1
4006c2: b203 lw v0,4006cc <symful+0x2c>
4006c4: da60 sw v1,0(v0)
4006c6: 65b9 move sp,s1
4006c8: 6411 restore 8,s1
4006ca: e8a0 jrc ra
4006cc: 0041 addiu s0,sp,260
4006ce: 0860 la s0,40084c <__libc_start_main@mips16plt+0x6c>
004006d0 <main>:
4006d0: 64d4 save 32,ra,s1
4006d2: 1a00 01ae jal 4006b8 <symful+0x18>
4006d6: 0104 addiu s1,sp,16
4006d8: 1a00 01a8 jal 4006a0 <symful>
4006dc: 6500 nop
4006de: 6740 move v0,zero
4006e0: 65b9 move sp,s1
4006e2: 6452 restore 16,ra,s1
4006e4: e8a0 jrc ra
4006e6: 6500 nop
4006e8: 6500 nop
4006ea: 6500 nop
4006ec: 6500 nop
4006ee: 6500 nop
-- and the original log:
(gdb) file .../gdb.base/step-symless
Reading symbols from .../gdb.base/step-symless...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
Breakpoint 1 at 0x4006d9
(gdb) set remotetimeout 5
(gdb) kill
The program is not being run.
(gdb)
[...]
target remote ...:2345
Reading symbols from .../mips16/lib/ld.so.1...done.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
0x2aaa8e81 in __start () from .../mips16/lib/ld.so.1
(gdb) continue
Continuing.
warning: Breakpoint address adjusted from 0x004006dd to 0x004006d9.
warning: Breakpoint 1 address previously adjusted from 0x004006dd to
0x004006d9.
Breakpoint 1, 0x004006d9 in main ()
(gdb) break symful
Breakpoint 2 at 0x4006a5
(gdb) step
Single stepping until exit from function main,
which has no line number information.
Breakpoint 2, 0x004006a5 in symful ()
(gdb) PASS: gdb.base/step-symless.exp: step
So the breakpoint at `main' was actually set at an instruction after the
call to `symful+0x18' aka `symless' and the test only passed because
single-stepping through `symless' wasn't actually done at all. With
this change in place this test fails for MIPS16 multilibs consistently
with all the other multilibs where it already failed in this manner
previously.
* mips-tdep.c (mips16_instruction_is_compact_branch): New
function.
(micromips_instruction_is_compact_branch): Likewise.
(mips16_scan_prologue): Terminate scanning upon seeing a branch
or a compact jump, reaching a jump delay slot, or seeing a
second non-prologue instruction.
(micromips_scan_prologue): Also terminate scanning upon seeing a
compact branch or jump, or reaching a branch or jump delay slot.
(mips32_scan_prologue): Terminate scanning upon reaching a branch
or jump delay slot, or seeing a second non-prologue instruction.
(mips32_instruction_has_delay_slot): Retain instruction
examination code only, update arguments accordingly and move
instruction fetch pieces to...
(mips32_insn_at_pc_has_delay_slot): ... this new function.
(micromips_instruction_has_delay_slot): Likewise and to...
(micromips_insn_at_pc_has_delay_slot): ... this new function.
(mips16_instruction_has_delay_slot): Likewise and to...
(mips16_insn_at_pc_has_delay_slot): ... this new function.
(mips_single_step_through_delay): Update accordingly.
(mips_adjust_breakpoint_address): Likewise.
This change addresses `micromips_instruction_has_delay_slot' and
`mips16_instruction_has_delay_slot' that both incorrectly interpret
their MUSTBE32 argument. Their callers assume that when the flag is
clear these functions will return 1 when any non-compact jump or branch
instruction is present at ADDR, while in fact they will only return 1
for 16-bit such instructions only. This change makes the implementation
match the expectations.
* mips-tdep.c (micromips_instruction_has_delay_slot): When
!mustbe32 also return 1 for 32-bit instructions.
(mips16_instruction_has_delay_slot): Likewise. Add an
explanatory comment.
In installing minimal symbols for ELF shared library trampolines
we "forget" to make individual symbols special where required. This
leads to problems on the MIPS target using microMIPS SVR4 lazy stubs.
Lacking the special annotation these stubs are treated as standard
MIPS code and this makes GDB insert the wrong software breakpoint
instruction, breaking e.g. single-stepping through these stubs. This
is not a very frequent scenario as microMIPS SVR4 lazy stubs are
typically only used in shared libraries with the main executable
using PLT, handled elsewhere. Still it triggers e.g. when a software
watchpoint has been installed. The symptom is SIGILL or the program
going astray, depending on the endianness. Disassembly of these stubs
is also wrong.
* elfread.c (elf_symtab_read): Also mark solib trampoline minimal
symbols special.
This change:
commit b775012e84
Author: Luis Machado <luisgpm@br.ibm.com>
Date: Fri Feb 24 15:10:59 2012 +0000
2012-02-24 Luis Machado <lgustavo@codesourcery.com>
* remote.c (remote_supports_cond_breakpoints): New forward
declaration.
[...]
changed the way breakpoints are inserted and removed such that
`insert_bp_location' can now be called with the breakpoint being handled
already in place, while previously the call was only ever made for
breakpoints that have not been put in place. This in turn caused an
issue for software breakpoints and targets for which a breakpoint's
`placed_address' may not be the same as the original requested address.
The issue is `insert_bp_location' overwrites the previously adjusted
value in `placed_address' with the original address, that is only
replaced back with the correct adjusted address later on when
`gdbarch_breakpoint_from_pc' is called. Meanwhile there's a window
where the value in `placed_address' does not correspond to data stored
in `shadow_contents', leading to incorrect instruction bytes being
supplied when `one_breakpoint_xfer_memory' is called to supply the
instruction overlaid by the breakpoint.
And this is exactly what happens on the MIPS target with software
breakpoints placed in microMIPS code. In this case not only
`placed_address' is not the original address because of the ISA bit, but
`mips_breakpoint_from_pc' has to read the original instruction to
determine which one of the two software breakpoint instruction encodings
to choose as well. The 16-bit encoding is used to replace 16-bit
instructions and similarly the 32-bit one is used with 32-bit
instructions, to satisfy branch delay slot size requirements.
The mismatch between `placed_address' and the address data in
`shadow_contents' has been obtained from leads to the wrong encoding
being used in some cases, which in the case of a 32-bit software
breakpoint instruction replacing a 16-bit instruction causes corruption
to the adjacent following instruction and leads the debug session astray
if execution reaches there e.g. with a jump.
To address this problem I made the change below, that adds a
`reqstd_address' field to `struct bp_target_info' and leaves
`placed_address' unchanged once it has been set. This ensures data in
`shadow_contents' is always consistent with `placed_address'.
This approach also has this good side effect that all the places that
examine the breakpoint's address see a consistent value, either
`reqstd_address' or `placed_address', as required. Currently some
places see either the original or the adjusted address in
`placed_address', depending on whether they have been called before
`gdbarch_remote_breakpoint_from_pc' or afterwards. This is in
particular true for subsequent calls to
`gdbarch_remote_breakpoint_from_pc' itself, e.g. from
`one_breakpoint_xfer_memory'. This is also important for places like
`find_single_step_breakpoint' where a breakpoint's address is compared
to the raw value of $pc.
* breakpoint.h (bp_target_info): Add `reqstd_address' member,
update comments.
* breakpoint.c (one_breakpoint_xfer_memory): Use `reqstd_address'
for the breakpoint's address. Don't preinitialize `placed_size'.
(insert_bp_location): Set `reqstd_address' rather than
`placed_address'.
(bp_target_info_copy_insertion_state): Also copy `placed_address'.
(bkpt_insert_location): Use `reqstd_address' for the breakpoint's
address.
(bkpt_remove_location): Likewise.
(deprecated_insert_raw_breakpoint): Likewise.
(deprecated_remove_raw_breakpoint): Likewise.
(find_single_step_breakpoint): Likewise.
* mem-break.c (default_memory_insert_breakpoint): Use
`reqstd_address' for the breakpoint's address. Don't set
`placed_address' or `placed_size' if breakpoint contents couldn't
have been determined.
* remote.c (remote_insert_breakpoint): Use `reqstd_address' for
the breakpoint's address.
(remote_insert_hw_breakpoint): Likewise. Don't set
`placed_address' or `placed_size' if breakpoint couldn't have been
set.
* aarch64-linux-nat.c (aarch64_linux_insert_hw_breakpoint): Use
`reqstd_address' for the breakpoint's address.
* arm-linux-nat.c (arm_linux_hw_breakpoint_initialize): Likewise.
* ia64-tdep.c (ia64_memory_insert_breakpoint): Likewise.
* m32r-tdep.c (m32r_memory_insert_breakpoint): Likewise.
* microblaze-linux-tdep.c
(microblaze_linux_memory_remove_breakpoint): Likewise.
* monitor.c (monitor_insert_breakpoint): Likewise.
* nto-procfs.c (procfs_insert_breakpoint): Likewise.
(procfs_insert_hw_breakpoint): Likewise.
* ppc-linux-nat.c (ppc_linux_insert_hw_breakpoint): Likewise.
* ppc-linux-tdep.c (ppc_linux_memory_remove_breakpoint): Likewise.
* remote-m32r-sdi.c (m32r_insert_breakpoint): Likewise.
* remote-mips.c (mips_insert_breakpoint): Likewise.
* x86-nat.c (x86_insert_hw_breakpoint): Likewise.
On MIPS64 little endian, attempting an assignment to a bit field
that lives in a register yields the wrong result. It just corrupts
the data in the register depending on the specific position of the
bit field inside the structure.
FAIL: gdb.base/store.exp: f_1.j
FAIL: gdb.base/store.exp: f_1.k
FAIL: gdb.base/store.exp: F_1.i
FAIL: gdb.base/store.exp: F_1.j
FAIL: gdb.base/store.exp: F_1.k
FAIL: gdb.base/store.exp: f_2.j
FAIL: gdb.base/store.exp: f_2.k
FAIL: gdb.base/store.exp: F_2.i
FAIL: gdb.base/store.exp: F_2.j
FAIL: gdb.base/store.exp: F_2.k
FAIL: gdb.base/store.exp: f_3.j
FAIL: gdb.base/store.exp: f_3.k
FAIL: gdb.base/store.exp: F_3.i
FAIL: gdb.base/store.exp: F_3.j
FAIL: gdb.base/store.exp: F_3.k
FAIL: gdb.base/store.exp: f_4.j
FAIL: gdb.base/store.exp: f_4.k
FAIL: gdb.base/store.exp: F_4.i
FAIL: gdb.base/store.exp: F_4.j
FAIL: gdb.base/store.exp: F_4.k
=== gdb Summary ===
Now, GDB knows how to do bit field assignment properly, but MIPS is
one of those architectures that uses a hook for the register-to-value
conversion. Although we can properly tell when the type being passed
is a structure or union, we cannot tell when it is a bit field,
because the bit field data lives in a value structure. Such data
only lives in a "type" structure when the parent structure is being
referenced, thus you can collect them from the flds_bnds members.
A bit field type structure looks pretty much the same as any other
primitive type like int or char, so we can't distinguish them.
Forcing more fields into the type structure wouldn't help much,
because the type structs are shared.
2014-10-03 Luis Machado <lgustavo@codesourcery.com>
* valops.c (value_assign): Check for bit field assignments
before calling architecture-specific register value
conversion functions.
Trying to debug gdb with itself,
I stumbled on the following complaints
Unknown symbol type 0x2e
or
Unknown symbol type 0x4e
It appears that those corrspond to N_BNSYM and N_ENSYM,
which are MacOS extensions of stabs debugging format.
But these extensions have been used inside gcc probalby
for a while already, see:
https://gcc.gnu.org/ml/gcc/2004-08/msg00157.html
As the only purpose of these entries is to allow for removal
of stabs information if the function is removed,
it can be safely ignored by GDB.
This patch simply adds those two entry types to the list
of ignored entry type in read_dbx_symtab function.
Is this OK?
Pierre Muller
2014-10-03 Pierre Muller <muller@sourceware.org>
* dbxread.c (read_dbx_symtab): Also ignore N_BNSYM/N_ENSYM.
Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove
"breakpoint always-inserted auto") regressed non-stop remote
debugging.
This was exposed by mi-nsintrall.exp intermittently failing with a
spurious SIGTRAP.
The problem is that when debugging with "target remote", new threads
the target has spawned but have never reported a stop aren't visible
to GDB until it explicitly resyncs its thread list with the target's.
For example, in a program like this:
int
main (void)
{
pthread_t child_thread;
pthread_create (&child_thread, NULL, child_function, NULL);
return 0; <<<< set breakpoint here
}
If the user sets a breakpoint at the "return" statement, and runs the
program, when that breakpoint hit is reported, GDB is only aware of
the main thread. So if we base the decision to remove or insert
breakpoints from the target based on whether all the threads we know
about are stopped, we'll miss that child_thread is running, and thus
we'll remove breakpoints from the target, even through they should
still remain inserted, otherwise child_thread will miss them.
The break-while-running.exp test actually should also be exposing this
thread-list-out-of-synch problem. That test sets a breakpoint while
the main thread is stopped, but other threads are running. Because
other threads are running, the breakpoint is supposed to be inserted
immediately. But, unless something forces a refetch of the thread
list, like, e.g., "info threads", GDB won't be aware of the other
threads that had been spawned by the main thread, and so won't insert
new or old breakpoints in the target. And it turns out that the test
is exactly doing an explicit "info threads", masking out the
problem... This commit adjust the test to exercise the case of not
issuing "info threads". The test then fails without the GDB fix.
In the ni-nsintrall.exp case, what happens is that several threads hit
the same breakpoint, and when the first thread reports the stop,
because GDB wasn't aware other threads exist, all threads known to GDB
are found stopped, so GDB removes the breakpoints from the target.
The other threads follow up with SIGTRAPs too for that same
breakpoint, which has already been removed. For the first few
threads, the moribund breakpoints machinery suppresses the SIGTRAPs,
but after a few events (precisely '3 * thread_count () + 1' at the
time the breakpoint was removed, see update_global_location_list), the
moribund breakpoint machinery is no longer aware of the removed
breakpoint, and the SIGTRAP is reported as a spurious stop.
The fix is naturally then to stop assuming that if no thread in the
list is executing, then the target is fully stopped. We can't know
that until we fully sync the thread list. Because updating the thread
list on every stop would be too much RSP traffic, I chose instead to
update it whenever we're about to present a stop to the user.
Actually updating the thread list at that point happens to be an item
I had added to the local/remote parity wiki page a while ago:
Native GNU/Linux debugging adds new threads to the thread list as
the program creates them "The [New Thread foo] messages". Remote
debugging can't do that, and it's arguable whether we shouldn't even
stop native debugging from doing that, as it hinders inferior
performance. However, a related issue is that with remote targets
(and gdbserver), even after the program stops, the user still needs
to do "info threads" to pull an updated thread list. This, should
most likely be addressed, so that GDB pulls the list itself, perhaps
just before presenting a stop to the user.
With that in place, the need to delay "Program received signal FOO"
was actually caught by the manythreads.exp test. Without that bit, I
was getting:
[Thread 0x7ffff7f13700 (LWP 4499) exited]
[New Thread 0x7ffff7f0b700 (LWP 4500)]
^C
Program received signal SIGINT, Interrupt.
[New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output
[Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
__GI___nptl_death_event () at events.c:31
31 {
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
That is, I was now getting "New Thread" lines after the "Program
received signal" line, and the test doesn't expect them. As the
number of new threads discovered before and after the "Program
received signal" output is unbounded, it's much nicer to defer
"Program received signal" until after synching the thread list, thus
close to the "switching to thread" output and "current frame/source"
info:
[Thread 0x7ffff7863700 (LWP 7647) exited]
^C[New Thread 0x7ffff786b700 (LWP 7648)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
__GI___nptl_create_event () at events.c:25
25 {
(gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoints_should_be_inserted_now): Use
threads_are_executing.
* breakpoint.h (breakpoints_should_be_inserted_now): Add
describing comment.
* gdbthread.h (threads_are_executing): Declare.
(handle_signal_stop) <random signals>: Don't print about the
signal here if stopping.
(end_stepping_range): Don't notify observers here.
(normal_stop): Update the thread list. If stopped by a random
signal or a stepping range ended, notify observers.
* thread.c (threads_executing): New global.
(init_thread_list): Clear 'threads_executing'.
(set_executing): Set or clear 'threads_executing'.
(threads_are_executing): New function.
(update_threads_executing): New function.
(update_thread_list): Use it.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp (test): Add new
'update_thread_list' argument. Skip "info threads" if false.
(top level): Add new 'update_thread_list' axis.
Following an exec with "breakpoint always-inserted on" tries to insert
breakpoints in the new image at the addresses the symbols had in the
old image.
With "always-inserted off", we see:
gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off"
GNU gdb (GDB) 7.8.50.20140924-cvs
...
(gdb) b main
Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24.
^^^^^^^^
(gdb) c
The program is not being run.
(gdb) r
Starting program: testsuite/gdb.multi/multi-arch-exec
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
process 9212 is executing new program: gdb/testsuite/gdb.multi/multi-arch-exec-hello
Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40
40 bar();
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080484e4 in main at gdb/testsuite/gdb.multi/hello.c:40
^^^^^^^^^^
breakpoint already hit 2 times
(gdb)
Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in
gdb.multi/hello.
With "always-inserted on", we get:
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
infrun: target_wait (-1, status) =
infrun: 9444 [process 9444],
infrun: status->kind = execd
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_EXECD
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400664
(gdb)
That is, GDB is trying to insert a breakpoint at 0x400664, after the
exec, and then that address happens to not be mapped at all in the new
image.
The problem is that update_breakpoints_after_exec is creating
breakpoints, which ends up in update_global_location_list immediately
inserting breakpoints if "breakpoints always-inserted" is "on".
update_breakpoints_after_exec is called very early when we see an exec
event. At that point, we haven't loaded the symbols of the new
post-exec image yet, and thus haven't reset breakpoint's addresses to
whatever they may be in the new image. All we should be doing in
update_breakpoints_after_exec is deleting breakpoints that no longer
make sense after an exec. So the fix removes those breakpoint
creations.
The question is then, if not here, where are those breakpoints
re-created? Turns out we don't need to do anything else, because at
the end of follow_exec, we call breakpoint_re_set, whose tail is also
creating exactly the same breakpoints update_breakpoints_after_exec is
currently creating:
breakpoint_re_set (void)
{
...
create_overlay_event_breakpoint ();
create_longjmp_master_breakpoint ();
create_std_terminate_master_breakpoint ();
create_exception_master_breakpoint ();
}
A new test is added to exercise this.
Tested on x86_64 Fedora 20.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* breakpoint.c (update_breakpoints_after_exec): Don't create
overlay, longjmp, std terminate nor exception breakpoints here.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* gdb.base/execl-update-breakpoints.c: New file.
* gdb.base/execl-update-breakpoints.exp: New file.
A patch I wrote made GDB pull the thread list sooner when debugging
with target remote, and I noticed an intended consequence. GDB
started bouncing around the currently selected remote/general thread
more frequently. E.g.:
Sending packet: $qTMinFTPILen#3b...Packet received: 5
+Sending packet: $Hgp726d.726d#53...Packet received: OK
Sending packet: $m400680,40#2f...Packet received: 85c0741455bff00d60004889e5ffd05de97bffffff0f1f00e973ffffff0f1f00554889e5c745fc00000000c745fc01000000e900000000c745fc02000000b800
+Sending packet: $Hgp726d.7278#28...Packet received: OK
Sending packet: $m4006b2,1#28...Packet received: e9
Fast tracepoint 2 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
This ended up breaking "tstart" when one has fast tracepoints set,
because gdbserver isn't expecting an Hg packet in response to
qRelocInsn:
(gdb) ftrace *set_point
Fast tracepoint 3 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
(gdb) PASS: gdb.trace/range-stepping.exp: ftrace: ftrace *set_point
tstart
gdbserver: Malformed response to qRelocInsn, ignoring: Hgp2783.2783
Target does not support this command.
(gdb) FAIL: gdb.trace/range-stepping.exp: ftrace: tstart
remote_trace_start should probably start by making sure the remote
current thread matches inferior_ptid (calling set_general_thread), but
still, reducing unnecessary bouncing is a good idea. It happens
because the memory/symbol/breakpoint routines use
switch_to_program_space_and_thread to do something in the right
context and then revert back to the previously current thread.
The fix is to simply make any_thread_of_process,
find_inferior_for_program_space, etc. give preference to the current
thread/inferior it if matches.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdbthread.h (any_thread_of_process, any_live_thread_of_process):
Adjust comments.
* inferior.c (find_inferior_for_program_space): Give preference to
the current inferior.
* inferior.h (find_inferior_for_program_space): Update comment.
* progspace.c (switch_to_program_space_and_thread): Prefer the
current inferior if it's bound to the program space requested. If
the inferior found doesn't have a PID yet, don't bother looking up
a thread.
* progspace.h (switch_to_program_space_and_thread): Adjust
comment.
* thread.c (any_thread_of_process, any_live_thread_of_process):
Give preference to the current thread.
Currently, with "set breakpoint auto-hw off", we'll still try to
insert a software breakpoint at addresses covered by supposedly
read-only or inacessible regions:
(top-gdb) mem 0x443000 0x450000 ro
(top-gdb) set mem inaccessible-by-default off
(top-gdb) disassemble
Dump of assembler code for function main:
0x0000000000443956 <+34>: movq $0x0,0x10(%rax)
=> 0x000000000044395e <+42>: movq $0x0,0x18(%rax)
0x0000000000443966 <+50>: mov -0x24(%rbp),%eax
0x0000000000443969 <+53>: mov %eax,-0x20(%rbp)
End of assembler dump.
(top-gdb) b *0x0000000000443969
Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29.
(top-gdb) c
Continuing.
warning: cannot set software breakpoint at readonly address 0x443969
Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29
29 args.argc = argc;
(top-gdb)
We warn, saying that the insertion can't be done, but then proceed
attempting the insertion anyway, and in case of manually added
regions, the insert actually succeeds.
This is a regression; GDB used to fail inserting the breakpoint. More
below.
I stumbled on this as I wrote a test that manually sets up a read-only
memory region with the "mem" command, in order to test GDB's behavior
with breakpoints set on read-only regions, even when the real memory
the breakpoints are set at isn't really read-only. I wanted that in
order to add a test that exercises software single-stepping through
read-only regions.
Note that the memory regions that target_memory_map returns aren't
like e.g., what would expect to see in /proc/PID/maps on Linux.
Instead, they're the physical memory map from the _debuggers_
perspective. E.g., a read-only region would be real ROM or flash
memory, while a read-only+execute mapping in /proc/PID/maps is still
read-write to the debugger (otherwise the debugger wouldn't be able to
set software breakpoints in the code segment).
If one tries to manually write to memory that falls within a memory
region that is known to be read-only, with e.g., "p foo = 1", then we
hit a check in memory_xfer_partial_1 before the write mananges to make
it to the target side.
But writing a software/memory breakpoint nowadays goes through
target_write_raw_memory, and unlike when writing memory with
TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path
checks whether we're trying to write to a read-only region.
At the time "breakpoint auto-hw" was added, we didn't have the
TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object
distinction yet, and the code path in memory_xfer_partial that blocks
writes to read-only memory was hit for memory breakpoints too. With
GDB 6.8 we had:
warning: cannot set software breakpoint at readonly address 0000000000443943
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x443943: Input/output error.
So I started out by fixing this by adding the memory region validation
to TARGET_OBJECT_RAW_MEMORY too.
But later, when testing against GDBserver, I realized that that would
only block software/memory breakpoints GDB itself inserts with
gdb/mem-break.c. If a target has a to_insert_breakpoint method, the
insertion request will still pass through to the target. So I ended
up converting the "cannot set breakpoint" warning in breakpoint.c to a
real error return, thus blocking the insertion sooner.
With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY
changes once software single-step breakpoints are converted to real
breakpoints. We need them today as software single-step breakpoints
bypass insert_bp_location. But, it'll be best to leave that in as
safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Error out if inserting a
software breakpoint at a read-only address.
* target.c (memory_xfer_check_region): New function, factored out
from ...
(memory_xfer_partial_1): ... this. Make the 'reg_len' local a
ULONGEST.
(target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access
against the memory region attributes.
gdb/testsuite/
2014-10-01 Pedro Alves <palves@redhat.com>
* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.
Don't reset the exit code at inferior exit and print it in
-list-thread-groups.
gdb/ChangeLog:
* NEWS: Announce new exit-code field in -list-thread-groups
output.
* inferior.c (exit_inferior_1): Don't clear exit code.
(inferior_appeared): Clear exit code.
* mi/mi-main.c (print_one_inferior): Add printing of the exit
code.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-exit-code.exp: New file.
* gdb.mi/mi-exit-code.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Miscellaneous gdb/mi Commands): Document new
exit-code field in -list-thread-groups output.
This makes it easier to rebuild all GDB's generated target description
C files.
It also clarifies the comments a bit. One might think we need a GDB
configured for the particular arquitecture (--target=foo). But a
build that includes support for the target description is sufficient.
(GDB rejects target descriptions that explicitly specify the
architecture, with an <architecture> element, if the architecture is
unknown.)
Tested that "make clean-cfiles" deletes all .c files under
src/gdb/features/, and that "make cfiles" generates them all without
error, and that diffing the newly generated C files against master
comes out an empty diff.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile: Update comments.
(XMLTOC): List all xml files we build C files from.
(clean-cfiles): New rule.
I regenerated all the .c files under src/gdb/features/ and this is
what I got.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/i386/amd64-avx512-linux.c: Regenerate.
* features/i386/amd64-avx512.c: Regenerate.
* features/i386/x32-avx512-linux.c: Regenerate.
* features/i386/x32-avx512.c: Regenerate.
The only reason .dat files exist is for GBBserver to use them in its
build system.
A few .dat files are listed as targets for generation that shouldn't.
The target descriptions these files are built from aren't used by
GDBserver. They're fallback descriptions GDB itself has baked in.
Remove them from the list of .dat files to be generated, otherwise a
plain "make" under src/gdb/features/ generates new .dat files that
aren't even in the tree today.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile (WHICH): Remove arm-with-m,
arm-with-m-fpa-layout and arm-with-m-vfp-d16.
So that we can do "make clean all" to regenerate all the renerated
.dat files.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/Makefile (clean): New rule.
This file's format is invalid, as it's missing some end quotes.
I noticed this because I tried to regenerate all the .dat files in
gdb/regformats/. I got:
sh ../../move-if-change ../regformats/i386/x32-avx.tmp ../regformats/i386/x32-avx.dat
echo "# DO NOT EDIT: generated from i386/x32-avx512.xml" > ../regformats/i386/x32-avx512.tmp
echo "name:`echo x32-avx512 | sed 's/-/_/g'`" >> ../regformats/i386/x32-avx512.tmp
echo "xmltarget:x32-avx512.xml" >> ../regformats/i386/x32-avx512.tmp
echo "expedite:rbp,rsp,rip" \
>> ../regformats/i386/x32-avx512.tmp
xsltproc --path "/home/pedro/gdb/mygit/src/gdb/features" --xinclude number-regs.xsl i386/x32-avx512.xml | \
xsltproc sort-regs.xsl - | \
xsltproc gdbserver-regs.xsl - >> ../regformats/i386/x32-avx512.tmp
i386/64bit-avx512.xml:81: parser error : Unescaped '<' not allowed in attributes values
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:81: parser error : attributes construct error
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:81: parser error : Couldn't find end of Start Tag reg line 80
<reg name="zmm11h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:82: parser error : Unescaped '<' not allowed in attributes values
<reg name="zmm12h" bitsize="256" type="v2ui128/>
^
i386/64bit-avx512.xml:82: parser error : attributes construct error
<reg name="zmm12h" bitsize="256" type="v2ui128/>
^
...
i386/x32-avx512.xml:17: element include: XInclude error : could not load i386/64bit-avx512.xml, and no fallback was found
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
make: *** [../regformats/i386/x32-avx512.dat] Error 6
Interestingly, gdb/expat manages to grok the broken file.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/i386/64bit-avx512.xml (zmm10h, zmm11h, zmm12h, zmm13h)
(zmm14h): Add missing end quotes.
This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be
64bit.'.
Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really
32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2)
implementation is a bad idea.
In addition, while that commit intended to fix big endian Aarch64, it
ended up breaking floating point debugging against GDBserver, for both
big and little endian, because it changed the CPSR to be 64-bit in the
features/aarch64-core.xml file, but missed regenerating the
regformats/aarch64.dat file. If we generate it now, we see this:
diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat
index afe1028..0d32183 100644
--- c/gdb/regformats/aarch64.dat
+++ w/gdb/regformats/aarch64.dat
@@ -35,7 +35,7 @@ expedite:x29,sp,pc
64:x30
64:sp
64:pc
-32:cpsr
+64:cpsr
128:v0
128:v1
128:v2
IOW, that commit left regformats/aarch64.dat still considering CPSR as
32-bits. regformats/aarch64.dat is used by GDBserver for its internal
regcache layout, and for the g/G packet register block. See the
generated aarch64.c file in GDBserver's build dir.
So the target description xml file that GDBserver reports to GDB is
now claiming that CPSR is 64-bit, but what GDBserver actually puts in
the g/G register packets is 32-bits. Because GDB thinks CPSR is
64-bit (because that's what the XML description says), GDB will be
reading the remaining 32-bit bits of CPSR out of v0 (the register
immediately afterwards), and then all the registers that follow CPSR
in the register packet end up wrong in GDB, because they're being read
from the wrong offsets...
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* features/aarch64-core.xml (cpsr): Change back to 32-bit.
* features/aarch64.c: Regenerate.
This patch reorganizes the code that implements follow-fork and
detach-on-fork in preparation for implementation of those features for the
extended-remote target. The function linux-nat.c:linux_child_follow_fork
contained target-independent code mixed in with target-dependent code. The
target-independent pieces need to be accessible for the host-side
implementation of follow-fork for extended-remote Linux targets.
The changes are fairly mechanical. A new routine, follow_fork_inferior,
is implemented in infrun.c, containing those parts of
linux_child_follow_fork that manage inferiors and the inferior list. The
parts of linux_child_follow_fork that deal with LWPs and target-specifics
were left in-place. Although the order of some operations was changed, the
resulting functionality was not.
Modifications were made to the other native target follow-fork functions,
inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them
to work with follow_fork_inferior. Some other adjustments were necessary
in inf-ttrace.c. The changes to inf-ttrace.c and inf-ptrace.c were not
tested.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent
code so as to work with follow_fork_inferior.
* inf-ttrace.c (inf_ttrace_follow_fork): Ditto.
(inf_ttrace_create_inferior): Remove reference to
inf_ttrace_vfork_ppid.
(inf_ttrace_attach): Ditto.
(inf_ttrace_detach): Ditto.
(inf_ttrace_kill): Use current_inferior instead of
inf_ttrace_vfork_ppid.
(inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report
TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the
inferior away from the parent.
* infrun.c (follow_fork): Call follow_fork_inferior instead of
target_follow_fork.
(follow_fork_inferior): New function.
(follow_inferior_reset_breakpoints): Make function static.
* infrun.h (follow_inferior_reset_breakpoints): Remove declaration.
* linux-nat.c (linux_child_follow_fork): Move target-independent
code to infrun.c:follow_fork_inferior.
Now that all instances of the regset_from_core_section gdbarch method
have been replaced by the new iterator method, delete the obsolete
method from the gdbarch interface. Adjust all invocations and
references to it.
gdb/ChangeLog:
* gdbarch.sh (regset_from_core_section): Remove gdbarch method.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* corelow.c (sniff_core_bfd): Drop presence check for deleted
gdbarch method 'regset_from_core_section'.
(get_core_register_section): Remove handling for the case that
regset == NULL and regset_from_core_section is defined.
(get_core_registers): Drop check for deleted method.
* procfs.c (procfs_do_thread_registers): Adjust comment.
Now that all Linux targets use the regset iterator, the fall back to
the deprecated target method is dropped.
gdb/ChangeLog:
* linux-nat.c (linux_nat_collect_thread_registers): Remove.
(linux_nat_make_corefile_notes): Remove.
(linux_target_install_ops): Do not set target method
'make_corefile_notes'.
* linux-tdep.c (struct linux_corefile_thread_data)<collect>:
Remove field.
(linux_corefile_thread_callback): Instead of args->collect, call
linux_collect_thread_registers.
(linux_make_corefile_notes): Remove 'collect' parameter. Return
NULL unless there is a regset iterator.
(linux_make_corefile_notes_1): Remove.
(linux_init_abi): Replace reference to linux_make_corefile_notes_1
by linux_make_corefile_notes.
* linux-tdep.h (linux_make_corefile_notes): Remove prototype.
Now that all users of the target method 'fbsd_make_corefile_notes'
have been converted to the version in fbsd-tdep.c, the old method is
removed.
gdb/ChangeLog:
* fbsd-nat.c (find_signalled_thread, find_stop_signal)
(fbsd_collect_regset_section_cb, fbsd_make_corefile_notes):
Remove.
* fbsd-nat.h (fbsd_make_corefile_notes): Remove prototype.
For TILE-Gx GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* tilegx-linux-tdep.c (TILEGX_LINUX_SIZEOF_GREGSET): New macro.
(tilegx_regset_from_core_section): Remove.
(tilegx_iterate_over_regset_sections): New.
(tilegx_linux_init_abi): Adjust gdbarch initialization.
For Super-H targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* sh-linux-tdep.c (sh_linux_init_abi): Set tdep fields
'sizeof_gregset' and 'sizeof_fpregset'.
* sh-tdep.c (sh_regset_from_core_section): Remove.
(sh_iterate_over_regset_sections): New.
(sh_gdbarch_init): Adjust gdbarch initialization.
* sh-tdep.h (struct gdbarch_tdep): New fields sizeof_gregset and
sizeof_fpregset.
* shnbsd-tdep.c (shnbsd_init_abi): Set tdep field
'sizeof_gregset'.
For Nios II GNU/Linux targets, no longer define the gdbarch method
'regset_from_core_section', but the iterator method instead.
gdb/ChangeLog:
* nios2-linux-tdep.c (NIOS2_GREGS_SIZE): New macro.
(nios2_regset_from_core_section): Remove.
(nios2_iterate_over_regset_sections): New.
(nios2_linux_init_abi): Adjust gdbarch initialization.
Don't define the 'regset_from_core_section' method, but the iterator
method instead. Do this for GNU/Linux- as well as
Net/OpenBSD-targets. In the case of GNU/Linux this should enable
non-native use of the 'generate-core-file' command.
gdb/ChangeLog:
* alpha-linux-tdep.c (alpha_linux_regset_from_core_section): Remove.
(alpha_linux_iterate_over_regset_sections): New.
(alpha_linux_init_abi): Adjust gdbarch initialization.
* alphabsd-tdep.h (alphanbsd_regset_from_core_section): Remove
prototype.
(alphanbsd_iterate_over_regset_sections): New prototype.
* alphafbsd-tdep.c (alphafbsd_init_abi): Add comment for missing
fbsd_init_abi invocation.
* alphanbsd-tdep.c (alphanbsd_supply_gregset): Move below
alphanbsd_aout_supply_gregset. Invoke the latter for the
appropriate size.
(alphanbsd_aout_gregset): Remove.
(alphanbsd_regset_from_core_section): Remove.
(alphanbsd_iterate_over_regset_sections): New.
(alphanbsd_init_abi): Adjust gdbarch initialization.
* alphaobsd-tdep.c (alphaobsd_init_abi): Likewise.
Don't define the 'regset_from_core_section' method, but the iterator
method instead. This slightly reduces the code and enables non-native
use of the 'generate-core-file' command.
Also, when all instances of 'regset_from_core_section' are replaced,
it can be dropped from the gdbarch interface.
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_regset_from_core_section):
Remove.
(aarch64_linux_iterate_over_regset_sections): New.
(aarch64_linux_init_abi): Adjust gdbarch initialization.
This creates a new version of the FreeBSD core file note generation
logic in the new target-dependent file "fbsd-tdep.c". The new version
is mostly copied from "fbsd-nat.c", but uses the iterator instead of
regset_from_core_section and defines fbsd_make_corefile_notes as a
gdbarch method instead of a target method.
Consecutive architecture-dependent changes exploit the new version,
migrating away from the target method. When all FreeBSD targets are
changed, the target method can go away.
gdb/ChangeLog:
* fbsd-tdep.c: New file.
* fbsd-tdep.h: New file.
* Makefile.in (ALL_TARGET_OBS): Add fbsd-tdep.o.
(HFILES_NO_SRCDIR): Add fbsd-tdep.h.
(ALLDEPFILES): Add fbsd-tdep.c.
This adds the 'regset' parameter to the iterator callback.
Consequently the 'regset_from_core_section' method is dropped for all
targets that provide the iterator method.
This change prepares for replacing regset_from_core_section
everywhere, thereby eliminating one gdbarch interface. Since the
iterator is usually no more complex than regset_from_core_section
alone, targets that previously didn't define core_regset_sections will
then gain multi-arch capable core file generation support without
increased complexity.
gdb/ChangeLog:
* gdbarch.sh (iterate_over_regset_sections_cb): Add regset
parameter.
* gdbarch.h: Regenerate.
* corelow.c (sniff_core_bfd): Don't sniff if gdbarch has a regset
iterator.
(get_core_register_section): Add parameter 'regset' and use it, if
set. Add parameter 'min_size' and verify the bfd section size
against it.
(get_core_registers_cb): Add parameter 'regset' and pass it to
get_core_register section. For the "standard" register sections
".reg" and ".reg2", set an appropriate default for human_name.
(get_core_registers): Don't abort when the gdbarch has an iterator
but no regset_from_core_section. Add NULL/0 for parameters
'regset'/'min_size' in calls to get_core_register_section.
* linux-tdep.c (linux_collect_regset_section_cb): Add parameter
'regset' and use it instead of calling the
regset_from_core_section gdbarch method.
* i386-tdep.h (struct gdbarch_tdep): Add field 'fpregset'.
* i386-tdep.c (i386_supply_xstateregset)
(i386_collect_xstateregset, i386_xstateregset): Moved to
i386-linux-tdep.c.
(i386_regset_from_core_section): Drop handling for .reg-xfp and
.reg-xstate.
(i386_gdbarch_init): Set tdep field 'fpregset'. Enable generic
core file support only if the regset iterator hasn't been set.
* i386-linux-tdep.c (i386_linux_supply_xstateregset)
(i386_linux_collect_xstateregset, i386_linux_xstateregset): New.
Moved from i386-tdep.c and renamed to *_linux*.
(i386_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation. Allow any .reg-xstate size when reading
from a core file.
* amd64-tdep.c (amd64_supply_xstateregset)
(amd64_collect_xstateregset, amd64_xstateregset): Moved to
amd64-linux-tdep.c.
(amd64_regset_from_core_section): Remove.
(amd64_init_abi): Set new tdep field 'fpregset'. No longer
install an amd64-specific regset_from_core_section gdbarch method.
* amd64-linux-tdep.c (amd64_linux_supply_xstateregset)
(amd64_linux_collect_xstateregset, amd64_linux_xstateregset): New.
Moved from amd64-tdep.c and renamed to *_linux*.
(amd64_linux_iterate_over_regset_sections): Add regset parameter
to each callback invocation. Allow any .reg-xstate size when
reading from a core file.
* arm-linux-tdep.c (arm_linux_regset_from_core_section): Remove.
(arm_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(arm_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* ppc-linux-tdep.c (ppc_linux_regset_from_core_section): Remove.
(ppc_linux_iterate_over_regset_sections): Add regset parameter to
each callback invocation.
(ppc_linux_init_abi): No longer set the regset_from_core_section
gdbarch method.
* s390-linux-tdep.c (struct gdbarch_tdep): Remove the fields
gregset, sizeof_gregset, fpregset, and sizeof_fpregset.
(s390_regset_from_core_section): Remove.
(s390_iterate_over_regset_sections): Add regset parameter to each
callback invocation.
(s390_gdbarch_init): No longer set the regset_from_core_section
gdbarch method. Drop initialization of deleted tdep fields.
The core_regset_sections list in gdbarch (needed for multi-arch
capable core file generation support) is replaced by an iterator
method. Overall, this reduces the code a bit, and it allows for more
flexibility.
gdb/ChangeLog:
* amd64-linux-tdep.c (amd64_linux_regset_sections): Remove.
(amd64_linux_iterate_over_regset_sections): New.
(amd64_linux_init_abi_common): Don't install the regset section
list, but the new iterator in gdbarch.
* arm-linux-tdep.c (arm_linux_fpa_regset_sections)
(arm_linux_vfp_regset_sections): Remove. Move combined logic...
(arm_linux_iterate_over_regset_sections): ...here. New function.
(arm_linux_init_abi): Set iterator instead of section list.
* corelow.c (get_core_registers_cb): New function, logic moved
from...
(get_core_registers): ...loop body here. Use new iterator method
instead of walking through the regset section list.
* gdbarch.sh: Remove 'core_regset_sections'. New method
'iterate_over_regset_sections'. New typedef
'iterate_over_regset_sections_cb'.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* i386-linux-tdep.c (i386_linux_regset_sections)
(i386_linux_sse_regset_sections, i386_linux_avx_regset_sections):
Remove.
(i386_linux_iterate_over_regset_sections): New.
(i386_linux_init_abi): Don't choose a regset section list, but
install new iterator in gdbarch.
* linux-tdep.c (struct linux_collect_regset_section_cb_data): New.
(linux_collect_regset_section_cb): New function, logic moved
from...
(linux_collect_thread_registers): ...loop body here. Use iterator
method instead of walking through list.
(linux_make_corefile_notes_1): Check for presence of iterator
method instead of regset section list.
* ppc-linux-tdep.c (ppc_linux_vsx_regset_sections)
(ppc_linux_vmx_regset_sections, ppc_linux_fp_regset_sections)
(ppc64_linux_vsx_regset_sections, ppc64_linux_vmx_regset_sections)
(ppc64_linux_fp_regset_sections): Remove. Move combined logic...
(ppc_linux_iterate_over_regset_sections): ...here. New function.
(ppc_linux_init_abi): Don't choose from above regset section
lists, but install new iterator in gdbarch.
* regset.h (struct core_regset_section): Remove.
* s390-linux-tdep.c (struct gdbarch_tdep): Add new fields
have_linux_v1, have_linux_v2, and have_tdb.
(s390_linux32_regset_sections, s390_linux32v1_regset_sections)
(s390_linux32v2_regset_sections, s390_linux64_regset_sections)
(s390_linux64v1_regset_sections, s390_linux64v2_regset_sections)
(s390x_linux64_regset_sections, s390x_linux64v1_regset_sections)
(s390x_linux64v2_regset_sections): Remove. Move combined logic...
(s390_iterate_over_regset_sections): ...here. New function. Use
new tdep fields.
(s390_gdbarch_init): Set new tdep fields. Don't choose from above
regset section lists, but install new iterator.
commit 2268b414f4
added file "features/library-list-svr4.dtd" but the added code uses
"library-list.dtd" instead.
Curiously after changing for a test s/name/nXme/ in the DTD making the
gdbserver output non-conforming there is no warning or regression seen (tested
gdb.base/shlib-call.exp, using_xfer is still 1). I did not check more why the
DTD conformance verification does not work.
gdb/ChangeLog
2014-09-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* solib-svr4.c (svr4_parse_libraries): Use "library-list-svr4.dtd".
Remove the pruning of program spaces in print_program_space to remove
unwanted side-effects. "info" commands and print routines should
generally not change the state of the debugger.
gdb/Changelog:
* progspace.c (print_program_space): Don't prune program spaces
before printing them.
What matters for this function, is whether the user requested a
"step", for "set scheduler-locking step", not whether GDB is doing an
internal step for some reason.
/* Return a ptid representing the set of threads that we will proceed,
in the perspective of the user/frontend. */
extern ptid_t user_visible_resume_ptid (int step);
Therefore, the check for singlestep_breakpoints_inserted_p is actually
incorrect, and we end up applying schedlock more often on sss targets
than on non-sss targets.
Found by inspection while working on a patch that eliminates the
singlestep_breakpoints_inserted_p global.
Tested on x86_64 Fedora 20 on top of my 'software single-step on x86'
series.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (user_visible_resume_ptid): Don't check
singlestep_breakpoints_inserted_p.
gdb/
2014-09-25 Pedro Alves <palves@redhat.com>
* infrun.c (stepping_past_instruction_at)
(clear_exit_convenience_vars): Point at infrun.h instead of
inferior.h.
(handle_signal_stop): Fix typo.
This patch fixes a typo in the bit mask I've made in my previous code
refactor. If PC is in the register list, the bit 8 is one, so bit
mask 0xff00 should be used. Current condition is a constant false.
gdb:
2014-09-24 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (thumb_in_function_epilogue_p): Fix typo in the
bitmask.
This commit renames target_stop_ptid as target_stop_and_wait and
target_continue_ptid as target_continue_no_signal. Comments are
updated to more fully describe the functions' behaviour.
gdb/ChangeLog:
* target/target.h (target_stop_ptid): Renamed as...
(target_stop_and_wait): New function. Updated comment.
All uses updated.
(target_continue_ptid): Renamed as...
(target_continue_no_signal): New function. Updated comment.
All uses updated.
By default, GDB removes all breakpoints from the target when the
target stops and the prompt is given back to the user. This is useful
in case GDB crashes while the user is interacting, as otherwise,
there's a higher chance breakpoints would be left planted on the
target.
But, as long as any thread is running free, we need to make sure to
keep breakpoints inserted, lest a thread misses a breakpoint. With
that in mind, in preparation for non-stop mode, we added a "breakpoint
always-inserted on" mode. This traded off the extra crash protection
for never having threads miss breakpoints, and in addition is more
efficient if there's a ton of breakpoints to remove/insert at each
user command (e.g., at each "step").
When we added non-stop mode, and for a period, we required users to
manually set "always-inserted on" when they enabled non-stop mode, as
otherwise GDB removes all breakpoints from the target as soon as any
thread stops, which means the other threads still running will miss
breakpoints. The test added by this patch exercises this.
That soon revealed a nuisance, and so later we added an extra
"breakpoint always-inserted auto" mode, that made GDB behave like
"always-inserted on" when non-stop was enabled, and "always-inserted
off" when non-stop was disabled. "auto" was made the default at the
same time.
In hindsight, this "auto" setting was unnecessary, and not the ideal
solution. Non-stop mode does depends on breakpoints always-inserted
mode, but only as long as any thread is running. If no thread is
running, no breakpoint can be missed. The same is true for all-stop
too. E.g., if, in all-stop mode, and the user does:
(gdb) c&
(gdb) b foo
That breakpoint at "foo" should be inserted immediately, but it
currently isn't -- currently it'll end up inserted only if the target
happens to trip on some event, and is re-resumed, e.g., an internal
breakpoint triggers that doesn't cause a user-visible stop, and so we
end up in keep_going calling insert_breakpoints. The test added by
this patch also covers this.
IOW, no matter whether in non-stop or all-stop, if the target fully
stops, we can remove breakpoints. And no matter whether in all-stop
or non-stop, if any thread is running in the target, then we need
breakpoints to be immediately inserted. And then, if the target has
global breakpoints, we need to keep breakpoints even when the target
is stopped.
So with that in mind, and aiming at reducing all-stop vs non-stop
differences for all-stop-on-stop-of-non-stop, this patch fixes
"breakpoint always-inserted off" to not remove breakpoints from the
target until it fully stops, and then removes the "auto" setting as
unnecessary. I propose removing it straight away rather than keeping
it as an alias, unless someone complains they have scripts that need
it and that can't adjust.
Tested on x86_64 Fedora 20.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* NEWS: Mention merge of "breakpoint always-inserted" modes "off"
and "auto" merged.
* breakpoint.c (enum ugll_insert_mode): New enum.
(always_inserted_mode): Now a plain boolean.
(show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO.
(breakpoints_always_inserted_mode): Delete.
(breakpoints_should_be_inserted_now): New function.
(insert_breakpoints): Pass UGLL_INSERT to
update_global_location_list instead of calling
insert_breakpoint_locations manually.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode.
(_initialize_breakpoint): "breakpoint always-inserted" option is
now a boolean command. Update help text.
* breakpoint.h (breakpoints_always_inserted_mode): Delete declaration.
(breakpoints_should_be_inserted_now): New declaration.
* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
Remove breakpoints_always_inserted_mode check.
(normal_stop): Adjust to use breakpoints_should_be_inserted_now.
* remote.c (remote_start_remote): Likewise.
gdb/doc/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Set Breaks): Document that "set breakpoint
always-inserted off" is the default mode now. Delete
documentation of "set breakpoint always-inserted auto".
gdb/testsuite/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp: New file.
* gdb.threads/break-while-running.c: New file.
This adds a new mode for update_global_location_list, that allows
callers saying "please insert breakpoints, even if
breakpoints_always_inserted_mode() is false". This allows removing a
couple breakpoints_always_inserted_mode checks.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* breakpoint.c (enum ugll_insert_mode): Add UGLL_INSERT.
(insert_breakpoints): Don't call insert_breakpoint_locations here.
Instead, pass UGLL_INSERT to update_global_location_list.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Handle UGLL_INSERT.
Later we'll want a tristate, but for now, convert to an enum that maps 1-1
with the current boolean's true/false.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* breakpoint.c (enum ugll_insert_mode): New enum.
(update_global_location_list)
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode. All callers adjusted.
This commit implements functions for identifying and extracting extended
ptrace event information from a Linux wait status. These are just
convenience functions intended to hide the ">> 16" used to extract the
event from the wait status word, replacing the hard-coded shift with a more
descriptive function call. This is preparatory work for implementation of
follow-fork and detach-on-fork for extended-remote linux targets.
gdb/ChangeLog:
* linux-nat.c (linux_handle_extended_wait): Call
linux_ptrace_get_extended_event.
(wait_lwp): Call linux_is_extended_waitstatus.
(linux_nat_filter_event): Call linux_ptrace_get_extended_event
and linux_is_extended_waitstatus.
* nat/linux-ptrace.c (linux_test_for_tracefork): Call
linux_ptrace_get_extended_event.
(linux_ptrace_get_extended_event): New function.
(linux_is_extended_waitstatus): New function.
* nat/linux-ptrace.h (linux_ptrace_get_extended_event)
(linux_is_extended_waitstatus): New declarations.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Call
linux_ptrace_get_extended_event.
(get_stop_pc, get_detach_signal, linux_low_filter_event): Call
linux_is_extended_waitstatus.
---
I see the following fail on arm-none-eabi target,
(gdb) b 24^M
Breakpoint 1 at 0x4: file
../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc,
line 24.^M
(gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24
Currently, we are using flag has_section_at_zero to determine whether
address zero in debug info means the corresponding code has been
GC'ed, like this:
case DW_LNE_set_address:
address = read_address (abfd, line_ptr, cu, &bytes_read);
if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
However, this is incorrect on some bare metal targets, as .text
section is located at 0x0, so dwarf2_per_objfile->has_section_at_zero
is true. If a function is GC'ed by linker, the address is zero. GDB
thinks address zero is a function's address rather than this function
is GC'ed.
In this patch, we choose 'lowpc' got in read_file_scope to check
whether 'lowpc' is greater than zero. If it isn't, address zero really
means the function is GC'ed. In this patch, we pass 'lowpc' in
read_file_scope through handle_DW_AT_stmt_list and dwarf_decode_lines,
and to dwarf_decode_lines_1 finally.
This patch fixes the fail above. This patch also covers the path that
partial symbol isn't used, which is tested by starting gdb with
--readnow option.
It is regression tested on x86-linux with
target_board=dwarf4-gdb-index, and arm-none-eabi. OK to apply?
gdb:
2014-09-19 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Add argument 'lowpc'. Update
comments. Callers update.
(dwarf_decode_lines): Likewise.
(dwarf_decode_lines_1): Add argument 'lowpc'. Update
comments. Skip the line table if 'lowpc' is greater than
'address'. Don't check
dwarf2_per_objfile->has_section_at_zero.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.base/break-on-linker-gcd-function.exp: Move test into new
proc set_breakpoint_on_gcd_function. Invoke
set_breakpoint_on_gcd_function. Restart GDB with --readnow and
invoke set_breakpoint_on_gcd_function again.
If accessing memory via safe_read_memory_integer fails, that function
used to print an error message even though callers were perfectly able
to handle (and even expected!) failures.
This patch removes the confusing message by changing the routine to
directly use target_read_memory.
gdb/ChangeLog:
PR gdb/17384
* corefile.c (struct captured_read_memory_integer_arguments): Remove.
(do_captured_read_memory_integer): Remove.
(safe_read_memory_integer): Use target_read_memory directly instead
of catching errors in do_captured_read_memory_integer.
This obvious change removes dead code from objc-lang.c. I was
grepping for "fprintf (stderr..." and found this code between "#if
0".."#endif" blocks.
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* objc-lang.c (find_implementation_from_class): Remove dead code.
This is an obvious replacement of "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...", which is the standard to use in
these cases.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/7233
* linux-nat.c (linux_nat_wait_1): Replace "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...)".
PR 12526 reports that -location watchpoints against bitfield arguments
trigger false positives when bits around the bitfield, but not the
bitfield itself, are modified.
This happens because -location watchpoints naturally operate at the
byte level, not at the bit level. When the address of a bitfield
lvalue is taken, information about the bitfield (i.e. its offset and
size) is lost in the process.
This information must first be retained throughout the lifetime of the
-location watchpoint. This patch achieves this by adding two new
fields to the watchpoint struct: val_bitpos and val_bitsize. These
fields are set when a watchpoint is first defined in watch_command_1.
They are both equal to zero if the watchpoint is not a -location
watchpoint or if the argument is not a bitfield.
Then these bitfield parameters are used inside update_watchpoint and
watchpoint_check to extract the actual value of the bitfield from the
watchpoint address, with the help of a local helper function
extract_bitfield_from_watchpoint_value.
Finally when creating a HW breakpoint pointing to a bitfield, we
optimize the address and length of the breakpoint. By skipping over
the bytes that don't cover the bitfield, this step reduces the
frequency at which a read watchpoint for the bitfield is triggered.
It also reduces the number of times a false-positive call to
check_watchpoint is triggered for a write watchpoint.
gdb/
PR breakpoints/12526
* breakpoint.h (struct watchpoint): New fields val_bitpos and
val_bitsize.
* breakpoint.c (watch_command_1): Use these fields to retain
bitfield information.
(extract_bitfield_from_watchpoint_value): New function.
(watchpoint_check): Use it.
(update_watchpoint): Use it. Optimize the address and length of a
HW watchpoint pointing to a bitfield.
* value.h (unpack_value_bitfield): New prototype.
* value.c (unpack_value_bitfield): Make extern.
gdb/testsuite/
PR breakpoints/12526
* gdb.base/watch-bitfields.exp: New file.
* gdb.base/watch-bitfields.c: New file.
gdb:
2014-08-13 Omair Javaid <omair.javaid@linaro.org>
* arm-tdep.c (arm_record_vdata_transfer_insn): Added record handler for
vector data transfer instructions.
(arm_record_coproc_data_proc): Updated.
gdb:
2014-08-13 Omair Javaid <omair.javaid@linaro.org>
* arm-tdep.c (arm_record_coproc_data_proc): Add record handler stubs
for asimd, vfp and coprocessor insns.
(arm_record_asimd_vfp_coproc): Add record handler for asimd, vfp
and coprocessor insns.
(thumb2_record_coproc_insn): New function.
(thumb2_record_decode_insn_handler): Update coprocessor insns record
handlers.
(decode_insn): Install arm_record_asimd_vfp_coproc as handler for
opcode 110 insns.
If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".
This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.
One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command. I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.
gdb/ChangeLog:
* NEWS: Mention new "queue-signal" command.
* infcmd.c (queue_signal_command): New function.
(_initialize_infcmd): Add new queue-signal command.
gdb/doc/ChangeLog:
* gdb.texinfo (Signaling): Document new queue-signal command.
gdb/testsuite/ChangeLog:
* gdb.threads/queue-signal.c: New file.
* gdb.threads/queue-signal.exp: New file.
The IRIX support wants to set a breakpoint to be hit when the startup
phase is complete, which is where shared libraries have been mapped
in. AFAIU, for most IRIX ports, that location is the entry point.
For MIPS IRIX however, GDB needs to set a breakpoint earlier, in
__dbx_link, as explained by:
#ifdef SYS_syssgi
/* On mips-irix, we need to stop the inferior early enough during
the startup phase in order to be able to load the shared library
symbols and insert the breakpoints that are located in these shared
libraries. Stopping at the program entry point is not good enough
because the -init code is executed before the execution reaches
that point.
So what we need to do is to insert a breakpoint in the runtime
loader (rld), more precisely in __dbx_link(). This procedure is
called by rld once all shared libraries have been mapped, but before
the -init code is executed. Unfortuantely, this is not straightforward,
as rld is not part of the executable we are running, and thus we need
the inferior to run until rld itself has been mapped in memory.
For this, we trace all syssgi() syscall exit events. Each time
we detect such an event, we iterate over each text memory maps,
get its associated fd, and scan the symbol table for __dbx_link().
When found, we know that rld has been mapped, and that we can insert
the breakpoint at the symbol address. Once the dbx_link() breakpoint
has been inserted, the syssgi() notifications are no longer necessary,
so they should be canceled. */
proc_trace_syscalls_1 (pi, SYS_syssgi, PR_SYSEXIT, FLAG_SET, 0);
#endif
The loop in irix_solib_create_inferior_hook then runs until whichever
breakpoint is hit first, the one set by solib-irix.c or the one set by
procfs.c.
Note the comment in disable_break talks about __dbx_init, but I think
that's a typo for __dbx_link:
- /* Note that it is possible that we have stopped at a location that
- is different from the location where we inserted our breakpoint.
- On mips-irix, we can actually land in __dbx_init(), so we should
- not check the PC against our breakpoint address here. See procfs.c
- for more details. */
This looks very much like referring to the loop in
irix_solib_create_inferior_hook stopping at __dbx_link instead of at
the entry point.
What this patch does is convert these deprecated raw breakpoints to
standard solib_event breakpoints. When the first solib-event
breakpoint is hit, we delete all solib-event breakpoints. We do that
in the so_ops->handle_event hook.
This allows getting rid of the loop in irix_solib_create_inferior_hook
completely, which should allow properly handling signals and other
events in the early startup phase, like in SVR4.
Built on x86_64 Fedora 20 with --enable-targets=all (builds
solib-irix.c).
Joel tested that with an earlier version of this patch "info shared"
after starting a program gave the same list of shared libraries as
before.
gdb/ChangeLog:
2014-09-12 Pedro Alves <palves@redhat.com>
* breakpoint.c (remove_solib_event_breakpoints_at_next_stop)
(create_and_insert_solib_event_breakpoint): New functions.
* breakpoint.h (create_and_insert_solib_event_breakpoint)
(remove_solib_event_breakpoints_at_next_stop): New declarations.
* procfs.c (dbx_link_bpt_addr, dbx_link_bpt): Delete globals.
(remove_dbx_link_breakpoint): Delete function.
(insert_dbx_link_bpt_in_file): Use
create_and_insert_solib_event_breakpoint instead of
deprecated_insert_raw_breakpoint.
(procfs_wait): Don't check whether we hit __dbx_link here.
(procfs_mourn_inferior): Don't delete the __dbx_link breakpoint
here.
* solib-irix.c (base_breakpoint): Delete global.
(disable_break): Delete function.
(enable_break): Use create_solib_event_breakpoint
instead of deprecated_insert_raw_breakpoint.
(irix_solib_handle_event): New function.
(irix_solib_create_inferior_hook): Don't run the target or disable
the mapping-complete breakpoint here.
(_initialize_irix_solib): Install irix_solib_handle_event as
so_ops->handle_event hook.
The problem is that rs6000_frame_cache attempts to read the stack backchain via
read_memory_unsigned_integer, which throws an exception if the stack pointer is
invalid. With this patch, it calls safe_read_memory_integer instead, which
doesn't throw an exception and allows for safe handling of that situation.
gdb/ChangeLog
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Ulrich Weigand <uweigand@de.ibm.com>
PR tdep/17379
* rs6000-tdep.c (rs6000_frame_cache): Use safe_read_memory_integer
instead of read_memory_unsigned_integer.
gdb/testcase/ChangeLog
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
PR tdep/17379
* gdb.arch/powerpc-stackless.S: New file.
* gdb.arch/powerpc-stackless.exp: New file.
This commit makes linux-waitpid.c include common-defs.h. GDB's
inclusion of defs.h is removed, but gdbserver's inclusion of
server.h remains to support some gdbserver-specific debug code
that cannot presently be merged. A new FIXME documents this.
gdb/ChangeLog:
* nat/linux-waitpid.c: Include common-defs.h.
[GDBSERVER]: Add FIXME comment.
[!GDBSERVER]: Don't include defs.h or signal.h.
(linux_debug) [!GDBSERVER]: Remove empty block.
This commit makes nat/x86-dregs.c include common-defs.h rather than
defs.h or server.h. An extra header required including in order to
support this change.
gdb/ChangeLog:
* nat/x86-dregs.c: Include common-defs.h and break-common.h.
Don't include defs.h or server.h.
This commit makes nat/linux-btrace.c include common-defs.h rather
than defs.h or server.h. A couple of minor changes were required
to support this change.
gdb/ChangeLog:
* nat/linux-btrace.c: Include common-defs.h.
Don't include defs.h, server.h or gdbthread.h.
* nat/linux-btrace.h (struct target_ops): New forward declaration.
This commit makes 19 of the 22 shared .c files in common, nat and
target include common-defs.h instead of defs.h/server.h. The
remaining three files need slight extra work and are dealt with
in separate commits.
gdb/ChangeLog:
* common/agent.c: Include common-defs.h.
Don't include defs.h or server.h.
* common/buffer.c: Likewise.
* common/common-debug.c: Likewise.
* common/common-utils.c: Likewise.
* common/errors.c: Likewise.
* common/filestuff.c: Likewise.
* common/format.c: Likewise.
* common/gdb_vecs.c: Likewise.
* common/print-utils.c: Likewise.
* common/ptid.c: Likewise.
* common/rsp-low.c: Likewise.
* common/signals.c: Likewise.
* common/vec.c: Likewise.
* common/xml-utils.c: Likewise.
* nat/linux-osdata.c: Likewise.
* nat/linux-procfs.c: Likewise.
* nat/linux-ptrace.c: Likewise.
* nat/mips-linux-watch.c: Likewise.
* target/waitstatus.c: Likewise.
This introduces common-regcache.h. This contains two functions that
allow nat/linux-btrace.c to be simplified. A better long term
solution would be unify the regcache code, but this is sufficient for
now.
gdb/ChangeLog:
* common/common-regcache.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/common-regcache.h.
* regcache.h: Include common-regcache.h.
(regcache_read_pc): Don't declare.
* regcache.c (get_thread_regcache_for_ptid): New function.
* nat/linux-btrace.c: Don't include regcache.h.
Include common-regcache.h.
(perf_event_read_bts): Use get_thread_regcache_for_ptid.
gdb/gdbserver/ChangeLog:
* regcache.h: Include common-regcache.h.
(regcache_read_pc): Don't declare.
* regcache.c (get_thread_regcache_for_ptid): New function.
gdb/
* regcache.h (struct regset): Declare.
Commit 0b3092721e added uses of struct regset to
gdb/regcache.h, but that struct is not declared in this file, and, as it
happens, also nowhere else in the #include chain on x86 GNU/Hurd. This results
in warnings/errors such as:
gcc-4.8 [...] ../../W._C._Handy/gdb/gdb.c
In file included from ./nm.h:25:0,
from ../../W._C._Handy/gdb/defs.h:454,
from ../../W._C._Handy/gdb/gdb.c:19:
../../W._C._Handy/gdb/regcache.h:190:9: warning: 'struct regset' declared inside parameter list [enabled by default]
size_t size);
^
../../W._C._Handy/gdb/regcache.h:190:9: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
../../W._C._Handy/gdb/regcache.h:193:10: warning: 'struct regset' declared inside parameter list [enabled by default]
int regnum, void *buf, size_t size);
^
Doing:
gdb --pid=PID -ex run
Results in GDB getting a SIGTTIN, and thus ending stopped. That's
usually indicative of a missing target_terminal_ours call.
E.g., from the PR:
$ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
[1] 28263
[1] Killed sleep 1h
[2]+ Stopped gdb -batch sleep $p -ex run
The workaround is doing:
gdb -ex "attach $PID" -ex "run"
instead of
gdb [-p] $PID -ex "run"
With the former, gdb waits for the attach command to complete before
moving on to the "run" command, because the interpreter is in sync
mode at this point, within execute_command. But for the latter,
attach_command is called directly from captured_main, and thus misses
that waiting. IOW, "run" is running before the attach continuation
has run, before the program stops and attach completes. The broken
terminal settings are just one symptom of that. Any command that
queries or requires input results in the same.
The fix is to wait in catch_command_errors (which is specific to
main.c nowadays), just like we wait in execute_command.
gdb/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* main.c: Include "infrun.h".
(catch_command_errors, catch_command_errors_const): Wait for the
foreground command to complete.
* top.c (maybe_wait_sync_command_done): New function, factored out
from ...
(maybe_wait_sync_command_done): ... here.
* top.h (maybe_wait_sync_command_done): New declaration.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
* gdb.base/attach.exp (test_command_line_attach_run): New
procedure.
(top level): Call it.
This introduces common/symbol.h. This file declares a function that
the shared code can use and that the clients must implement. It also
changes some shared code to use these functions.
gdb/ChangeLog:
* common/symbol.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/symbol.h.
* minsyms.c (find_minimal_symbol_address): New function.
* common/agent.c: Include common/symbol.h.
[!GDBSERVER]: Don't include objfiles.h.
(agent_look_up_symbols): Use find_minimal_symbol_address.
gdb/gdbserver/ChangeLog:
* symbol.c: New file.
* Makefile.in (SFILES): Add symbol.c.
(OBS): Add symbol.o.
This commit introduces two new functions to stop and restart target
processes that shared code can use and that clients must implement.
It also changes some shared code to use these functions.
gdb/ChangeLog:
* target/target.h (target_stop_ptid, target_continue_ptid):
Declare.
* target.c (target_stop_ptid, target_continue_ptid): New
functions.
* common/agent.c [!GDBSERVER]: Don't include infrun.h.
(agent_run_command): Always use target_stop_ptid and
target_continue_ptid.
gdb/gdbserver/ChangeLog:
* target.c (target_stop_ptid, target_continue_ptid): New
functions.
This introduces target/target.h. This file declares some functions
that the shared code can use and that clients must implement. It also
changes some shared code to use these functions.
gdb/ChangeLog:
* target/target.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add target/target.h.
* target.h: Include target/target.h.
(target_read_memory, target_write_memory): Don't declare.
* target.c (target_read_uint32): New function.
* common/agent.c: Include target/target.h.
[!GDBSERVER]: Don't include target.h.
(helper_thread_id): Type changed to uint32_t.
(agent_get_helper_thread_id): Use target_read_uint32.
(agent_run_command): Always use target_read_memory and
target_write_memory.
(agent_capability): Type changed to uint32_t.
(agent_capability_check): Use target_read_uint32.
gdb/gdbserver/ChangeLog:
* target.h: Include target/target.h.
* target.c (target_read_memory, target_read_uint32)
(target_write_memory): New functions.
This commit adds a new global flag show_debug_regs to common-debug.h
to replace the flag debug_hw_points used by gdbserver and by the
Linux x86 and AArch64 ports, and to replace the flag maint_show_dr
used by the Linux MIPS port.
Note that some debug printing in the AArch64 port was enabled only if
debug_hw_points > 1 but no way to set debug_hw_points to values other
than 0 and 1 was provided; that code was effectively dead. This
commit enables all debug printing if show_debug_regs is nonzero, so
the AArch64 output will be more verbose than previously.
gdb/ChangeLog:
* common/common-debug.h (show_debug_regs): Declare.
* common/common-debug.c (show_debug_regs): Define.
* aarch64-linux-nat.c (debug_hw_points): Don't define. Replace
all uses with show_debug_regs. Replace all uses that considered
debug_hw_points as a multi-value integer with straight boolean
uses.
* x86-nat.c (debug_hw_points): Don't define. Replace all uses
with show_debug_regs.
* nat/x86-dregs.c (debug_hw_points): Don't declare. Replace
all uses with show_debug_regs.
* mips-linux-nat.c (maint_show_dr): Don't define. Replace all
uses with show_debug_regs.
gdb/gdbserver/ChangeLog:
* server.h (debug_hw_points): Don't declare.
* server.c (debug_hw_points): Don't define. Replace all uses
with show_debug_regs.
* linux-aarch64-low.c (debug_hw_points): Don't define. Replace
all uses with show_debug_regs.
Since the last change to address_from_register, it no longer supports
targets that require a special conversion (gdbarch_convert_register_p)
for plain pointer type; I had assumed no target does so.
This turned out to be incorrect: MIPS64 n32 big-endian needs such a
conversion in order to properly sign-extend pointer values.
This patch fixes this regression by handling targets that need a
special conversion in address_from_register as well.
gdb/ChangeLog:
* findvar.c (address_from_register): Handle targets requiring
a special conversion routine even for plain pointer types.
Old AIX versions required GDB to update the stack pointer register and
execute at least one instruction before accessing the space newly allocated
on the user stack. This was done using the exec_one_dummy_insn routine
in rs6000-nat.c
However, in currently supported AIX versions (tested on AIX 6.1), this hack
is no longer necessary. In fact, removing the hack actually fixed several
test case failures, and removes a call to deprecated_insert_raw_breakpoint.
gdb/ChangeLog:
* rs6000-nat.c (exec_one_dummy_insn): Remove.
(store_register): Do not call exec_one_dummy_insn.
Trying to print the bounds or the length of a pointer to an array
whose bounds are dynamic results in the following error:
(gdb) p foo.three_ptr.all'first
Location address is not set.
(gdb) p foo.three_ptr.all'length
Location address is not set.
This is because, after having dereferenced our array pointer, we
use the type of the resulting array value, instead of the enclosing
type. The former is the original type where the bounds are unresolved,
whereas we need to get the actual array bounds.
Similarly, trying to apply those attributes to the array pointer
directly (without explicitly dereferencing it with the '.all'
operator) yields the same kind of error:
(gdb) p foo.three_ptr'first
Location address is not set.
(gdb) p foo.three_ptr'length
Location address is not set.
This is caused by the fact that the dereference was done implicitly
in this case, and perform at the type level only, which is not
sufficient in order to resolve the array type.
This patch fixes both issues, thus allowing us to get the expected output:
(gdb) p foo.three_ptr.all'first
$1 = 1
(gdb) p foo.three_ptr.all'length
$2 = 3
(gdb) p foo.three_ptr'first
$3 = 1
(gdb) p foo.three_ptr'length
$4 = 3
gdb/ChangeLog:
* ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR,
dereference it first. Use value_enclosing_type instead of
value_type.
(ada_array_length): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
Consider a pointer to an array which dynamic bounds, described in
DWARF as follow:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is now able to correctly print the entire array, but not one
element of the array. Eg:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
(gdb) p foo.three_ptr.all(1)
Cannot access memory at address 0xfffffffff4123a0c
The problem occurs because we are missing a dynamic resolution of
the variable's array type when subscripting the array. What the current
code does is "fix"-ing the array type using the GNAT encodings, but
that operation ignores any of the array's dynamic properties.
This patch fixes the issue by using ada_value_ind to dereference
the array pointer, which takes care of the array type resolution.
It also continues to "fix" arrays described using GNAT encodings,
so backwards compatibility is preserved.
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Remove parameter "type".
Adjust function implementation and documentation accordingly.
(ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if
NOSIDE is EVAL_AVOID_SIDE_EFFECTS.
Update call to ada_value_ptr_subscript.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
Consider the following declaration:
type Array_Type is array (Natural range <>) of Integer;
type Array_Ptr is access all Array_Type;
for Array_Ptr'Size use 64;
Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3);
This creates a pointer to an array where the bounds are stored
in a memory region just before the array itself (aka a "thin pointer").
In DWARF, this is described as a the usual pointer type to an array
whose subrange has dynamic values for its bounds:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is currently printing the value of the array incorrectly:
(gdb) p foo.three_ptr.all
$1 = (26629472 => 1, 2,
value.c:819: internal-error: value_contents_bits_eq: [...]
The dereferencing (".all" operator) is done by calling ada_value_ind,
which itself calls value_ind. It first produces a new value where
the bounds of the array were correctly resolved to their actual value,
but then calls readjust_indirect_value_type which replaces the resolved
type by the original type.
The problem starts when ada_value_print does not take this situation
into account, and starts using the type of the resulting value, which
has unresolved array bounds, instead of using the value's enclosing
type.
After fixing this issue, the debugger now correctly prints:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use VAL's enclosing type
instead of VAL's type.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.c: New file.
* gdb.dwarf2/dynarr-ptr.exp: New file.
gdb/ChangeLog:
* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): Pass guile version as
last parameter to pkg-config, not first.
* configure.ac: Pass --with-guile provided pkg-config path to
GDB_GUILE_PROGRAM_NAMES.
* configure: Regenerate.
There are `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' sections
also present in Linux executables, so we can't infer IRIX OS ABI solely
from the existence of these sections. This is not going to be a problem
as there are bound to be other sections whose names start with `.MIPS.'
in IRIX executables and this selection only matters for a non-default OS
ABI in a multiple-target GDB executable. As a last resort the automatic
selection can be overridden with `set osabi'.
* mips-irix-tdep.c (mips_irix_elf_osabi_sniff_abi_tag_sections):
Exclude `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' from
the list of sections determining GDB_OSABI_IRIX.
The trad_frame_set_reg_unknown declaration was added in commit
0db9b4b709 (March 2004), but apparently never defined or referenced.
gdb/ChangeLog:
* trad-frame.h (trad_frame_set_reg_unknown): Remove declaration.
The following patch...
commit 3116063bd6
Date: Fri Jun 27 09:52:29 2014 +0100
Subject: Tidy #include lists
... introduced a build failure on certain x86 GNU/Linux distributions
(reproduced on SuSE 10 and RHES4) due to "struct iovec" not being
defined. This struct is defined in <sys/uio.h>, which used to be
explicitly included, but no longer is after the commit above was
applied.
[...]/i386-linux-nat.c: In function 'fetch_xstateregs':
[...]/i386-linux-nat.c:325:16: error: storage size of 'iov' isn't known
[...]/i386-linux-nat.c: In function 'store_xstateregs':
[...]/i386-linux-nat.c:348:16: error: storage size of 'iov' isn't known
make[2]: *** [i386-linux-nat.o] Error 1
It seems to be working on newer GNU/Linux distros thanks to indirect
inclusion of <sys/uio.h>, but it does not work on some other versions
of the same distros. This is why indirect includes of public APIs
should be avoided if at all possible.
This patch fixes the issue by adding the explicit include back.
gdb/ChangeLog:
* i386-linux-nat.c, x86-linux-nat.c: Add <sys/uio.h> #include.
The problem here is that if a thread other than gdb's main thread
gets a SIGCHLD (it's an asynchronous signal so the kernel will
essentially pick a random thread) then gdb will hang if it is
in sigsuspend when the SIGCHLD is delivered. The other thread
will see the signal and the sigsuspend won't "wake up".
Guile and libgc should be blocking SIGCHLD in their threads,
but we need to work with Guile 2.0 and libgc 7.4.
The problem first shows up in libgc 7.4 because it is the first
release that enables multiple marker threads by default.
gdb/ChangeLog:
PR 17247
* guile.c: #include <signal.h>.
(_initialize_guile): Block SIGCHLD while initializing Guile.
Replaces the following, which is reverted.
2014-07-26 Doug Evans <xdje42@gmail.com>
PR 17185
* configure.ac: Add check for header gc/gc.h.
Add check for function setenv.
* configure: Regenerate.
* config.in: Regenerate.
* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.
gdb/ChangeLog:
* guile/scm-cmd.c (gdbscm_parse_command_name): Replace magic number
with named constant. Fix style of pointer comparison.
* python/py-cmd.c (gdbpy_parse_command_name): Ditto.
have empty bodies.
User-defined commands that have empty bodies weren't being shown because
the print function returned too soon. Now, it prints the command's name
before checking if it has any body at all. This also fixes the same
problem on "show user <myemptycommand>", which wasn't being printed due
to a similar reason.
gdb/Changelog:
* cli/cli-cmds.c (show_user): Use cli_user_command_p to
decide whether we display the command on "show user".
* cli/cli-script.c (show_user_1): Only verify cmdlines after
printing command name.
* cli/cli-decode.h (cli_user_command_p): Declare new function.
* cli/cli-decode.c (cli_user_command_p): Create helper function
to verify whether cmd_list_element is a user-defined command.
gdb/testsuite/Changelog:
* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.
https://bugzilla.redhat.com/show_bug.cgi?id=1126177
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540
T0)
#0 0x992bee in value_type .../gdb/value.c:925
#1 0x87c951 in py_print_single_arg python/py-framefilter.c:445
#2 0x87cfae in enumerate_args python/py-framefilter.c:596
#3 0x87e0b0 in py_print_args python/py-framefilter.c:968
It crashes because frame_arg::val is documented it may contain NULL
(frame_arg::error is then non-NULL) but the code does not handle it.
Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH
which messes up GDB cleanup chain crashing GDB later.
It is probably 7.7 regression (I have not verified it) due to the introduction
of Python frame filters.
gdb/ChangeLog
PR python/17355
* python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL.
Fix goto out of TRY_CATCH.
gdb/testsuite/ChangeLog
PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.
This patch is a fix to PR gdb/17235. The bug is about an unused
variable that got declared and set during one of the parsing phases of
an SDT probe's argument. I took the opportunity to rewrite some of the
code to improve the parsing. The bug was actually a thinko, because
what I wanted to do in the code was to discard the number on the string
being parsed.
During this portion, the code identifies that it is dealing with an
expression that begins with a sign ('+', '-' or '~'). This means that
the expression could be:
- a numeric literal (e.g., '+5')
- a register displacement (e.g., '-4(%rsp)')
- a subexpression (e.g., '-(2*3)')
So, after saving the sign and moving forward 1 char, now the code needs
to know if there is a digit followed by a register displacement prefix
operand (e.g., '(' on x86_64). If yes, then it is a register
operation. If not, then it will be handled recursively, and the code
will later apply the requested operation on the result (either a '+', a
'-' or a '~').
With the bug, the code was correctly discarding the digit (though using
strtol unnecessarily), but it wasn't properly dealing with
subexpressions when the register indirection prefix was '(', like on
x86_64. This patch also fixes this bug, and includes a testcase. It
passes on x86_64 Fedora 20.
valgrind caught that parse_number reads uninitialized memory when we
parse literal "0":
$ valgrind ./gdb -q -nx -ex "set height 0"
(...)
==10378== Conditional jump or move depends on uninitialised value(s)
==10378== at 0x548A10: parse_number (c-exp.y:1828)
==10378== by 0x54A340: lex_one_token (c-exp.y:2638)
==10378== by 0x54B4BB: c_lex (c-exp.y:3089)
==10378== by 0x544951: c_parse_internal (c-exp.c:2208)
==10378== by 0x54BF8C: c_parse (c-exp.y:3260)
==10378== by 0x6502E7: parse_exp_in_context_1 (parse.c:1221)
==10378== by 0x650064: parse_exp_in_context (parse.c:1122)
==10378== by 0x65001F: parse_exp_1 (parse.c:1114)
==10378== by 0x650421: parse_expression (parse.c:1266)
==10378== by 0x5A74B7: parse_and_eval_long (eval.c:92)
==10378== by 0x501ABD: do_set_command (cli-setshow.c:302)
==10378== by 0x721059: execute_command (top.c:452)
==10378==
(gdb)
I've pushed the obvious fix.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
* c-exp.y (parse_number): Skip handling base-switching prefixes if
the input is only one character long.
This commit fixes the PR mentioned in $subject. It is about a set but
unused variable that refers to the output format of integer values
printed in Fortran.
This was probably a thinko (like most set-but-unused-vars), but it
could cause an internal error depending on the scenario. I am sending
a testcase which triggers this error as well.
gdb/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* f-valprint.c (f_val_print): Specify the correct print option to
use when printing integer values.
gdb/testsuite/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* gdb.fortran/print-formatted.exp: New file.
* gdb.fortran/print-formatted.f90: Likewise.
Historically the Linux x86 watchpoint code did not cope with multi-
threaded processes and LWP IDs were passed to it wrapped as PIDs.
Not all entry points were converted when the Linux x86 watchpoint
code was made multi-thread-aware, so a handler was left in place to
cope with wrapped LWPs. Since then all such entry points have been
converted to pass regular LWPs and the handler is now redundant.
This commit removes the handler and adds assertions to ensure no
wrapped LWPs are passed in future.
gdb/ChangeLog:
* x86-linux-nat.c (x86_linux_dr_get, x86_linux_dr_set):
Remove code to cope with LWPs wrapped as PIDs.
Add assertions to ensure no wrapped LWPs are passed.
Git 9a0dc9e3 regressed gdb.dwarf2/pieces-optimized-out.exp, visible on
i686 (the test doesn't run on x86_64):
(gdb) p s
-$1 = {a = 5, b = <optimized out>, c = <optimized out>, d = <optimized out>}
+$1 = {a = 5, b = <optimized out>, c = 0, d = 0}
-(gdb) PASS: gdb.dwarf2/pieces-optimized-out.exp: print s
+(gdb) FAIL: gdb.dwarf2/pieces-optimized-out.exp: print s
The regression was caused by this removal in cp-valprint.c:
@@ -293,12 +293,6 @@ cp_print_value_fields (struct type *type, struct type *real_type,
{
fputs_filtered (_("<synthetic pointer>"), stream);
}
- else if (!value_bits_valid (val,
- TYPE_FIELD_BITPOS (type, i),
- TYPE_FIELD_BITSIZE (type, i)))
- {
- val_print_optimized_out (val, stream);
- }
else
{
struct value_print_options opts = *options;
The idea was that we'd just fallback to calling value_field_bitfield,
which handles unavailable values (in unpack_value_bits_as_long_1) so
should be able to handle optimized out values too. Alas, it doesn't.
This is currently a bit too messy. Instead of teaching
unpack_value_bits_as_long_1 about optimized out bits, let's bite the
bullet and teach the value code to handle partially optimized out
bitfield, by having it unpack a bitfield and then propagate the range
metadata. Turns out the resulting code looks simpler and clearer.
Tested on x86_64 Fedora 20, -m64/-m32.
gdb/ChangeLog:
* value.c (value_ranges_copy_adjusted): New function, factored out
from ...
(value_contents_copy_raw): ... here.
(unpack_value_bits_as_long_1): Rename back to ...
(unpack_bits_as_long): ... this. Remove 'original_value' and
'result' parameters. Change return type to LONGEST.
(unpack_value_bits_as_long): Delete.
(unpack_value_field_as_long_1): Delete.
(unpack_value_field_as_long, unpack_field_as_long): Reimplement.
(unpack_value_bitfield): New function.
(value_field_bitfield): Reimplement using unpack_value_bitfield.
(value_fetch_lazy): Use unpack_value_bitfield.
* value.h (unpack_value_bits_as_long): Delete declaration.
The ability to read registers is needed to use Frame Filter API to
display the frames created by JIT compilers.
gdb/ChangeLog:
2014-08-29 Sasha Smundak <asmundak@google.com>
* python/py-frame.c (frapy_read_register): New function.
gdb/doc/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* python.texi (Frames in Python): Add read_register description.
gdb/testsuite/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* gdb.python/py-frame.exp: Test Frame.read_register.
PTRACE_PEEKUSER can return -1, which is usually used to determine whether
a system call has reported an error, so errno must be used alone to
determine whether an error occurred. However errno isn't modified by a
successful system call so it must be reset to a known value (0) before the
syscall call.
Add the missing errno reset when reading the DSP_CONTROL register in the
native MIPS Linux backend and the MIPS gdbserver backend.
gdb/:
* mips-linux-nat.c (mips_linux_read_description): Reset errno to 0
prior to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.
gdb/gdbserver/:
* linux-mips-low.c (mips_read_description): Reset errno to 0 prior
to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
The loop macro ALL_DEBUG_REGISTERS does not iterate over the status or
control registers, so its name is misleading. This commit renames it
as ALL_DEBUG_ADDRESS_REGISTERS and updates all uses. This commit also
updates its loop conditions to an equivalent but better form, and
makes two functions use it that had previously hardwired the loop.
A comment on a related field in the x86_debug_reg_state structure is
also updated to reflect that the field refers specifically to address
registers only.
gdb/ChangeLog:
* nat/x86-dregs.h (ALL_DEBUG_REGISTERS): Renamed as...
(ALL_DEBUG_ADDRESS_REGISTERS): New macro. All uses updated.
Loop conditions changed to equivalent form.
(struct x86_debug_reg_state): Updated dr_ref_count comment.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.
This commit renames nine files that contain code used by both 32- and
64-bit Intel ports such that their names are prefixed with "x86"
rather than "i386". All types, functions and variables within these
files are likewise renamed such that their names are prefixed with
"x86" rather than "i386". This makes GDB follow the convention used
by gdbserver such that 32-bit Intel code lives in files called
"i386-*", 64-bit Intel code lives in files called "amd64-*", and code
for both 32- and 64-bit Intel lives in files called "x86-*".
This commit only renames OS-independent files. The Linux ports of
both GDB and gdbserver now follow the i386/amd64/x86 convention fully.
Some ports still use the old convention where "i386" in file/function/
type/variable names can mean "32-bit only" or "32- and 64-bit" but I
don't want to touch ports I can't fully test except where absolutely
necessary.
gdb/ChangeLog:
* i386-nat.h: Renamed as...
* x86-nat.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-nat.c: Renamed as...
* x86-nat.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* common/i386-xstate.h: Renamed as...
* common/x86-xstate.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-cpuid.h: Renamed as...
* nat/x86-cpuid.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-gcc-cpuid.h: Renamed as...
* nat/x86-gcc-cpuid.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-dregs.h: Renamed as...
* nat/x86-dregs.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-dregs.c: Renamed as...
* nat/x86-dregs.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
gdb/gdbserver/ChangeLog:
* i386-low.h: Renamed as...
* x86-low.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-low.c: Renamed as...
* x86-low.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
This commit creates a new file, common/gdb_setjmp.h, to hold some
portability macros for setjmp/longjmp et al. that are used by the
exceptions subsystem and by the demangler crash catcher.
gdb/ChangeLog:
* common/gdb_setjmp.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/gdb_setjmp.h.
* configure.ac: Move sigsetjmp check...
* common/common.m4: ...here.
* configure: Regenerate.
* cp-support.c (SIGJMP_BUF): Delete.
(SIGSETJMP): Likewise.
(SIGLONGJMP): Likewise.
* exceptions.h (gdb_setjmp.h): Include.
(setjmp.h): Do not include.
(EXCEPTIONS_SIGJMP_BUF): Delete.
(EXCEPTIONS_SIGSETJMP): Likewise.
(EXCEPTIONS_SIGLONGJMP): Likewise.
Replace all uses of EXCEPTIONS_SIG* macros with SIG* macros
from gdb_setjmp.h.
* exceptions.c: Likewise.
gdb/gdbserver/ChangeLog:
* config.in: Regenerate.
* configure: Likewise.
This commit moves cleanups.[ch] into gdb/common/. The only change to
the content of the files is that cleanups.c's include list was altered
to match its new location.
gdb/ChangeLog:
* cleanups.h: Moved to...
* common/cleanups.h: New file.
* cleanups.c: Moved to...
* common/cleanups.c: New file. Include common-defs.h and
cleanups.h. Do not include defs.h.
* Makefile.in (SFILES): Replace cleanups.c with common/cleanups.c.
(HFILES_NO_SRCDIR): Replace cleanups.h with common/cleanups.h.
(cleanups.o): New rule.
gdb/gdbserver/ChangeLog:
* Makefile.in (SFILES): Add common/cleanups.c.
(OBS): cleanups.o.
(cleanups.o): New rule.
Various warnings are emitted during startup and option-parsing using
fprintf_unfiltered. One warning is prefixed with the command name,
the others are not. This commit replaces these hardwired warnings
with calls to warning. It also sets warning_pre_print to prefix all
warnings with the command name until option parsing is complete.
gdb/ChangeLog:
* main.c (captured_main): Use warning during startup.
Prefix startup warning messages with command name.
This commit replaces the hardwired fprintf/exit error handlers
for usage errors with calls to error.
gdb/ChangeLog:
* main.c (captured_main): Handle usage errors with error.
go32_create_inferior invokes a hardwired fprintf/exit error handler
if v2loadimage fails. I could find no reason for this other than that
the block seems to have been copy-and-pasted from v2loadimage's
manpage. This commit replaces the hardwired handler with a call to
error.
gdb/ChangeLog:
* go32-nat.c (go32_create_inferior): Replace a fprintf/
exit pair with a call to error. Wrap the message with _().
If the requested interpreter cannot be set captured_main reports the
error with a hardwired fprintf/exit pair. A fprintf/exit pair on the
previous line was replaced with a call to error in March 2003
(https://sourceware.org/ml/gdb-patches/2003-03/msg00444.html) but I
found no documentation as to why this particular hardwired handler
was left untouched. I was also unable to come up with a situation
where error would not be suitable, so I have replaced it with a call
to error.
gdb/ChangeLog:
* main.c (captured_main): Replace a fprintf/exit
pair with a call to error. Wrap the message with _().
tui_initialize_io contains a pair of hardwired fprintf/exit error
handlers. I was unable to find any documentation as to why they're
hardwired (the code appeared in a monolithic block back in 2001:
https://sourceware.org/ml/gdb-patches/2001-07/msg00490.html) and I
was also unable to come up with a situation where error would not
be suitable, so I have replaced both handlers with calls to error.
gdb/ChangeLog:
* tui/tui-io.c (tui_initialize_io): Replace two fprintf/exit
pairs with calls to error. Wrap the message with _().
warning will crash if called before the first call to set_width. This
commit makes the warning usable from the moment gdb_stderr is set up.
gdb/ChangeLog:
* utils.c (vwarning): Protect calls to target_terminal_ours
and wrap_here.
error (and other exception-throwing functions) are callable from the
first line of captured_main, but the exception printing code will
crash if called before the first call to set_width. This commit makes
the exception printing code usable from the moment gdb_stderr is set
up.
gdb/ChangeLog:
* exceptions.c (print_flush): Protect calls to
target_terminal_ours and wrap_here.
internal_vproblem can be called (via malloc_failure) from almost the
first line of captured_main, but it will crash if called before the
first call to set_width. This commit makes internal_vproblem work
at any time.
There are two parts to this. If called before gdb_stderr is set up,
internal_vproblem will fall back to printing the message on regular
stderr and aborting. If called after gdb_stderr is set up but before
filtered printing is set up, internal_vproblem will operate as usual
except that it can not query whether to quit and/or dump core so it
defaults to doing both.
gdb/ChangeLog:
* utils.h (filtered_printing_initialized): New declaration.
* utils.c (abort_with_message): New function.
(internal_vproblem): Use abort_with_message for first level
recursive internal problems, and if gdb_stderr is not set up.
Protect calls to target_terminal_ours, begin_line and query.
Hi,
This patch is to handle a software watchpoint case that program returns
to caller's epilogue, and it causes the fail in thumb mode,
finish^M
Run till exit from #0 func () at gdb/testsuite/gdb.base/watchpoint-cond-gone.c:26^M
0x000001f6 in jumper ()^M
(gdb) FAIL: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint
In the test, jumper calls func, and programs returns from func to
jumper's epilogue, IOW, the branch instruction is the last instruction
of jumper's function body.
jumper:
.....
0x000001f2 <+10>: bl 0x200 [1] <---- indirect call to func
0x000001f6 <+14>: mov sp, r7 [2] <---- start of the epilogue
0x000001f8 <+16>: add sp, #8
0x000001fa <+18>: pop {r7}
0x000001fc <+20>: pop {r0}
0x000001fe <+22>: bx r0
When the inferior returns from func back to jumper, it is expected
that an expression of a software watchpoint becomes out-of-scope.
GDB validates the expression by checking the corresponding frame,
but this check is guarded by gdbarch_in_function_epilogue_p. See
breakpoint.c:watchpoint_check.
It doesn't work in this case, because program returns from func's
epilogue back to jumper's epilogue [2], GDB thinks the program is
still within the epilogue, but in fact it goes to a different one.
When PC points at [2], the sp-restore instruction is to be
executed, so the stack frame isn't destroyed yet and we can still
use the frame mechanism reliably.
Note that when PC points to the first instruction of restoring SP,
it is part of epilogue, but we still return zero. When goes to
the next instruction, the backward scan will still match the
epilogue sequence correctly. The reason for doing this is to
handle the "return-to-epilogue" case.
What this patch does is to restrict the epilogue matching that let
GDB think the first SP restore instruction isn't part of the epilogue,
and fall back to use frame mechanism. We set 'found_stack_adjust'
zero before backward scan, and we've done this for arm mode
counterpart (arm_in_function_epilogue_p) too.
The patch is tested in arm-none-eabi and arm-none-linux-gnueabi with
various multilibs. OK to apply?
gdb:
2014-08-28 Yao Qi <yao@codesourcery.com>
* arm-tdep.c (thumb_in_function_epilogue_p): Don't set
found_stack_adjust in forward scan. Remove condition check
on found_stack_adjust which is always true. Indent the code.
Hi,
dwarf_decode_lines is called in two functions,
dwarf2_build_include_psymtabs and handle_DW_AT_stmt_list, in which, 1
is passed to argument 'want_line_info' and 'want_line_info' is a
conditional variable in dwarf_decode_lines. We can simplify it by
removing 'want_line_info' and propagating the constant 1 into
dwarf_decode_lines. This is what this patch does. This patch also
remove one line comment about WANT_LINE_INFO in
handle_DW_AT_stmt_list, as handle_DW_AT_stmt_list doesn't have such
argument.
gdb:
2014-08-28 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Remove comment about WANT_LINE_INFO.
(dwarf_decode_lines): Remove argument
want_line_info. Remove condition check on want_line_info.
Callers update.
