This is a trace which would have been useful when trying to understand
why the debugger was not decoding the stream of unwind codes I was
expecting. This patch adds a trace first informing us that we are
following the unwind info to the next unwind record in that chain.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_frame_decode_insns):
Add debug trace.
On x86_64-windows, GDB is unable to unwind past some code in
mswsock.dll. For instance:
(gdb) bt
#0 0x00000000778712fa in ntdll!ZwWaitForSingleObject ()
from C:\Windows\SYSTEM32\ntdll.dll
#1 0x000007fefcfb0f75 in WSPStartup ()
from C:\Windows\system32\mswsock.dll
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The UNWIND_INFO record for frame #1's PC has a UNW_FLAG_CHAININFO
flag, and so after having decoded this unwind record, GDB's decoder
next tries to locate the next unwind record on the chain. Unfortunately,
the location of that unwind info appears to be miscomputed. This is
the expression used:
chain_vma = cache->image_base + unwind_info
+ sizeof (ex_ui) + ((codes_count + 1) & ~1) * 2 + 8;
The chain-info is expected to be right after the "Unwind codes
array" which is itself after all the fields of ex_ui's struct.
So the "+ 8" offset at the end should not be there.
Because of that extra offset, we were reading no longer processing
correct unwind info, leading the unwinder computing the wrong frame
size, computing the wrong return address, etc.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_frame_decode_insns):
Remove "+ 8" offset in computation of CHAIN_VMA.
This commit removes all inclusions of defs.h and server.h from header
files.
gdb/
2014-07-31 Gary Benson <gbenson@redhat.com>
* common/btrace-common.h: Do not include defs.h or server.h.
* nat/mips-linux-watch.h: Likewise.
* gdb-dlfcn.h: Do not include defs.h.
* tracefile.h: Likewise.
gdb/gdbserver/
2014-07-31 Gary Benson <gbenson@redhat.com>
* ax.h: Do not include server.h.
* gdbthread.h: Likewise.
* lynx-low.h: Likewise.
* notif.h: Likewise.
This makes target_ops::to_open take a const string and then fixes the
fallout.
There were a few of these I could not build. However I eyeballed it
and in any case the fixes should generally be trivial.
This is based on the patch to fix up the target debugging for to_open,
because that changes gdb to not directly install to_open as the target
command
2014-07-30 Tom Tromey <tromey@redhat.com>
* bsd-kvm.c (bsd_kvm_open): Constify.
* corelow.c (core_open): Constify.
* ctf.c (ctf_open): Constify.
* dbug-rom.c (dbug_open): Constify.
* exec.c (exec_open): Constify.
* m32r-rom.c (m32r_open, mon2000_open): Constify.
* microblaze-rom.c (picobug_open): Constify.
* nto-procfs.c (procfs_open_1, procfs_open, procfs_native_open):
Constify.
* ppcbug-rom.c (ppcbug_open0, ppcbug_open1): Constify.
* record-btrace.c (record_btrace_open): Constify.
* record-full.c (record_full_core_open_1, record_full_open_1)
(record_full_open): Constify.
* remote-m32r-sdi.c (m32r_open): Constify.
* remote-mips.c (common_open, mips_open, pmon_open, ddb_open)
(rockhopper_open, lsi_open): Constify.
* remote-sim.c (gdbsim_open): Constify.
* remote.c (remote_open, extended_remote_open, remote_open_1):
Constify.
* target.h (struct target_ops) <to_open>: Make "arg" const.
* tracefile-tfile.c (tfile_open): Constify.
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.
This constifies exec_file_attach and updates the rest of gdb.
Insight will need some minor tweaks after this, though it's worth
noting that I think all that hook stuff can actually just go away. I
sent a patch to this effect once, but since the Insight source
repository situation isn't currently resolved there wasn't a
convenient way to test it.
2014-07-30 Tom Tromey <tromey@redhat.com>
* corefile.c (hook_type, call_extra_exec_file_hooks)
(specify_exec_file_hook): Constify.
* exec.c (exec_file_attach): Make "filename" const.
* gdbcore.h (deprecated_exec_file_display_hook)
(specify_exec_file_hook, exec_file_attach): Constify.
* main.c (captured_main): Use catch_command_errors_const.
This is a follow-on to the patch to auto-generate target debug methods.
While working on that patch I noticed that the to_open debug setting
will never work. There is no path by which debug_to_open can be
called.
This patch fixes the problem by using a generic function as the
implementation of the various "target" subcommands, and then putting
the debug printing there.
This is also a tiny step toward fixing PR 7250 (and apparently why
command contexts were introduced).
Built and regtested on x86-64 Fedora 20.
2014-07-30 Tom Tromey <tromey@redhat.com>
* target.c (open_target): New function.
(add_target_with_completer, add_deprecated_target_alias): Use
set_cmd_sfunc, set_cmd_context.
(debug_to_open): Remove.
(setup_target_debug): Update.
Hello,
I happen to read the code and find the comments to operator_check are
incorrect. This patch is to fix the comments per my understanding.
The comments and field operator_check was added by this patch
https://sourceware.org/ml/gdb-patches/2010-04/msg00556.html
but the inconsistency between code and comments wasn't pointed out during
the review.
gdb:
2014-07-30 Yao Qi <yao@codesourcery.com>
* parser-defs.h (struct exp_descriptor) <operator_check>: Update
comments.
* parse.c (exp_iterate): Update comments.
This commit creates a new header, common/common-defs.h, to hold
definitions common to all code under gdb/. Both gdb/defs.h and
gdb/gdbserver/server.h are modified to include common-defs.h as
their first non-comment line; all code under gdb/ includes either
defs.h or server.h as appropriate, so common-defs.h will be the
first actual code the compiler sees.
For this initial commit common-defs.h includes only the two
config.h files. Future commits will move more code currently
duplicated across defs.h and server.h such that shared code in
gdb/{common,target,nat} can be modified to include common-defs.h
rather than defs.h or server.h.
gdb/
2014-07-30 Gary Benson <gbenson@redhat.com>
* common/common-defs.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/common-defs.h.
* defs.h: Include common-defs.h.
Do not include config.h or build-gnulib/config.h.
gdb/gdbserver/
2014-07-30 Gary Benson <gbenson@redhat.com>
* server.h: Include common-defs.h.
Do not include config.h or build-gnulib-gdbserver/config.h.
All source files under gdb/ that include headers from gdb/ include
either defs.h or server.h before any other code with the exception
of gdb/gdbserver/gdbreplay.c which seems to be a special case. Both
defs.h and server.h include both our and gnulib's config.h files as
their first non-comment line, so no other file ever needs to directly
include any config.h. This commit removes two such direct config.h
includes.
gdb/
2014-07-30 Gary Benson <gbenson@redhat.com>
* common/common-utils.h: Do not include config.h.
* nat/linux-btrace.h: Likewise.
This commit makes all source files under gdb/ that include headers
from gdb/ include either defs.h or server.h before any other code.
This ensures that definitions and macros from the two config.h files
are always in place for our code. An exception has been made for
gdb/gdbserver/gdbreplay.c which seems to be a special case.
gdb/
2014-07-30 Gary Benson <gbenson@redhat.com>
* btrace.c: Include defs.h.
* common/ptid.c: Include defs.h or server.h as appropriate.
* nat/mips-linux-watch.c: Likewise.
gdb/gdbserver/
2014-07-30 Gary Benson <gbenson@redhat.com>
* hostio-errno.c: Move server.h to top of includes list.
* inferiors.c: Likewise.
* linux-x86-low.c: Likewise.
* notif.c: Include server.h.
While working on target_is_pushed, I noticed that it is written in a
strange way. The code currently keeps an extra indirection, where a
simple linked list traversal is all that is needed. It seems likely
this was done by copying and pasting other code. However, there is no
reason to do this and the more obvious code is simpler to reason
about. So, this patch change the implementation.
2014-07-29 Tom Tromey <tromey@redhat.com>
* target.c (target_is_pushed): Simplify.
gas/
* config/tc-mips.c: Rename INSN_LOAD_COPROC_DELAY to INSN_LOAD_COPROC
and INSN_COPROC_MOVE_DELAY to INSN_COPROC_MOVE throughout.
include/opcode/
* mips.h (INSN_LOAD_COPROC_DELAY): Rename to...
(INSN_LOAD_COPROC): New define.
(INSN_COPROC_MOVE_DELAY): Rename to...
(INSN_COPROC_MOVE): New define.
opcodes/
* micromips-opc.c (COD): Rename throughout to...
(CM): New define, update to use INSN_COPROC_MOVE.
(LCD): Rename throughout to...
(LC): New define, update to use INSN_LOAD_COPROC.
* mips-opc.c: Likewise.
As reported in PR 17206, an internal error is triggered when command
until is executed. In infcmd.c:until_next_command, step_range_end is
set to 'pc',
if (!func)
{
struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc);
if (msymbol.minsym == NULL)
error (_("Execution is not within a known function."));
tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol);
tp->control.step_range_end = pc;
}
and later in infrun.c:resume, the assert below is triggered in PR
17206.
if (tp->control.may_range_step)
{
/* If we're resuming a thread with the PC out of the step
range, then we're doing some nested/finer run control
operation, like stepping the thread out of the dynamic
linker or the displaced stepping scratch pad. We
shouldn't have allowed a range step then. */
gdb_assert (pc_in_thread_step_range (pc, tp));
}
In until_next_command, we set step range to [XXX, pc), so pc isn't
within the range. pc_in_thread_step_range returns false and the
assert is triggered. AFAICS, the range we want in until_next_command
is [XXX, pc] instead of [XXX, pc), because we want to program step
until greater than pc. This patch is to set step_range_end to
'pc + 1'. Running until-nodebug.exp with unpatched GDB will get the
following fail,
FAIL: gdb.base/until-nodebug.exp: until 2 (GDB internal error)
and the fail goes away when the fix is applied.
gdb:
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* infcmd.c (until_next_command): Set step_range_end to PC + 1.
gdb/testsuite:
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* gdb.base/until-nodebug.exp: New.
* guile/scm-param.c (pascm_parameter_defined_p): New function.
(gdbscm_register_parameter_x): Call it. Raise error for pre-existing
parameters.
testsuite/
* gdb.guile/scm-parameter.exp: Add tests for trying to create
previously existing parameter, and previously ambiguously spelled
parameter.
Recent versions of glibc have assembled the signal trampoline code
as Thumb2, which causes gdb to misinterpret them and a number of
testsuite tests to fail. Educate gdb about these trampolines and
get the tests running again.
gdb/ChangeLog:
2014-07-28 Will Newton <will.newton@linaro.org>
* arm-linux-tdep.c (THUMB2_SET_R7_SIGRETURN1): New define.
(THUMB2_SET_R7_SIGRETURN2): Likewise.
(THUMB2_SET_R7_RT_SIGRETURN1): Likewise.
(THUMB2_SET_R7_RT_SIGRETURN2): Likewise.
(THUMB2_EABI_SYSCALL): Likewise.
(thumb2_eabi_linux_sigreturn_tramp_frame): Create new
struct tramp_frame.
(thumb2_eabi_linux_rt_sigreturn_tramp_frame): Likewise.
(arm_linux_init_abi): Add Thumb2 tramp frame unwinders.
These tests used to fail on ARM but now pass, so remove the KFAIL.
gdb/testsuite/ChangeLog:
2014-07-28 Will Newton <will.newton@linaro.org>
* gdb.base/varargs.exp: Remove KFAILs for ARM.
* configure.ac (or1k*-*-rtems*): gdb not supported. The ordering
of the stanzas results in this not being caught by or1k*-*-* later.
* configure. Regenerated.
Signed-off-by: Christian Svensson <blue@cmd.nu>
* gas/configure.tgt (or1k*-*-rtems*): Ensure a match.
(or1k*-*-*): Use or1k* to match or1knd and or1kZ.
Signed-off-by: Christian Svensson <blue@cmd.nu>
* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): New macro.
(GDB_GUILD_TARGET_FLAG, GDB_TRY_GUILD): New macros.
* configure.ac: Try to use guild to compile an scm file, if it fails
then disable guile support.
* configure: Regenerate.
* data-directory/Makefile.in (GUILE_SOURCE_FILES): Renamed from
GUILE_FILE_LIST.
(GUILE_COMPILED_FILES): New variable.
(GUILE_FILES) Update.
(GUILD, GUILD_TARGET_FLAG, GUILD_COMPILE_FLAGS): New variables.
(stamp-guile): Compile scm files.
* guile/guile.c (boot_guile_support): New function.
(standard_throw_args_p): New function.
(print_standard_throw_error, print_throw_error): New functions.
(handle_boot_error): New function.
(initialize_scheme_side): Rewrite to call boot_guile_support.
* guile/lib/gdb/boot.scm: Update %load-compiled-path. Load gdb.go.
* guile/lib/gdb/init.scm (%silence-compiler-warnings%): New function.
* data-directory/Makefile.in (GUILE_FILES): Add support.scm.
* guile/lib/gdb/support.scm: New file.
* guile/guile.c (gdbscm_init_module_name): Change to "gdb".
* guile/lib/gdb.scm: Load gdb/init.scm as an include file.
All uses updated.
* guile/lib/gdb/init.scm (SCM_ARG1, SCM_ARG2): Moved to support.scm.
All uses updated.
(%assert-type): Ditto, and renamed to assert-type.
(%exception-print-style): Delete.
testsuite/
* gdb.guile/types-module.exp: Add tests for wrong type arguments.
Tested with/without guile,python on amd64-linux.
I'm not sure we still have to deal with shells that can't
handle empty for lists, but I played it safe.
Otherwise this patch would be a lot smaller (though a diff -b
will still show the real changes).
PR build/17105
* configure.ac: Add AM_CONDITIONALs for HAVE_PYTHON, HAVE_GUILE.
* configure: Regenerate.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Renamed from
PYTHON_FILES.
(PYTHON_FILES): New variable.
(GUILE_FILE_LIST): Renamed from GUILE_FILES.
(GUILE_FILES): New variable.
(stamp-python, install-python, uninstall-python): Handle empty
file list.
(stamp-guile, install-guile, uninstall-guile): Ditto.
PR 17185 describes a problem with using gdb+guile with libgc 7.4.0.
The symptom is a hang in sigsuspend.
[The thread referenced in the PR has the details.]
It's not clear what the right fix is, or even where the bug is yet.
This patch applies the same workaround Guile has applied.
There is no functionality or real performance loss with this,
and Guile has been using it for awhile.
* configure.ac: Add check for header gc/gc.h.
Add check for function setenv.
* configure: Regenerate.
* config.in: Regenerate.
* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.
Use size_t in a few places involved with obstacks, and don't include
obstack.h in files that don't use obstacks.
gas/
* config/bfin-parse.y: Don't include obstack.h.
* config/obj-aout.c: Likewise.
* config/obj-coff.c: Likewise.
* config/obj-som.c: Likewise.
* config/tc-bfin.c: Likewise.
* config/tc-i960.c: Likewise.
* config/tc-rl78.c: Likewise.
* config/tc-rx.c: Likewise.
* config/tc-tic4x.c: Likewise.
* expr.c: Likewise.
* listing.c: Likewise.
* config/obj-elf.c (elf_file_symbol): Make name_length a size_t.
* config/tc-aarch64.c (symbol_locate): Likewise.
* config/tc-arm.c (symbol_locate): Likewise.
* config/tc-mmix.c (mmix_handle_mmixal): Make len_0 a size_t.
* config/tc-score.c (s3_build_score_ops_hsh): Make len a size_t.
(s3_build_dependency_insn_hsh): Likewise.
* config/tc-score7.c (s7_build_score_ops_hsh): Likewise.
(s7_build_dependency_insn_hsh): Likewise.
* frags.c (frag_grow): Make parameter a size_t, and use size_t locals.
(frag_new): Make parameter a size_t.
(frag_var_init): Make max_chars and var parameters size_t.
(frag_var, frag_variant): Likewise.
(frag_room): Return a size_t.
(frag_align_pattern): Make n_fill parameter a size_t.
* frags.h: Update function prototypes.
* symbols.c (save_symbol_name): Make name_length a size_t.
Individual users will still have to:
1. Install git-merge-changelog
2. Set up the merge driver in their git config
See gnulib's lib/git-merge-changelog.c [1] for details.
For example, I:
1. Patched Debian's gnulib package to build git-merge-changelog, and
sent the patch to the Debian maintainer, who then proceeded to not
only accept my patch but even write a *manpage* for
git-merge-changelog! (Let's hear it for Ian Beckwith.)
So now, I can install it simply by running "apt-get install
git-merge-changelog". (Except, of course, that I already have it
installed from when I was testing my patch.)
2. Did step (2) from .gitattributes
With this patch applied and the above two steps done by whatever means
you deem best, you can say goodbye to merge conflicts in ChangeLog
files -- at least *IF* people stop renaming the danged things, anyway.
If you don't do step 2, you will continue to suffer from ChangeLog
merge conflicts exactly as before, whether or not you did step 1.
If you do step 2 but not step 1, git will likely start complaining
that it can't find any "git-merge-changelog" to run.
[1]: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
[Note: The docs for git-merge-changelog (the comments at the top) say
that you need a .gitattributes in every directory. The docs are wrong.
Ignore the docs. Well, not the whole docs; just that part.
You really only need one at the top level, since .gitattributes uses
the same pattern matching rules as .gitignore, which match files in
any subdirectory unless you prefix the pattern with a "/", as
explained in the gitignore(5) manpage.]
This fixes gdbarch matching, making sure one for the opposite compressed
ISA variation is not chosen. That in turn makes "set mips compression"
work; right now the setting sticks to the initial value, either inferred
from the ELF header of the binary first loaded or the default value if
no binary has been used. This only affects debugging with no symbol
table available or no binary chosen at all, as otherwise symbol
annotations determine the compressed ISA variation.
* mips-tdep.c (mips_gdbarch_init): Also check the compressed ISA
variation in gdbarch matching.
This removes the using_exec_ops global from exec.c, in favor of
querying the target stack directly using target_is_pushed. This is
more in keeping with other code in gdb, and is also more future-proof
as it is more multi-target-ready.
Built and regtested on x86-64 Fedora 20.
2014-07-25 Tom Tromey <tromey@redhat.com>
* exec.c (using_exec_ops): Remove.
(exec_close_1): Update. Remove extraneous block, reindent.
(add_target_sections): Use target_is_pushed.
A previous patch added a new parameter to clear_proceed_status, but
forgot to update a few callers.
Tested by building on x86_64 Fedora 20, with --enable-targets=all.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* go32-nat.c (go32_create_inferior): Pass 0 to clear_proceed_status.
* monitor.c (monitor_create_inferior): Likewise.
* remote-m32r-sdi.c (m32r_create_inferior): Likewise.
* remote-sim.c (gdbsim_create_inferior): Likewise.
* solib-irix.c (irix_solib_create_inferior_hook): Likewise.
* solib-osf.c (osf_solib_create_inferior_hook): Likewise.
* windows-nat.c (do_initial_windows_stuff): Likewise.
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.
I happened to notice that a couple of macros in target.h weren't
properly using parens and as a result had a strange definition.
This patch adds the parens and then fixes the macros to be written as
must have been intended.
Tested by rebuilding.
I'm pushing this as obvious.
2014-07-25 Tom Tromey <tromey@redhat.com>
* target.h (target_stopped_data_address)
(target_watchpoint_addr_within_range): Use "->", not ".". Fix
parentheses.
