Code in update_dprintf_command_list performed a duplicated memory
allocation which caused an obvious memory leak. This removes the
duplication.
gdb/
2015-04-19 Gabriel Krisman Bertazi <gabriel@krisman.be>
* breakpoint.c (update_dprintf_command_list): Remove duplicated
xmalloc.
Pedro Alves:
The commands that enables aren't even documented in the manual.
Judging from that, I assume that only wdb users would ever really
be using the --xdb switch.
I think it's time to drop "support" for the --xdb switch too. I
looked through the commands that that exposes, the only that looked
potentially interesting was "go", but then it's just an alias
for "tbreak+jump", which can easily be done with "define go...end".
I'd rather free up the "go" name for something potentially
more interesting (either run control, or maybe even unrelated,
e.g., for golang).
gdb/ChangeLog
2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* NEWS (Changes since GDB 7.9): Add removed -xdb.
* breakpoint.c (command_line_is_silent): Remove xdb_commands
conditional.
(_initialize_breakpoint): Remove xdb_commands for bc, ab, sb, db, ba
and lb.
* cli/cli-cmds.c (_initialize_cli_cmds): Remove xdb_commands for v and
va.
* cli/cli-decode.c (find_command_name_length): Remove xdb_commands
conditional.
* defs.h (xdb_commands): Remove declaration.
* f-valprint.c (_initialize_f_valprint): Remove xdb_commands for lc.
* guile/scm-cmd.c (command_classes): Remove xdb from comment.
* infcmd.c (run_no_args_command, go_command): Remove.
(_initialize_infcmd): Remove xdb_commands for S, go, g, R and lr.
* infrun.c (xdb_handle_command): Remove.
(_initialize_infrun): Remove xdb_commands for lz and z.
* main.c (xdb_commands): Remove variable.
(captured_main): Remove "xdb" from long_options.
(print_gdb_help): Remove --xdb from help.
* python/py-cmd.c (gdbpy_initialize_commands): Remove xdb from comment.
* source.c (_initialize_source): Remove xdb_commands for D, ld, / and ?.
* stack.c (backtrace_full_command, args_plus_locals_info)
(current_frame_command): Remove.
(_initialize_stack): Remove xdb_commands for t, T and l.
* symtab.c (_initialize_symtab): Remove xdb_commands for lf and lg.
* thread.c (_initialize_thread): Remove xdb_commands condition.
* tui/tui-layout.c (tui_toggle_layout_command)
(tui_toggle_split_layout_command, tui_handle_xdb_layout): Remove.
(_initialize_tui_layout): Remove xdb_commands for td and ts.
* tui/tui-regs.c (tui_scroll_regs_forward_command)
(tui_scroll_regs_backward_command): Remove.
(_initialize_tui_regs): Remove xdb_commands for fr, gr, sr, +r and -r.
* tui/tui-win.c (tui_xdb_set_win_height_command): Remove.
(_initialize_tui_win): Remove xdb_commands for U and w.
* utils.c (pagination_on_command, pagination_off_command): Remove.
(initialize_utils): Remove xdb_commands for am and sm.
gdb/doc/ChangeLog
2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Mode Options): Remove -xdb.
The "step" parameters of 'proceed' and 'resume' aren't really useful
as indication of whether run control wants to single-step the target,
as that information must already be retrievable from
currently_stepping. In fact, if currently_stepping disagrees with
whether we single-stepped the target, then things break. Thus instead
of having the same information in two places, this patch removes those
parameters.
Setting 'step_start_function' is the only user of proceed's 'step'
argument, other than passing the 'step' argument down to 'resume' and
debug log output. Move that instead to set_step_frame, where we
already set other related fields.
clear_proceed_status keeps its "step" parameter for now because it
needs to know which set of threads should have their state cleared,
and is called before the "stepping_command" flag is set.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* breakpoint.c (until_break_command): Adjust call to proceed.
* gdbthread.h (struct thread_control_state) <stepping_command>:
New field.
* infcall.c (run_inferior_call): Adjust call to proceed.
* infcmd.c (run_command_1, proceed_thread_callback, continue_1):
Adjust calls to proceed.
(set_step_frame): Set the current thread's step_start_function
here.
(step_once): Adjust calls to proceed.
(jump_command, signal_command, until_next_command)
(finish_backward, finish_forward, proceed_after_attach_callback)
(attach_command_post_wait): Adjust calls to proceed.
* infrun.c (proceed_after_vfork_done): Adjust call to proceed.
(do_target_resume): New function, factored out from ...
(resume): ... here. Remove 'step' parameter. Instead, check
currently_stepping to determine whether the thread should be
single-stepped.
(proceed): Remove 'step' parameter and don't set the thread's
step_start_function here. Adjust call to 'resume'.
(handle_inferior_event): Adjust calls to 'resume'.
(switch_back_to_stepped_thread): Use do_target_resume instead of
'resume'.
(keep_going): Adjust calls to 'resume'.
* infrun.h (proceed): Remove 'step' parameter.
(resume): Likewise.
* windows-nat.c (do_initial_windows_stuff): Adjust call to
'resume'.
* mi/mi-main.c (proceed_thread): Adjust call to 'proceed'.
When setting a pending breakpoint with a thread condition while using
the mi interface, the thread condition would be lost by gdb when the breakpoint
was resolved.
This patch fixes this behavior by setting the thread condition properly in the
mi case.
Also, this patch modifies the mi-pending test case to test for this issue and
removes some unneeded code in the testcase and dependency on stdio.
gdb/Changelog:
PR breakpoints/16466
* breakpoint.c (create_breakpoint): Set thread on breakpoint struct.
gdb/testsuite/ChangeLog:
PR breakpoints/16466
* gdb.mi/Makefile.in: Add mi-pendshr2.sl to cleanup.
* gdb.mi/mi-pending.c (thread_func): New function.
(int main): Add threading support required.
* gdb.mi/mi-pending.exp: Add tests for this issue.
* gdb.mi/mi-pendshr.c (pendfunc1): Remove stdio dependency.
(pendfunc2): Remove stdio dependency.
* gdb.mi/mi-pendshr2.c: New file.
This patch changes the heuristic the linespec lexer uses to
detect a keyword in the input stream.
Currently, the heuristic is: a word is a keyword if it
1) points to a string that is a keyword
2) is followed by a non-identifier character
This is strictly more correct than using whitespace. For example,
it allows constructs such as "break foo if(i == 1)". However,
find_condition_and_thread in breakpoint.c does not support this expanded
usage. It requires whitespace to follow the keyword.
The proposed new heuristic is: a word is a keyword if it
1) points to a string that is a keyword
2) is followed by whitespace
3) is not followed by another keyword string followed by whitespace
This additional complexity allows constructs such as
"break thread thread 3" and "break thread 3". In the former case,
the actual location is a symbol named "thread" to be set on thread #3.
In the later case, the location is NULL, i.e., the default location,
to be set on thread #3.
In order to pass all the new tests added here, I've also had to add a
new feature to parse_breakpoint_sals, which expands recognition of the
default location to keywords other than "if", which is the only keyword
currently permitted with the default (NULL) location, but there is no
reason to exclude other keywords.
Consequently, it will be possible to use "break thread 1" or
"break task 1".
In addition to all of this, it is now possible to remove the keyword_ok
state from the linespec parser.
gdb/ChangeLog
* breakpoint.c (parse_breakpoint_sals): Use
linespec_lexer_lex_keyword to ascertain if the user specified
a NULL location.
* linespec.c [IF_KEYWORD_INDEX]: Define.
(linespec_lexer_lex_keyword): Export.
(struct ls_parser) <keyword_ok>: Remove.
A keyword is only a keyword if not followed by another keyword.
(linespec_lexer_lex_one): Remove keyword_ok handling.
Add comment explaining why the parsing stream is not advanced
when a keyword is seen.
(parse_linespec): Remove parser->keyword_ok.
* linespec.h (linespec_lexer_lex_keyword): Add declaration.
gdb/testsuite/ChangeLog
* gdb.linespec/keywords.c: New file.
* gdb.linespec/keywords.exp: New file.
This commits cleans up the gdb/breakpoint.c file and moves everything
that is related to the 'catch syscall' command to the new file
gdb/break-catch-syscall.c. This is just code movement, and the only
new part is the adjustment needed on 'catching_syscall_number' to use
the new 'breakpoint_find_if' function insted of relying on the
ALL_BREAKPOINTS macro.
Tested by running the 'gdb.base/catch-syscall.exp' testcase.
gdb/ChangeLog:
2015-03-11 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): New source break-catch-syscall.c.
(COMMON_OBS): New object break-catch-syscall.o.
* break-catch-syscall.c: New file.
* breakpoint.c: Remove inclusion of "xml-syscall.h".
(syscall_catchpoint_p): Move declaration to break-catch-syscall.c
(struct syscall_catchpoint): Likewise.
(dtor_catch_syscall): Likewise.
(catch_syscall_inferior_data): Likewise.
(struct catch_syscall_inferior_data): Likewise.
(get_catch_syscall_inferior_data): Likewise.
(catch_syscall_inferior_data_cleanup): Likewise.
(insert_catch_syscall): Likewise.
(remove_catch_syscall): Likewise.
(breakpoint_hit_catch_syscall): Likewise.
(print_it_catch_syscall): Likewise.
(print_one_catch_syscall): Likewise.
(print_mention_catch_syscall): Likewise.
(print_recreate_catch_syscall): Likewise.
(catch_syscall_breakpoint_ops): Likewise.
(syscall_catchpoint_p): Likewise.
(create_syscall_event_catchpoint): Likewise.
(catch_syscall_split_args): Likewise.
(catch_syscall_command_1): Likewise.
(is_syscall_catchpoint_enabled): Likewise.
(catch_syscall_enabled): Likewise.
(catching_syscall_number): Likewise.
(catch_syscall_completer): Likewise.
(clear_syscall_counts): Likewise.
(initialize_breakpoint_ops): Move initialization of syscall
catchpoints to break-catch-syscall.c.
(_initialize_breakpoint): Move code related to syscall catchpoints
to break-catch-syscall.c.
This commit implements the 'breakpoint_find_if' function, which allows
code external to gdb/breakpoint.c to iterate through the list of
'struct breakpoint *'. This is needed in order to create the
'gdb/break-catch-syscall.c' file, because one of its functions
(catching_syscall_number) needs to do this iteration.
My first thought was to share the ALL_BREAKPOINTS* macros on
gdb/breakpoint.h, but they use a global variable local to
gdb/breakpoint.c, and I did not want to share that variable. So, in
order to keep the minimal separation, I decided to implement this
way of iterating through the existing 'struct breakpoint *'.
This function was based on BFD's bfd_sections_find_if. If the
user-provided function returns 0, the iteration proceeds. Otherwise,
the iteration stops and the function returns the 'struct breakpoint *'
that is being processed. This means that the return value of this
function can be either NULL or a pointer to a 'struct breakpoint'.
gdb/ChangeLog:
2015-03-11 Sergio Durigan Junior <sergiodj@redhat.com>
* breakpoint.c (breakpoint_find_if): New function.
* breakpoint.h (breakpoint_find_if): New prototype.
All these were caught by actually making TRY/CATCH use try/catch
behind the scenes, which then resulted in the build failing (on x86_64
Fedora 20) because there was code between the try and catch blocks.
gdb/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
* breakpoint.c (save_breakpoints): Adjust to avoid code between
TRY and CATCH.
* gdbtypes.c (safe_parse_type): Remove empty line.
(types_deeply_equal):
* guile/scm-frame.c (gdbscm_frame_name):
* linux-thread-db.c (find_new_threads_once):
* python/py-breakpoint.c (bppy_get_commands):
* record-btrace.c (record_btrace_insert_breakpoint)
(record_btrace_remove_breakpoint, record_btrace_start_replaying)
(record_btrace_start_replaying): Adjust to avoid code between TRY
and CATCH.
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
This commit introduces a new inline common function "startswith"
which takes two string arguments and returns nonzero if the first
string starts with the second. It also updates the 295 places
where this logic was written out longhand to use the new function.
gdb/ChangeLog:
* common/common-utils.h (startswith): New inline function.
All places where this logic was used updated to use the above.
The moribund locations heuristics are problematic. This patch teaches
GDB about targets that can reliably tell whether a trap was caused by
a software or hardware breakpoint, and thus don't need moribund
locations, thus bypassing all the problems that mechanism has.
The non-stop-fair-events.exp test is frequently failing currently.
E.g., see https://sourceware.org/ml/gdb-testers/2015-q1/msg03148.html.
The root cause is a fundamental problem with moribund locations. For
example, the stepped_breakpoint logic added by af48d08f breaks in this
case (which is what happens with that test):
- Step thread A, no breakpoint is set at PC.
- The kernel doesn't schedule thread A yet.
- Insert breakpoint at A's PC, for some reason (e.g., a step-resume
breakpoint for thread B).
- Kernel finally schedules thread A.
- thread A's stepped_breakpoint flag is not set, even though it now
stepped a breakpoint instruction.
- adjust_pc_after_break gets the PC wrong, because PC == PREV_PC, but
stepped_breakpoint is not set.
We needed the stepped_breakpoint logic to workaround moribund
locations, because otherwise adjust_pc_after_break could apply an
adjustment when it shouldn't just because there _used_ to be a
breakpoint at PC (a moribund breakpoint location). For example, on
x86, that's wrong if the thread really hasn't executed an int3, but
instead executed some other 1-byte long instruction. Getting the PC
adjustment wrong of course leads to the inferior executing the wrong
instruction.
Other problems with moribund locations are:
- if a true SIGTRAP happens to be raised when the program is
executing the PC that used to have a breakpoint, GDB will assume
that is a trap for a breakpoint that has recently been removed, and
thus we miss reporting the random signal to the user.
- to minimize that, we get rid of moribund location after a while.
That while is defined as just a certain number of events being
processed. That number of events sometimes passes by before a
delayed breakpoint is processed, and GDB confuses the trap for a
random signal, thus reporting the random trap. Once the user
resumes the thread, the program crashes because the PC was not
adjusted...
The fix for all this is to bite the bullet and get rid of heuristics
and instead rely on the target knowing accurately what caused the
SIGTRAP. The target/kernel/stub is in the best position to know what
that, because it can e.g. consult priviledged CPU flags GDB has no
access to, or by knowing which exception vector entry was called when
the instruction trapped, etc. Most debug APIs I've seen to date
report breakpoint hits as a distinct event in some fashion. For
example, on the Linux kernel, whether a breakpoint was executed is
exposed to userspace in the si_code field of the SIGTRAP's siginfo.
On Windows, the debug API reports a EXCEPTION_BREAKPOINT exception
code.
We needed to keep around deleted breakpoints in an on-the-side list
(the moribund locations) for two main reasons:
- Know that a SIGTRAP actually is a delayed event for a hit of a
breakpoint that was removed before the event was processed, and
thus should not be reported as a random signal.
- So we still do the decr_pc_after_break adjustment in that case, so
that the thread is resumed at the correct address.
In the new model, if GDB processes an event the target tells is a
breakpoint trap, and GDB doesn't find the corresponding breakpoint in
its breakpoint tables, it means that event is a delayed event for a
breakpoint that has since been removed, and thus the event should be
ignored.
For the decr_pc_after_after issue, it ends up being much simpler that
on targets that can reliably tell whether a breakpoint trapped, for
the breakpoint trap to present the PC already adjusted. Proper
multi-threading support already implies that targets needs to be doing
decr_pc_after_break adjustment themselves, otherwise for example, in
all-stop if two threads hit a breakpoint simultaneously, and the user
does "info threads", he'll see the non-event thread that hit the
breakpoint stopped at the wrong PC.
This way (target adjusts) also ends up eliminating the need for some
awkward re-incrementing of the PC in the record-full and Linux targets
that we do today, and the need for the target_decr_pc_after_break
hook.
If the target always adjusts, then there's a case where GDB needs to
re-increment the PC. Say, on x86, an "int3" instruction that was
explicitly written in the program traps. In this case, GDB should
report a random SIGTRAP signal to the user, with the PC pointing at
the instruction past the int3, just like if GDB was not debugging the
program. The user may well decide to pass the SIGTRAP to the program
because the program being debugged has a SIGTRAP handler that handles
its own breakpoints, and expects the PC to be unadjusted.
Tested on x86-64 Fedora 20.
gdb/ChangeLog:
2015-03-04 Pedro Alves <palves@redhat.com>
* breakpoint.c (need_moribund_for_location_type): New function.
(bpstat_stop_status): Don't skipping checking moribund locations
of breakpoint types which the target tell caused a stop.
(program_breakpoint_here_p): New function, factored out from ...
(bp_loc_is_permanent): ... this.
(update_global_location_list): Don't create a moribund location if
the target supports reporting stops of the type of the removed
breakpoint.
* breakpoint.h (program_breakpoint_here_p): New declaration.
* infrun.c (adjust_pc_after_break): Return early if the target has
already adjusted the PC. Add comments.
(handle_signal_stop): If nothing explains a signal, and the target
tells us the stop was caused by a software breakpoint, check if
there's a breakpoint instruction in the memory. If so, adjust the
PC before presenting the stop to the user. Otherwise, ignore the
trap. If nothing explains a signal, and the target tells us the
stop was caused by a hardware breakpoint, ignore the trap.
* target.h (struct target_ops) <to_stopped_by_sw_breakpoint,
to_supports_stopped_by_sw_breakpoint, to_stopped_by_hw_breakpoint,
to_supports_stopped_by_hw_breakpoint>: New fields.
(target_stopped_by_sw_breakpoint)
(target_supports_stopped_by_sw_breakpoint)
(target_stopped_by_hw_breakpoint)
(target_supports_stopped_by_hw_breakpoint): Define.
* target-delegates.c: Regenerate.
This patch adds a new type of probe to GDB: the DTrace USDT probes. The new
type is added by providing functions implementing all the entries of the
`probe_ops' structure defined in `probe.h'. The implementation is
self-contained and does not depend on DTrace source code in any way.
gdb/ChangeLog:
2015-02-7 Jose E. Marchesi <jose.marchesi@oracle.com>
* breakpoint.c (BREAK_ARGS_HELP): Help string updated to mention
the -probe-dtrace new vpossible value for PROBE_MODIFIER.
* configure.ac (CONFIG_OBS): dtrace-probe.o added if BFD can
handle ELF files.
* Makefile.in (SFILES): dtrace-probe.c added.
* configure: Regenerate.
* dtrace-probe.c: New file.
(SHT_SUNW_dof): New constant.
(dtrace_probe_type): New enum.
(dtrace_probe_arg): New struct.
(dtrace_probe_arg_s): New typedef.
(struct dtrace_probe_enabler): New struct.
(dtrace_probe_enabler_s): New typedef.
(dtrace_probe): New struct.
(dtrace_probe_is_linespec): New function.
(dtrace_dof_sect_type): New enum.
(dtrace_dof_dofh_ident): Likewise.
(dtrace_dof_encoding): Likewise.
(DTRACE_DOF_ENCODE_LSB): Likewise.
(DTRACE_DOF_ENCODE_MSB): Likewise.
(dtrace_dof_hdr): New struct.
(dtrace_dof_sect): Likewise.
(dtrace_dof_provider): Likewise.
(dtrace_dof_probe): Likewise.
(DOF_UINT): New macro.
(DTRACE_DOF_PTR): Likewise.
(DTRACE_DOF_SECT): Likewise.
(dtrace_process_dof_probe): New function.
(dtrace_process_dof): Likewise.
(dtrace_build_arg_exprs): Likewise.
(dtrace_get_arg): Likewise.
(dtrace_get_probes): Likewise.
(dtrace_get_probe_argument_count): Likewise.
(dtrace_can_evaluate_probe_arguments): Likewise.
(dtrace_evaluate_probe_argument): Likewise.
(dtrace_compile_to_ax): Likewise.
(dtrace_probe_destroy): Likewise.
(dtrace_gen_info_probes_table_header): Likewise.
(dtrace_gen_info_probes_table_values): Likewise.
(dtrace_probe_is_enabled): Likewise.
(dtrace_probe_ops): New variable.
(info_probes_dtrace_command): New function.
(_initialize_dtrace_probe): Likewise.
(dtrace_type_name): Likewise.
In C, we can forward declare static structure instances. That doesn't
work in C++ though. C++ treats these as definitions. So then the
compiler complains about symbol redefinition, like:
src/gdb/elfread.c:1569:29: error: redefinition of ‘const sym_fns elf_sym_fns_lazy_psyms’
src/gdb/elfread.c:53:29: error: ‘const sym_fns elf_sym_fns_lazy_psyms’ previously declared here
The intent of static here is naturally to avoid making these objects
visible outside the compilation unit. The equivalent in C++ would be
to instead define the objects in the anonymous namespace. But given
that it's desirable to leave the codebase compiling as both C and C++
for a while, this just makes the objects extern.
(base_breakpoint_ops is already declared in breakpoint.h, so we can
just remove the forward declare from breakpoint.c)
gdb/ChangeLog:
2015-02-11 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
* breakpoint.c (base_breakpoint_ops): Delete.
* dwarf2loc.c (dwarf_expr_ctx_funcs): Make extern.
* elfread.c (elf_sym_fns_gdb_index, elf_sym_fns_lazy_psyms): Make extern.
* guile/guile.c (guile_extension_script_ops, guile_extension_ops): Make extern.
* ppcnbsd-tdep.c (ppcnbsd2_sigtramp): Make extern.
* python/py-arch.c (arch_object_type): Make extern.
* python/py-block.c (block_syms_iterator_object_type): Make extern.
* python/py-bpevent.c (breakpoint_event_object_type): Make extern.
* python/py-cmd.c (cmdpy_object_type): Make extern.
* python/py-continueevent.c (continue_event_object_type)
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Remove 'qual'
parameter. Update all callers.
* python/py-evtregistry.c (eventregistry_object_type): Make extern.
* python/py-exitedevent.c (exited_event_object_type): Make extern.
* python/py-finishbreakpoint.c (finish_breakpoint_object_type): Make extern.
* python/py-function.c (fnpy_object_type): Make extern.
* python/py-inferior.c (inferior_object_type, membuf_object_type): Make extern.
* python/py-infevents.c (call_pre_event_object_type)
(inferior_call_post_event_object_type).
(memory_changed_event_object_type): Make extern.
* python/py-infthread.c (thread_object_type): Make extern.
* python/py-lazy-string.c (lazy_string_object_type): Make extern.
* python/py-linetable.c (linetable_entry_object_type)
(linetable_object_type, ltpy_iterator_object_type): Make extern.
* python/py-newobjfileevent.c (new_objfile_event_object_type)
(clear_objfiles_event_object_type): Make extern.
* python/py-objfile.c (objfile_object_type): Make extern.
* python/py-param.c (parmpy_object_type): Make extern.
* python/py-progspace.c (pspace_object_type): Make extern.
* python/py-signalevent.c (signal_event_object_type): Make extern.
* python/py-symtab.c (symtab_object_type, sal_object_type): Make extern.
* python/py-type.c (type_object_type, field_object_type)
(type_iterator_object_type): Make extern.
* python/python.c (python_extension_script_ops)
(python_extension_ops): Make extern.
* stap-probe.c (stap_probe_ops): Make extern.
Typing "enable count" by itself crashes GDB. Also, if you omit the
breakpoint number/range, the error message is not very clear:
(gdb) enable count 2
warning: bad breakpoint number at or near ''
(gdb) enable count
Segmentation fault (core dumped)
With this patch, the error messages are slightly more helpful:
(gdb) enable count 2
Argument required (one or more breakpoint numbers).
(gdb) enable count
Argument required (hit count).
gdb/ChangeLog:
PR gdb/15678
* breakpoint.c (map_breakpoint_numbers): Check for empty args
string.
(enable_count_command): Check args for NULL value.
gdb/testsuite/ChangeLog:
PR gdb/15678
* gdb.base/ena-dis-br.exp: Test "enable count" for bad user input.
Executing a gdb script that runs the inferior (from the command line
with -x), and has it hit breakpoints with breakpoint commands that
themselves run the target, is currently broken on async targets
(Linux, remote).
While we're executing a command list or a script, we force the
interpreter to be sync, which results in some functions nesting an
event loop and waiting for the target to stop, instead of returning
immediately and having the top level event loop handle the stop.
The issue with this bug is simply that bpstat_do_actions misses
checking whether the interpreter is sync. When we get here, in the
case of executing a script (or, when the interpreter is sync), the
program has already advanced to the next breakpoint, through
maybe_wait_sync_command_done. We need to process its breakpoints
immediately, just like with a sync target.
Tested on x86_64 Fedora 20.
gdb/
2015-01-14 Pedro Alves <palves@redhat.com>
PR gdb/17525
* breakpoint.c: Include "interps.h".
(bpstat_do_actions_1): Also check whether the interpreter is
async.
gdb/testsuite/
2015-01-14 Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
PR gdb/17525
* gdb.base/bp-cmds-execution-x-script.c: New file.
* gdb.base/bp-cmds-execution-x-script.exp: New file.
* gdb.base/bp-cmds-execution-x-script.gdb: New file.
Running the testsuite with a series that reimplements user-visible
all-stop behavior on top of a target running in non-stop mode revealed
problems related to event starvation avoidance.
For example, I see
gdb.threads/signal-while-stepping-over-bp-other-thread.exp failing.
What happens is that GDB core never gets to see the signal event. It
ends up processing the events for the same threads over an over,
because Linux's waitpid(-1, ...) returns that first task in the task
list that has an event, starving threads on the tail of the task list.
So I wrote a non-stop mode test originally inspired by
signal-while-stepping-over-bp-other-thread.exp, to stress this
independently of all-stop on top of non-stop. Fixing it required the
changes described below. The test will be added in a following
commit.
1) linux-nat.c has code in place that picks an event LWP at random out
of all that have had events. This is because on the kernel side,
"waitpid(-1, ...)" just walks the task list linearly looking for the
first that had an event. But, this code is currently only used in
all-stop mode. So with a multi-threaded program that has multiple
events triggering debug events in parallel, GDB ends up starving some
threads.
To make the event randomization work in non-stop mode too, the patch
makes us pull out all the already pending events on the kernel side,
with waitpid, before deciding which LWP to report to the core.
There's some code in linux_wait that takes care of leaving events
pending if they were for LWPs the caller is not interested in. The
patch moves that to linux_nat_filter_event, so that we only have one
place that leaves events pending. With that in place, conceptually,
the flow is simpler and more normalized:
#1 - walk the LWP list looking for an LWP with a pending event to report.
#2 - if no pending event, pull events out of the kernel, and store
them in the LWP structures as pending.
#3- goto #1.
2) Then, currently the event randomization code only considers SIGTRAP
(or trap-like) events. That means that if e.g., have have multiple
threads stepping in parallel that hit a breakpoint that needs stepping
over, and one gets a signal, the signal may end up never getting
processed, because GDB will always be giving priority to the SIGTRAPs.
The patch fixes this by making the randomization code consider all
kinds of pending events.
3) If multiple threads hit a breakpoint, we report one of those, and
"cancel" the others. Cancelling means decrementing the PC, and
discarding the event. If the next time the LWP is resumed the
breakpoint is still installed, the LWP should hit it again, and we'll
report the hit then. The problem I found is that this delays threads
from advancing too much, with the kernel potentially ending up
scheduling the same threads over and over, and others not advancing.
So the patch switches away from cancelling the breakpoints, and
instead remembering that the LWP had stopped for a breakpoint. If on
resume the breakpoint is still installed, we report it. If it's no
longer installed, we discard the pending event then. This is actually
how GDBserver used to handle this before d50171e4 (Teach linux
gdbserver to step-over-breakpoints), but with the difference that back
then we'd delay adjusting the PC until resuming, which made it so that
"info threads" could wrongly see threads with unadjusted PCs.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (hardware_breakpoint_inserted_here_p): New
function.
* breakpoint.h (hardware_breakpoint_inserted_here_p): New
declaration.
* linux-nat.c (linux_nat_status_is_event): Move higher up in file.
(linux_resume_one_lwp): Store the thread's PC. Adjust to clear
stop_reason.
(check_stopped_by_watchpoint): New function.
(save_sigtrap): Reimplement.
(linux_nat_stopped_by_watchpoint): Adjust.
(linux_nat_lp_status_is_event): Delete.
(stop_wait_callback): Only call save_sigtrap after storing the
pending status.
(status_callback): If the thread had been stopped for a breakpoint
that has since been removed, discard the event and resume the LWP.
(count_events_callback, select_event_lwp_callback): Use
lwp_status_pending_p instead of linux_nat_lp_status_is_event.
(cancel_breakpoint): Rename to ...
(check_stopped_by_breakpoint): ... this. Record whether the LWP
stopped for a software breakpoint or hardware breakpoint.
(select_event_lwp): Only give preference to the stepping LWP in
all-stop mode. Adjust comments.
(stop_and_resume_callback): Remove references to new_pending_p.
(linux_nat_filter_event): Likewise. Leave exit events of the
leader thread pending here. Handle signal short circuiting here.
Only call save_sigtrap after storing the pending waitstatus.
(linux_nat_wait_1): Remove 'retry' label. Remove references to
new_pending. Don't handle leaving events the caller is not
interested in pending here, nor handle signal short-circuiting
here. Also give equal priority to all LWPs that have had events
in non-stop mode. If reporting a software breakpoint event,
unadjust the LWP's PC.
* linux-nat.h (enum lwp_stop_reason): New.
(struct lwp_info) <stop_pc>: New field.
(struct lwp_info) <stopped_by_watchpoint>: Delete field.
(struct lwp_info) <stop_reason>: New field.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Adjust.
Factor out common code, and use the more efficient
ALL_BP_LOCATIONS_AT_ADDR.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (bp_location_inserted_here_p): New function,
factored out from ...
(breakpoint_inserted_here_p): ... here. Use
ALL_BP_LOCATIONS_AT_ADDR.
(software_breakpoint_inserted_here_p): Use
bp_location_inserted_here_p and ALL_BP_LOCATIONS_AT_ADDR.
On Linux native, if dprintfs are inserted when detaching, they are left
in the inferior which causes it to crash from a SIGTRAP. It also happens
with dprintfs on remote targets, when set disconnected-dprintf is off.
The rationale of the line modified by the patch was to leave dprintfs
inserted in order to support disconnected dprintfs. However, not all
dprintfs are persistent. Also, there's no reason other kinds of
breakpoints can't be persistent either. So this replaces the bp_dprintf
check with a check on whether the location is persistent.
bl->target_info.persist will be 1 only if disconnected-dprintf is on and
we are debugging a remote target. On native, it will always be 0,
regardless of the value of disconnected-dprintf. This makes sense, since
disconnected dprintfs are not supported by the native target.
One issue about the test is that it does not pass when using
--target_board=native-extended-gdbserver, partly due to bug 17302 [1].
One quick hack I tried for this was to add a useless "next" between the
call to getpid() and detach, which avoids the bug. There is still one
case where the test fails, and that is with:
- breakpoint always-inserted on
- dprintf-style agent
- disconnected-dprintf on
What happens is that my detach does not actually detach the process,
because some persistent commands (the disconnected dprintf) is present.
However since gdbserver is ran with --once, when gdb disconnects,
gdbserver goes down and takes with it all the processes it spawned and
that are still under its control (which includes my test process).
When the test checks if the test process is still alive, it obvisouly
fails. Investigating about that led me to ask a question on the ML [2]
about the behavior of detach.
Until the remote case is sorted out, the problematic test is marked as
KFAIL.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17302
[2] https://sourceware.org/ml/gdb/2014-08/msg00115.html
gdb/Changelog:
PR breakpoints/17012
* breakpoint.c (remove_breakpoints_pid): Skip removing
breakpoint if it is marked as persistent.
gdb/testsuite/ChangeLog:
PR breakpoints/17012
* gdb.base/dprintf-detach.c: New file.
* gdb.base/dprintf-detach.exp: New file.
A recent change...
commit 1a853c5224
Date: Wed Nov 12 10:10:49 2014 +0000
Subject: make "permanent breakpoints" per location and disableable
... broke function calls on sparc-elf when running over QEMU. Any
function call should demonstrate the problem.
For instance, seen from the debugger:
(gdb) call pn(1234)
[Inferior 1 (Remote target) exited normally]
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
And seen from QEMU:
qemu: fatal: Trap 0x02 while interrupts disabled, Error state
[register dump removed]
What happens in this case is that GDB sets the inferior function call
by not only creating the dummy frame, but also writing a breakpoint
instruction at the return address for our function call. See infcall.c:
/* Write a legitimate instruction at the point where the infcall
breakpoint is going to be inserted. While this instruction
is never going to be executed, a user investigating the
memory from GDB would see this instruction instead of random
uninitialized bytes. We chose the breakpoint instruction
as it may look as the most logical one to the user and also
valgrind 3.7.0 needs it for proper vgdb inferior calls.
If software breakpoints are unsupported for this target we
leave the user visible memory content uninitialized. */
bp_addr_as_address = bp_addr;
bp_bytes = gdbarch_breakpoint_from_pc (gdbarch, &bp_addr_as_address,
&bp_size);
if (bp_bytes != NULL)
write_memory (bp_addr_as_address, bp_bytes, bp_size);
This instruction triggers a change introduced by the commit above,
where we consider bp locations as being permanent breakpoints
if there is already a breakpoint instruction at that address:
+ if (bp_loc_is_permanent (loc))
+ {
+ loc->inserted = 1;
+ loc->permanent = 1;
+ }
As a result, when resuming the program's execution for the inferior
function call, GDB decides that it does not need to insert a breakpoint
at this address, expecting the target to just report a SIGTRAP when
trying to execute that instruction.
But unfortunately for us, at least some versions of QEMU for SPARC
just terminate the execution entirely instead of reporting a breakpoint,
thus producing the behavior reported here.
Although it appears like QEMU might be misbehaving and should therefore
be fixed (to be verified) from the user's point of view, the recent
change does introduce a regression. So this patch tries to mitigate
a bit the damage by handling such infcall breakpoints as special and
making sure that they are never considered permanent, thus restoring
the previous behavior specifically for those breakpoints.
The option of not writing the breakpoint instructions in the first
place was considered, and would probably work also. But the comment
associated to it seems to indicate that there is still reason to
keep it.
gdb/ChangeLog:
* breakpoint.c (bp_loc_is_permanent): Return 0 if LOC corresponds
to a bp_call_dummy breakpoint type.
Tested on x86_64-linux. Also testing on sparc-elf/QEMU using
AdaCore's testsuite.
This patch intends to partially fix PR breakpoints/10737, which is
about making the syscall information (for the "catch syscall" command)
be per-arch, instead of global. This is not a full fix because of the
other issues pointed by Pedro here:
<https://sourceware.org/bugzilla/show_bug.cgi?id=10737#c5>
However, I consider it a good step towards the real fix. It will also
help me fix <https://sourceware.org/bugzilla/show_bug.cgi?id=17402>.
What this patch does, basically, is move the "syscalls_info"
struct to gdbarch. Currently, the syscall information is stored in a
global variable inside gdb/xml-syscall.c, which means that there is no
easy way to correlate this info with the current target or
architecture being used, for example. This causes strange behaviors,
because the syscall info is not re-read when the arch changes. For
example, if you put a syscall catchpoint in syscall 5 on i386 (syscall
open), and then load a x86_64 program on GDB and put the same syscall
5 there (fstat on x86_64), you will still see that GDB tells you that
it is catching "open", even though it is not. With this patch, GDB
correctly says that it will be catching fstat syscalls.
(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'open' [5])
But with the patch:
(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'fstat' [5])
As I said, there are still some problems on the "catch syscall"
mechanism, because (for example) the user should be able to "catch
syscall open" on i386, and then expect "open" to be caught also on
x86_64. Currently, it doesn't work. I intend to work on this later.
gdb/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Adjust call to
set_xml_syscall_file_name to provide gdbarch.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* bfin-linux-tdep.c (bfin_linux_init_abi): Likewise.
* breakpoint.c (print_it_catch_syscall): Adjust call to
get_syscall_by_number to provide gdbarch.
(print_one_catch_syscall): Likewise.
(print_mention_catch_syscall): Likewise.
(print_recreate_catch_syscall): Likewise.
(catch_syscall_split_args): Adjust calls to get_syscall_by_number
and get_syscall_by_name to provide gdbarch.
(catch_syscall_completer): Adjust call to get_syscall_names to
provide gdbarch.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* gdbarch.sh: Forward declare "struct syscalls_info".
(xml_syscall_file): New variable.
(syscalls_info): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Adjust call to
set_xml_syscall_file_name to provide gdbarch.
* mips-linux-tdep.c (mips_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_gdbarch_init): Likewise.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise.
* xml-syscall.c: Include gdbarch.h.
(set_xml_syscall_file_name): Accept gdbarch parameter.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
(my_gdb_datadir): Delete global variable.
(struct syscalls_info) <my_gdb_datadir>: New variable.
(struct syscalls_info) <sysinfo>: Rename variable to
"syscalls_info".
(sysinfo): Delete global variable.
(have_initialized_sysinfo): Likewise.
(xml_syscall_file): Likewise.
(sysinfo_free_syscalls_desc): Rename to...
(syscalls_info_free_syscalls_desc): ... this.
(free_syscalls_info): Rename "sysinfo" to "syscalls_info". Adjust
code to the new layout of "struct syscalls_info".
(make_cleanup_free_syscalls_info): Rename parameter "sysinfo" to
"syscalls_info".
(syscall_create_syscall_desc): Likewise.
(syscall_start_syscall): Likewise.
(syscall_parse_xml): Likewise.
(xml_init_syscalls_info): Likewise. Drop "const" from return value.
(init_sysinfo): Rename to...
(init_syscalls_info): ...this. Add gdbarch as a parameter.
Adjust function to deal with gdbarch.
(xml_get_syscall_number): Delete parameter sysinfo. Accept
gdbarch as a parameter. Adjust code.
(xml_get_syscall_name): Likewise.
(xml_list_of_syscalls): Likewise.
(set_xml_syscall_file_name): Accept gdbarch as parameter.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
* xml-syscall.h (set_xml_syscall_file_name): Likewise.
(get_syscall_by_number): Likewise.
(get_syscall_by_name): Likewise.
(get_syscall_names): Likewise.
gdb/testsuite/
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* gdb.base/catch-syscall.exp (do_syscall_tests): Call
test_catch_syscall_multi_arch.
(test_catch_syscall_multi_arch): New function.
Currently "symtabs" in gdb are stored as a single linked list of
struct symtab that contains both symbol symtabs (the blockvectors)
and file symtabs (the linetables).
This has led to confusion, bugs, and performance issues.
This patch is conceptually very simple: split struct symtab into
two pieces: one part containing things common across the entire
compilation unit, and one part containing things specific to each
source file.
Example.
For the case of a program built out of these files:
foo.c
foo1.h
foo2.h
bar.c
foo1.h
bar.h
Today we have a single list of struct symtabs:
objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL
where "->" means the "next" pointer in struct symtab.
With this patch, that turns into:
objfile -> foo.c(cu) -> bar.c(cu) -> NULL
| |
v v
foo.c bar.c
| |
v v
foo1.h foo1.h
| |
v v
foo2.h bar.h
| |
v v
NULL NULL
where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects,
and the files foo.c, etc. are struct symtab objects.
So now, for example, when we want to iterate over all blockvectors
we can now just iterate over the compunit_symtab list.
Plus a lot of the data that was either unused or replicated for each
symtab in a compilation unit now lives in struct compunit_symtab.
E.g., the objfile pointer, the producer string, etc.
I thought of moving "language" out of struct symtab but there is
logic to try to compute the language based on previously seen files,
and I think that's best left as is for now.
With my standard monster benchmark with -readnow (which I can't actually
do, but based on my calculations), whereas today the list requires
77MB to store all the struct symtabs, it now only requires 37MB.
A modest space savings given the gigabytes needed for all the debug info,
etc. Still, it's nice. Plus, whereas today we create a copy of dirname
for each source file symtab in a compilation unit, we now only create one
for the compunit.
So this patch is basically just a data structure reorg,
I don't expect significant performance improvements from it.
Notes:
1) A followup patch can do a similar split for struct partial_symtab.
I have left that until after I get the changes I want in to
better utilize .gdb_index (it may affect how we do partial syms).
2) Another followup patch *could* rename struct symtab.
The term "symtab" is ambiguous and has been a source of confusion.
In this patch I'm leaving it alone, calling it the "historical" name
of "filetabs", which is what they are now: just the file-name + line-table.
gdb/ChangeLog:
Split struct symtab into two: struct symtab and compunit_symtab.
* amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit.
* block.c (blockvector_for_pc_sect): Change "struct symtab *" argument
to "struct compunit_symtab *". All callers updated.
(set_block_compunit_symtab): Renamed from set_block_symtab. Change
"struct symtab *" argument to "struct compunit_symtab *".
All callers updated.
(get_block_compunit_symtab): Renamed from get_block_symtab. Change
result to "struct compunit_symtab *". All callers updated.
(find_iterator_compunit_symtab): Renamed from find_iterator_symtab.
Change result to "struct compunit_symtab *". All callers updated.
* block.h (struct global_block) <compunit_symtab>: Renamed from symtab.
hange type to "struct compunit_symtab *". All uses updated.
(struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab".
Change type to "struct compunit_symtab *". All uses updated.
* buildsym.c (struct buildsym_compunit): New struct.
(subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete.
(buildsym_compunit): New static global.
(finish_block_internal): Update to fetch objfile from
buildsym_compunit.
(make_blockvector): Delete objfile argument.
(start_subfile): Rewrite to use buildsym_compunit. Don't initialize
debugformat, producer.
(start_buildsym_compunit): New function.
(free_buildsym_compunit): Renamed from free_subfiles_list.
All callers updated.
(patch_subfile_names): Rewrite to use buildsym_compunit.
(get_compunit_symtab): New function.
(get_macro_table): Delete argument comp_dir. All callers updated.
(start_symtab): Change result to "struct compunit_symtab *".
All callers updated. Create the subfile of the main source file.
(watch_main_source_file_lossage): Rewrite to use buildsym_compunit.
(reset_symtab_globals): Update.
(end_symtab_get_static_block): Update to use buildsym_compunit.
(end_symtab_without_blockvector): Rewrite.
(end_symtab_with_blockvector): Change result to
"struct compunit_symtab *". All callers updated.
Update to use buildsym_compunit. Don't set symtab->dirname,
instead set it in the compunit.
Explicitly make sure main symtab is first in its list.
Set debugformat, producer, blockvector, block_line_section, and
macrotable in the compunit.
(end_symtab_from_static_block): Change result to
"struct compunit_symtab *". All callers updated.
(end_symtab, end_expandable_symtab): Ditto.
(set_missing_symtab): Change symtab argument to
"struct compunit_symtab *". All callers updated.
(augment_type_symtab): Ditto.
(record_debugformat): Update to use buildsym_compunit.
(record_producer): Update to use buildsym_compunit.
* buildsym.h (struct subfile) <dirname>: Delete.
<producer, debugformat>: Delete.
<buildsym_compunit>: New member.
(get_compunit_symtab): Declare.
* dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed
from primary_symtab. Change type to "struct compunit_symtab *".
All uses updated.
(dwarf2_start_symtab): Change result to "struct compunit_symtab *".
All callers updated.
(dwarf_decode_macros): Delete comp_dir argument. All callers updated.
(struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from
symtab. Change type to "struct compunit_symtab *". All uses updated.
(dw2_instantiate_symtab): Change result to "struct compunit_symtab *".
All callers updated.
(dw2_find_last_source_symtab): Ditto.
(dw2_lookup_symbol): Ditto.
(recursively_find_pc_sect_compunit_symtab): Renamed from
recursively_find_pc_sect_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(dw2_find_pc_sect_compunit_symtab): Renamed from
dw2_find_pc_sect_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(get_compunit_symtab): Renamed from get_symtab. Change result to
"struct compunit_symtab *". All callers updated.
(recursively_compute_inclusions): Change type of immediate_parent
argument to "struct compunit_symtab *". All callers updated.
(compute_compunit_symtab_includes): Renamed from
compute_symtab_includes. All callers updated. Rewrite to compute
includes of compunit_symtabs and not symtabs.
(process_full_comp_unit): Update to work with struct compunit_symtab.
(process_full_type_unit): Ditto.
(dwarf_decode_lines_1): Delete argument comp_dir. All callers updated.
(dwarf_decode_lines): Remove special case handling of main subfile.
(macro_start_file): Delete argument comp_dir. All callers updated.
(dwarf_decode_macro_bytes): Ditto.
* guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to
use struct compunit_symtab.
* i386-tdep.c (i386_skip_prologue): Fetch producer from compunit.
* jit.c (finalize_symtab): Build compunit_symtab.
* jv-lang.c (get_java_class_symtab): Change result to
"struct compunit_symtab *". All callers updated.
* macroscope.c (sal_macro_scope): Fetch macro table from compunit.
* macrotab.c (struct macro_table) <compunit_symtab>: Renamed from
comp_dir. Change type to "struct compunit_symtab *".
All uses updated.
(new_macro_table): Change comp_dir argument to cust,
"struct compunit_symtab *". All callers updated.
* maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from
nr_primary_symtabs. All uses updated.
(count_symtabs_and_blocks): Update to handle compunits.
(report_command_stats): Update output, "primary symtabs" renamed to
"compunits".
* mdebugread.c (new_symtab): Change result to
"struct compunit_symtab *". All callers updated.
(parse_procedure): Change type of search_symtab argument to
"struct compunit_symtab *". All callers updated.
* objfiles.c (objfile_relocate1): Loop over blockvectors in a
separate loop.
* objfiles.h (struct objfile) <compunit_symtabs>: Renamed from
symtabs. Change type to "struct compunit_symtab *". All uses updated.
(ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS.
All uses updated.
(ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS.
All uses updated.
(ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated.
(ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated.
* psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from
symtab. Change type to "struct compunit_symtab *". All uses updated.
* psymtab.c (psymtab_to_symtab): Change result type to
"struct compunit_symtab *". All callers updated.
(find_pc_sect_compunit_symtab_from_partial): Renamed from
find_pc_sect_symtab_from_partial. Change result type to
"struct compunit_symtab *". All callers updated.
(lookup_symbol_aux_psymtabs): Change result type to
"struct compunit_symtab *". All callers updated.
(find_last_source_symtab_from_partial): Ditto.
* python/py-symtab.c (stpy_get_producer): Fetch producer from compunit.
* source.c (forget_cached_source_info_for_objfile): Fetch debugformat
and macro_table from compunit.
* symfile-debug.c (debug_qf_find_last_source_symtab): Change result
type to "struct compunit_symtab *". All callers updated.
(debug_qf_lookup_symbol): Ditto.
(debug_qf_find_pc_sect_compunit_symtab): Renamed from
debug_qf_find_pc_sect_symtab, change result type to
"struct compunit_symtab *". All callers updated.
* symfile.c (allocate_symtab): Delete objfile argument.
New argument cust.
(allocate_compunit_symtab): New function.
(add_compunit_symtab_to_objfile): New function.
* symfile.h (struct quick_symbol_functions) <lookup_symbol>:
Change result type to "struct compunit_symtab *". All uses updated.
<find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab.
Change result type to "struct compunit_symtab *". All uses updated.
* symmisc.c (print_objfile_statistics): Compute blockvector count in
separate loop.
(dump_symtab_1): Update test for primary source symtab.
(maintenance_info_symtabs): Update to handle compunit symtabs.
(maintenance_check_symtabs): Ditto.
* symtab.c (set_primary_symtab): Delete.
(compunit_primary_filetab): New function.
(compunit_language): New function.
(iterate_over_some_symtabs): Change type of arguments "first",
"after_last" to "struct compunit_symtab *". All callers updated.
Update to loop over symtabs in each compunit.
(error_in_psymtab_expansion): Rename symtab argument to cust,
and change type to "struct compunit_symtab *". All callers updated.
(find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab.
Change result type to "struct compunit_symtab *". All callers updated.
(find_pc_compunit_symtab): Renamed from find_pc_symtab.
Change result type to "struct compunit_symtab *". All callers updated.
(find_pc_sect_line): Only loop over symtabs within selected compunit
instead of all symtabs in the objfile.
* symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab.
<compunit_symtab> New member.
<block_line_section>: Moved to compunit_symtab.
<locations_valid>: Ditto.
<epilogue_unwind_valid>: Ditto.
<macro_table>: Ditto.
<dirname>: Ditto.
<debugformat>: Ditto.
<producer>: Ditto.
<objfile>: Ditto.
<call_site_htab>: Ditto.
<includes>: Ditto.
<user>: Ditto.
<primary>: Delete
(SYMTAB_COMPUNIT): New macro.
(SYMTAB_BLOCKVECTOR): Update definition.
(SYMTAB_OBJFILE): Update definition.
(SYMTAB_DIRNAME): Update definition.
(struct compunit_symtab): New type. Common members among all source
symtabs within a compilation unit moved here. All uses updated.
(COMPUNIT_OBJFILE): New macro.
(COMPUNIT_FILETABS): New macro.
(COMPUNIT_DEBUGFORMAT): New macro.
(COMPUNIT_PRODUCER): New macro.
(COMPUNIT_DIRNAME): New macro.
(COMPUNIT_BLOCKVECTOR): New macro.
(COMPUNIT_BLOCK_LINE_SECTION): New macro.
(COMPUNIT_LOCATIONS_VALID): New macro.
(COMPUNIT_EPILOGUE_UNWIND_VALID): New macro.
(COMPUNIT_CALL_SITE_HTAB): New macro.
(COMPUNIT_MACRO_TABLE): New macro.
(ALL_COMPUNIT_FILETABS): New macro.
(compunit_symtab_ptr): New typedef.
(DEF_VEC_P (compunit_symtab_ptr)): New vector type.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Update expected output.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This constifies a few functions in cli-utils -- get_number_trailer and
friends -- and then fixes the fallout.
2014-07-30 Tom Tromey <tromey@redhat.com>
* breakpoint.c (map_breakpoint_numbers): Update.
* cli/cli-utils.c (get_number_trailer): Make "pp" const. Update.
(get_number_const): New function.
(get_number): Rewrite using get_number_const.
(init_number_or_range): Make "string" const.
(number_is_in_list): Make "list" const.
* cli/cli-utils.h (get_number_const): Declare.
(struct get_number_or_range_state) <string, end_ptr>: Now const.
(init_number_or_range, number_is_in_list): Update.
* printcmd.c (map_display_numbers): Update.
* value.c (value_from_history_ref): Constify.
* value.h (value_from_history_ref): Update.
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.
E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1. This obviously messes up programs that use
pthread_kill to send signals to specific threads.
This has been a known issue for a long while. Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.
The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.
Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint... If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).
"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for. These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do. GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test). At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.
Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:
(gdb) continue
Thread 1 stopped for signal SIGFOO.
(gdb) thread 2
(gdb) signal SIGBAR
... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).
So the patch makes GDB detect that, and ask for confirmation:
(gdb) thread 1
[Switching to thread 1 (Thread 10979)]
(gdb) signal SIGUSR2
Note:
Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
Continuing thread 1 (the current thread) with specified signal will
still deliver the signals noted above to their respective threads.
Continue anyway? (y or n)
All these scenarios are covered by the new tests.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* NEWS: Mention signal passing and "signal" command changes.
* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
comment.
* breakpoint.c (until_break_command): Adjust clear_proceed_status
call.
* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
* infcmd.c (proceed_thread_callback, continue_1, step_once)
(jump_command): Adjust clear_proceed_status call.
(signal_command): Warn if other thread that are resumed have
signals that will be delivered. Adjust clear_proceed_status call.
(until_next_command, finish_command)
(proceed_after_attach_callback, attach_command_post_wait)
(attach_command): Adjust clear_proceed_status call.
* infrun.c (proceed_after_vfork_done): Likewise.
(proceed_after_attach_callback): Adjust comment.
(clear_proceed_status_thread): Clear stop_signal if not in pass
state.
(clear_proceed_status_callback): Delete.
(clear_proceed_status): New 'step' parameter. Only clear the
proceed status of threads the command being prepared is about to
resume.
(proceed): If passed in an explicit signal, override stop_signal
with it. Don't pass the last stop signal to the thread we're
resuming.
(init_wait_for_inferior): Adjust clear_proceed_status call.
(switch_back_to_stepped_thread): Clear the signal if it should not
be passed.
* infrun.h (clear_proceed_status): New 'step' parameter.
(user_visible_resume_ptid): Add comment.
* linux-nat.c (linux_nat_resume_callback): Don't check whether the
signal is in pass state.
* remote.c (append_pending_thread_resumptions): Likewise.
* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
gdb/doc/
2014-07-25 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Signaling) <signal command>: Explain what happens
with multi-threaded programs.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
BINOP_RANGE was added by the following commit for chill language.
commit badefd2800
Author: Per Bothner <per@bothner.com>
Date: Wed Nov 29 22:59:31 1995 +0000
* expression.h (enum exp_opcode): Add BINOP_RANGE.
* expprint.c (dump_expression): Support BINOP_RANGE.
* eval.c (evaluate_subexp_standard): Handle BINOP_RANGE (as error).
(case MULTI_SUBSCRIPT): Fix broken f77 value->int ad hoc conversion.
* ch-lang.c (chill_op_print_tab): Support BINOP_RANGE.
(evaluate_subexp_chill): Error on BINOP_COMMA.
Chill language is no longer supported, so we can remove BINOP_RANGE too.
This patch is to remove BINOP_RANGE.
gdb:
2014-07-20 Yao Qi <yao@codesourcery.com>
* std-operator.def: Remove BINOP_RANGE.
* breakpoint.c (watchpoint_exp_is_const): Update.
* expprint.c (dump_subexp_body_standard): Likewise.
* eval.c (init_array_element): Remove dead code.
(evaluate_subexp_standard): Likewise.
Chill language support was removed several years ago, and BINOP_IN
isn't used for Pascal. This patch is to remove BINOP_IN.
gdb:
2014-07-20 Yao Qi <yao@codesourcery.com>
* std-operator.def: Remove BINOP_IN.
* breakpoint.c (watchpoint_exp_is_const): Update.
* eval.c (evaluate_subexp_standard): Likewise.
* expprint.c (dump_subexp_body_standard): Likewise.
This patch changes a few more spots to use either cmd_sfunc_ftype or
cmd_cfunc_ftype, as appropriate. This is a bit cleaner.
Tested by rebuilding.
2014-07-01 Tom Tromey <tromey@redhat.com>
* breakpoint.c (add_catch_command): Use cmd_sfunc_ftype.
* breakpoint.h (add_catch_command): Use cmd_sfunc_ftype.
* cli/cli-decode.c (cmd_cfunc_eq, add_cmd, add_prefix_cmd)
(add_abbrev_prefix_cmd, add_info, add_com): Use cmd_cfunc_ftype.
* command.h (cmd_cfunc_ftype): Move earlier.
(add_cmd, add_prefix_cmd, add_abbrev_prefix_cmd, cmd_cfunc_eq)
(add_com, add_info): Use cmd_cfunc_ftype.
Gabriel Krisman Bertazi
Jan Kratochvil
Pedro Alves
Antoine Tremblay
Keith Seitz
Sergio Durigan Junior
Gary Benson
Jose E. Marchesi
Tom Tromey
Simon Marchi
Joel Brobecker
Doug Evans
Maciej W. Rozycki
Patrick Palka
Yao Qi