Add the function lwp_is_stepping which indicates whether the given LWP
is currently single-stepping. This is a common interface, usable from
native GDB as well as from gdbserver.
gdb/gdbserver/ChangeLog:
* linux-low.c (lwp_is_stepping): New function.
gdb/ChangeLog:
* nat/linux-nat.h (lwp_is_stepping): New declaration.
* linux-nat.c (lwp_is_stepping): New function.
Implement a new function for dumping the S390 "debug
registers" (actually, the PER info) and invoke it at appropriate places.
Respect the variable show_debug_regs and make it settable by the user.
gdb/ChangeLog:
* s390-linux-nat.c (gdbcmd.h): New include.
(s390_show_debug_regs): New function.
(s390_stopped_by_watchpoint): Call it, if show_debug_regs is set.
(s390_prepare_to_resume): Likewise.
(_initialize_s390_nat): Register the command "maint set
show-debug-regs".
Support different sets of watchpoints in multiple inferiors.
gdb/ChangeLog:
* s390-linux-nat.c (watch_areas): Remove variable. Replace by a
member of...
(struct s390_debug_reg_state): ...this. New struct.
(struct s390_process_info): New struct.
(s390_process_list): New variable.
(s390_find_process_pid, s390_add_process, s390_process_info_get)
(s390_get_debug_reg_state): New functions.
(s390_stopped_by_watchpoint): Now access the watch_areas VEC via
s390_get_debug_reg_state.
(s390_prepare_to_resume): Likewise.
(s390_insert_watchpoint): Likewise.
(s390_remove_watchpoint): Likewise.
(s390_forget_process, s390_linux_new_fork): New linux_nat target
methods.
(_initialize_s390_nat): Register them.
For S390, the list of active watchpoints is maintained in a list based
at "watch_base". This refactors the list to a vector "watch_areas".
gdb/ChangeLog:
* s390-linux-nat.c (s390_watch_area): New typedef. Define a VEC.
(watch_base): Remove variable.
(watch_areas): New variable.
(s390_stopped_by_watchpoint): Transform operations on the
watch_base list to equivalent operations on the watch_areas VEC.
(s390_prepare_to_resume): Likewise.
(s390_insert_watchpoint): Likewise.
(s390_remove_watchpoint): Likewise.
When using the lwp_info structure, avoid accessing its members directly,
and use the advertised function interfaces instead. This is according
to the instructions in linux-nat.h and prepares for making some of the
code common between gdb and gdbserver.
gdb/ChangeLog:
* s390-linux-nat.c (s390_prepare_to_resume): Use advertised lwp
functions instead of accessing lwp_info structure members.
(s390_mark_per_info_changed): New function.
(s390_new_thread): Use it.
(s390_refresh_per_info_cb): New function.
(s390_refresh_per_info): Remove parameter. Refresh all lwps of
the current process.
(s390_insert_watchpoint): Adjust call to s390_refresh_per_info.
(s390_remove_watchpoint): Likewise.
On various GNU Elf architectures, including AArch64, ARM, s390/s390x,
ppc32/64, and sparc32/64, the dynamic loader passes HWCAP as a parameter
to each ifunc resolver. Currently there is an open glibc Bugzilla that
requests this to be generalized to all architectures:
https://sourceware.org/bugzilla/show_bug.cgi?id=19766
And various ifunc resolvers already rely on receiving HWCAP. Currently
GDB always calls an ifunc resolver without any arguments; thus the
resolver may receive garbage, and based on that, the resolver may decide
to return a function that is not suited for the given platform.
This patch always passes HWCAP to ifunc resolvers, even on systems where
the dynamic loader currently behaves otherwise. The rationale is
that (1) the dynamic loader may get adjusted on those systems as well in
the future; (2) passing an unused argument should not cause a problem
with existing resolvers; and (3) the logic is much simpler without such
a distinction.
gdb/ChangeLog:
* elfread.c (auxv.h): New include.
(elf_gnu_ifunc_resolve_addr): Pass HWCAP to ifunc resolver.
gdb/testsuite/ChangeLog:
* gdb.base/gnu-ifunc-lib.c (resolver_hwcap): New external
variable declaration.
(gnu_ifunc): Add parameter hwcap. Store it in resolver_hwcap.
* gdb.base/gnu-ifunc.c (resolver_hwcap): New global variable.
* gdb.base/gnu-ifunc.exp: Add test to verify that the resolver
received HWCAP as its argument.
I happened to notice a few unneeded casts in remote.c. In some cases
these are no-ops, and in others these cast away const, but in a context
where this is not needed.
I'm checking this in under the obvious rule.
Tested by rebuilding on x86-64 Fedora 24.
2016-09-08 Tom Tromey <tom@tromey.com>
* remote.c (remote_notif_stop_ack, remote_wait_as)
(show_remote_cmd): Remove unneeded casts.
I noticed that if input is already pending on the new-ui TTY, gdb
internal-errors.
E.g., create /dev/pts/2, and type anything there (even just <return>
is sufficient).
Now start GDB creating a new UI on that TTY, while at the same time,
running a synchronous execution command. Something like:
$ gdb program -ex "new-ui console /dev/pts/2" -ex "start"
Back on /dev/pts/2, we get:
(gdb) .../src/gdb/event-top.c:360: internal-error: double prompt
A problem internal to GDB has been detected,
further debugging may prove unreliable.
While the main UI was waiting for "start" to finish, gdb kepts pumping
events, including the input fd of the extra console. The problem is
that stdin_event_handler doesn't restore the current UI back to what
it was, assuming that it's only ever called from the top level event
loop. However, in this case, it's being called from the nested event
loop from within maybe_wait_sync_command_done.
When finally the "start" command is done, we reach the code that
prints the prompt in the main UI, just before starting the main event
loop. Since now the current UI is pointing at the extra console (by
mistake), we find ourselves printing a double prompt on the extra
console. This is caught by the assertion that fails, as shown above.
Since other event handlers also don't restore the UI (e.g., signal
event handlers), I think it's better if whatever is pumping events to
take care to restore the UI, if it cares. That's what this patch
does. New test included.
gdb/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* top.c (wait_sync_command_done): Don't assume current_ui doesn't
change across events. Restore the current UI before returning.
(gdb_readline_wrapper): Restore the current UI before returning.
gdb/testsuite/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui-pending-input.c: New file.
* gdb.base/new-ui-pending-input.exp: New file.
* gdb.exp (clear_gdb_spawn_id): New procedure.
(with_spawn_id): Check whether gdb_spawn_id exists before
referencing it. If gdb_spawn_id didn't exist on entry, clear it
on exit.
Just a tidy, no functional changes.
gdb/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* event-top.c (restore_ui_cleanup): Now static.
(make_cleanup_restore_current_ui): New function.
(switch_thru_all_uis_init): Use it.
* infcall.c (call_thread_fsm_should_stop): Use it.
* infrun.c (fetch_inferior_event): Use it.
* top.c (new_ui_command): Use it.
* top.h (restore_ui_cleanup): Delete declaration.
(make_cleanup_restore_current_ui): New declaration.
Now that all the prerequisites are in place, this commit finally adds support
for handling the __float128 type on Intel and Power, by providing appropriate
platform-specific versions of the floatformat_for_type callback.
Since at this point we do not yet have any indication in the debug info to
distinguish different floating-point formats of the same length, we simply
use the type name as hint. Types named "__float128" get the IEEE format.
In addition to handling "__float128" itself, we also recognize "_Float128"
and (on Power) "_Float64x", as well as the complex versions of those.
(As pointed out by Joseph Myers, starting with GCC 7, __float128 is just
a typedef for _Float128 -- but it's good to handle this anyway.)
A new test case does some simple verification that the format is decoded
correctly, using both __float128 and "long double" to make sure using both
in the same file still works. Another new test verifies handling of the
_FloatN and _FloatNx types supported by GCC 7, as well as the complex
versions of those types.
Note that this still only supports basic format decoding and encoding.
We do not yet support the GNU extension 'g' suffix for __float128 constants.
In addition, since all *arithmetic* on floating-point values is still
performed in native host "long double" arithmetic, if that format is not
able to encode all target __float128 values, we may get incorrect results.
(To fix this would require implementing fully synthetic target floating-
point arithmetic along the lines of GCC's real.c, presumably using MPFR.)
gdb/ChangeLog:
* i386-tdep.c (i386_floatformat_for_type): New function.
(i386_gdbarch_init): Install it.
* ppc-linux-tdep.c (ppc_floatformat_for_type): New function.
(ppc_linux_init_abi): Install it.
gdb/testsuite/ChangeLog:
* gdb.base/float128.c: New file.
* gdb.base/float128.exp: Likewise.
* gdb.base/floatn.c: Likewise.
* gdb.base/floatn.exp: Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
At this point, all TYPE_CODE_FLT types carry their floating-point format,
except for those creating from reading DWARF or stabs debug info. Those
will be addressed by this commit.
The main issue here is that we actually have to determine which floating-
point format to use. Currently, we only have the type length as input
to this decision. In the future, we may hopefully get --at least in
DWARF-- additional information to help disambiguate multiple different
formats of the same length. For now, we can still look at the type name
as a hint.
This decision logic is encapsulated in a gdbarch callback to allow
platform-specific overrides. The default implementation use the same
logic (compare type length against the various gdbarch_..._bit sizes)
that is currently implemented in floatformat_from_length.
With this commit, all platforms still use the default logic, so there
should be no actual change in behavior. A follow-on commit will add
support for __float128 on Intel and Power.
Once dwarf2read.c and stabsread.c make use of the new callback to
determine floating-point formats, we're now sure every TYPE_CODE_FLT
type will always carry its format. The commit therefore adds asserts
to verify_floatformat to ensure new code will continue to always
provide formats, and removes the code in floatformat_from_type that
used to handle types with a NULL TYPE_FLOATFORMAT.
gdb/ChangeLog:
* gdbarch.sh (floatformat_for_type): New gdbarch callback.
* gdbarch.h, gdbarch.c: Re-generate.
* arch-utils.h (default_floatformat_for_type): New prototype.
* arch-utils.c (default_floatformat_for_type): New function.
* doublest.c (floatformat_from_length): Remove.
(floatformat_from_type): Assume TYPE_FLOATFORMAT is non-NULL.
* gdbtypes.c (verify_floatformat): Require non-NULL format.
* dwarf2read.c (dwarf2_init_float_type): New function.
(read_base_type): Use it.
* stabsread.c (dbx_init_float_type): New function.
(read_sun_floating_type): Use it.
(read_range_type): Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Many callers of init_float_type and arch_float_type still pass a NULL
floatformat. This commit changes those callers where the floatformat
that is supposed to be use is obvious. There are two categories where
this is the case:
- A number of built-in types are intended to match the platform ABI
floating-point types (i.e. types that use gdbarch_float_bit etc.).
Those places should use the platform ABI floating-point formats
defined via gdbarch_float_format etc.
- A number of language built-in types should simply use IEEE floating-
point formats, since the language actually defines that this is the
format that must be used to implement floating-point types for this
language. (This affects Java, Go, and Rust.) The same applies for
to the predefined "RS/6000" stabs floating-point built-in types.
gdb/ChangeLog:
* ada-lang.c (ada_language_arch_info): Use gdbarch-provided
platform ABI floating-point formats for built-in types.
* d-lang.c (build_d_types): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* mdebugread.c (basic_type): Likewise.
* go-lang.c (build_go_types): Use IEEE floating-point formats
for language built-in types as mandanted by the language.
* jv-lang.c (build_java_types): Likewise.
* rust-lang.c (rust_language_arch_info): Likewise.
* stabsread.c (rs6000_builtin_type): Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
init_type (and arch_integer_type) currently use a special hack to set the
TYPE_NOSIGN flag if the type name is exactly "char". This commit moves the
hack up to the callers of those routines.
The special case currently can hit only for types created from dwarf2read,
but read_base_type actually implements the "char" check itself, so it is
redundant to do it in init_type as well. (Note that stabsread.c and the
other type readers always pass NULL as name to init_type, so the special
case can never hit for those.)
A few other cases create pre-definded types with a hard-coded name of "char";
the commit simply moves setting the TYPE_NOSIGN flag to those places.
No functional change intended.
gdb/ChangeLog:
* gdbtypes.c (init_type): Remove "char" special case.
(arch_integer_type): Likewise.
(gdbtypes_post_init): Set TYPE_NOSIGN for "char" type.
(objfile_type): Likewise.
* mdebugread.c (basic_type): Likewise.
* stabsread.c (rs6000_builtin_type): Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Now that init_type no longer takes a FLAGS argument, there is no user of
the TYPE_FLAGS_... enum values left. This commit removes them (and all
references to them in comments as well).
This is mostly a no-op, except for a change to the Python type printer,
which attempted to use them before. (As best as I can tell, this wasn't
really needed anyway, since it was only used to pretty-print type
*instance* flags, which only use the instance flags.)
gdb/ChangeLog:
* gdbtypes.h (enum type_flag_value): Remove.
Remove references to TYPE_FLAG_... in comments throughout.
* gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_...
flags, print the corresponding TYPE_... access macro names.
Remove references to TYPE_FLAG_... in comments throughout.
* infcall.c: Remove references to TYPE_FLAG_... in comments.
* valprint.c: Likewise.
* gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_...
values, only TYPE_INSTANCE_FLAG_... values.
(class TypeFlagsPrinter): Likewise.
gdb/testsuite/ChangeLog:
* gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
This adds a number of helper routines for creating objfile-owned types;
these correspond 1:1 to the already existing helper routines for creating
gdbarch-owned types, and are intended to be used instead of init_type.
A shared fragment of init_float_type and arch_float_type is extracted into
a separate subroutine verify_subroutine.
The commit also brings the interface of init_type in line with the one for
arch_type. In particular, this means removing the FLAGS argument; callers
now set the required flags directly. (Since most callers use the new
helper routines, very few callers actually need to set any additional
flags directly any more.)
Note that this means all the TYPE_FLAGS_... defined are no longer needed
anywhere; they will be removed by a follow-on commit.
All users of init_type are changed to use on of the new helpers where
possible. No functional change intended.
gdb/ChangeLog:
* gdbtypes.h (init_type): Remove FLAGS argument. Move OBJFILE
argument to first position.
(init_integer_type): New prototype.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
* gdbtypes.c (verify_floatflormat): New function.
(init_type): Remove FLAGS argument and processing. Move OBJFILE
argument to first position.
(init_integer_type): New function.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
(arch_float_type): Use verify_floatflormat.
(objfile_type): Use init_..._type helpers instead of calling
init_type directly.
* dwarf2read.c (fixup_go_packaging): Update to changed init_type
prototype.
(read_namespace_type): Likewise.
(read_module_type): Likewise.
(read_typedef): Likewise.
(read_unspecified_type): Likewise.
(build_error_marker_type): Likewise.
(read_base_type): Use init_..._type helpers.
* mdebugread.c (basic_type): Use init_..._type helpers.
(parse_type): Update to changed init_type prototype.
(cross_ref): Likewise.
* stabsread.c (rs6000_builtin_type): Use init_..._type helpers.
(read_sun_builtin_type): Likewise.
(read_sun_floating_type): Likewise.
(read_range_type): Likewise. Also update to changed init_type
prototype.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
gdbtypes provides a number of helper routines that can be called instead of
using arch_type directly to create a type of a particular kind. This patch
adds two additional such routines that have been missing so far, to allow
creation of TYPE_CODE_DECFLOAT and TYPE_CODE_POINTER types.
The patch also changes a number of places to use the new helper routines
instead of calling arch_type directly. No functional change intended.
gdb/ChangeLog:
* gdbtypes.h (arch_decfloat_type): New prototype.
(arch_pointer_type): Likewise.
* gdbtypes.c (arch_decfloat_type): New function.
(arch_pointer_type): Likewise.
(gdbtypes_post_init): Use arch_decfloat_type.
* avr-tdep.c (avr_gdbarch_init): Use arch_pointer_type.
* ft32-tdep.c (ft32_gdbarch_init): Likewise.
* m32c-tdep.c (make_types): Likewise.
* rl78-tdep.c (rl78_gdbarch_init): Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
A type's TYPE_SPECIFIC_FIELD is supposed to be initialized as appropriate
for the type code. This does happen if the type is created via init_type,
but not if it created via arch_type.
Fixed by extracting the initialization logic into a new set_type_code
routine, which is then called from both places.
gdb/ChangeLog:
* gdbtypes.c (set_type_code): New function.
(init_type, arch_type): Use it.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
This fixes a bug introduced by a wrong replacement here:
https://sourceware.org/ml/gdb-patches/2007-06/msg00196.html
The Ada "long_long_float" type is supposed to correspond to the
platform ABI long double type, not double.
gdb/ChangeLog:
* ada-lang.c (ada_language_arch_info): Use gdbarch_long_double_bit
instead of gdbarch_double_bit for "long_long_float".
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
This removes all support for building gdb & gdbserver with a C
compiler from gdb & gdbserver's build machinery.
gdb/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
* NEWS: Mention that a C++ compiler is now required.
* Makefile.in (COMPILER, COMPILER_CFLAGS): Remove.
(COMPILE.pre, CC_LD): Use CXX directly.
(INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly.
* acinclude.m4: Don't include build-with-cxx.m4.
* build-with-cxx.m4: Delete file.
* configure.ac: Remove GDB_AC_BUILD_WITH_CXX call.
* warning.m4: Assume $enable_build_with_cxx is yes.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
* Makefile.in (COMPILER, COMPILER_CFLAGS): Remove.
(COMPILE.pre, CC_LD): Use CXX directly.
(INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly.
* acinclude.m4: Don't include build-with-cxx.m4.
* configure.ac: Remove GDB_AC_BUILD_WITH_CXX call.
* configure: Regenerate.
This fixes the problem exercised by Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
This was originally exposed by the OpenJDK Python-based unwinder.
If an unwinder attempts to call parse_and_eval from within its
sniffing method, GDB's unwinding machinery enters infinite recursion.
However, parse_and_eval is a pretty reasonable thing to call, because
Python/Scheme-based unwinders will often need to read globals out of
inferior memory. The recursion happens because:
- get_current_frame() is called soon after the target stops.
- current_frame is NULL, and so we unwind it from the sentinel frame
(which is special and has level == -1).
- We reach get_prev_frame_if_no_cycle, which does cycle detection
based on frame id, and thus tries to compute the frame id of the new
frame.
- Frame id computation requires an unwinder, so we go through all
unwinder sniffers trying to see if one accepts the new frame (the
current frame).
- the unwinder's sniffer calls parse_and_eval().
- parse_and_eval depends on the selected frame/block, and if not set
yet, the selected frame is set to the current frame.
- get_current_frame () is called again. current_frame is still NULL,
so ...
- recurse forever.
In Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
gdb doesn't recurse forever simply because the Python unwinder
contains code to detect and stop the recursion itself. However, GDB
goes downhill from here, e.g., by showing the sentinel frame as
current frame (note the -1):
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
That "-1" frame level comes from this:
if (catch_exceptions (current_uiout, unwind_to_current_frame,
sentinel_frame, RETURN_MASK_ERROR) != 0)
{
/* Oops! Fake a current frame? Is this useful? It has a PC
of zero, for instance. */
current_frame = sentinel_frame;
}
which is bogus. It's never correct to set the current frame to the
sentinel frame. The only reason this has survived so long is that
getting here normally indicates something wrong has already happened
before and we fix that. And this case is no exception -- it doesn't
really matter how precisely we managed to get to that bogus code (it
has to do with the the stash), because anything after recursion
happens is going to be invalid.
So the fix is to avoid the recursion in the first place.
Observations:
#1 - The recursion happens because we try to do cycle detection from
within get_prev_frame_if_no_cycle. That requires computing the
frame id of the frame being unwound, and that itself requires
calling into the unwinders.
#2 - But, the first time we're unwinding from the sentinel frame,
when we reach get_prev_frame_if_no_cycle, there's no frame chain
at all yet:
- current_frame is NULL.
- the frame stash is empty.
Thus, there's really no need to do cycle detection the first time we
reach get_prev_frame_if_no_cycle, when building the current frame.
So we can break the recursion by making get_current_frame call a
simplified version of get_prev_frame_if_no_cycle that results in
setting the current_frame global _before_ computing the current
frame's id.
But, we can go a little bit further. As there's really no reason
anymore to compute the current frame's frame id immediately, we can
defer computing it to when some caller of get_current_frame might need
it. This was actually how the frame id was computed for all frames
before the stash-based cycle detection was added. So in a way, this
patch reintroduces the lazy frame id computation, but unlike before,
only for the case of the current frame, which turns out to be special.
This lazyness, however, requires adjusting
gdb.python/py-unwind-maint.exp, because that assumes unwinders are
immediately called as side effect of some commands. I didn't see a
need to preserve the behavior expected by that test (all it would take
is call get_frame_id inside get_current_frame), so I adjusted the
test.
gdb/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* frame.c (get_frame_id): Compute the frame id if not computed
yet.
(unwind_to_current_frame): Delete.
(get_current_frame): Use get_prev_frame_always_1 to get the
current frame and assert that that always succeeds.
(get_prev_frame_if_no_cycle): Skip cycle detection if returning
the current frame.
gdb/testsuite/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* gdb.python/py-unwind-maint.exp: Adjust tests to not expect that
unwinders are immediately called as side effect of "source" or
"disable unwinder" commands.
* gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
Currently gdb supports DW_OP_GNU_push_tls_address, but not
DW_OP_form_tls_address. I think it would be better if the toolchain
as a whole moved to using the standard opcode, and the prerequisite to
this is getting gdb to recognize it.
GCC can sometimes emit DW_OP_form_tls_address for emultls targets. As
far as I know, nobody has ever tried this with gdb (since it wouldn't
work at all).
I don't think there's a major drawback to using a single opcode for
all targets, because computing the location of a thread-local is
already target specific.
This is PR gdb/11616.
I don't know how to write a test case for this; though it's worth
noting that there aren't explicit tests for DW_OP_GNU_push_tls_address
either -- and if I change GCC, these paths will be tested to the same
extent they are now.
2016-09-02 Tom Tromey <tom@tromey.com>
PR gdb/11616:
* dwarf2read.c (decode_locdesc): Handle DW_OP_form_tls_address.
* dwarf2loc.c (dwarf2_compile_expr_to_ax): Handle
DW_OP_form_tls_address.
(locexpr_describe_location_piece): Likewise.
* dwarf2expr.h (struct dwarf_expr_context_funcs): Update comment.
* dwarf2expr.c (execute_stack_op): Handle DW_OP_form_tls_address.
(ctx_no_get_tls_address): Mention DW_OP_form_tls_address.
* compile/compile-loc2c.c (struct insn_info): Update comment.
(compute_stack_depth_worker): Handle DW_OP_form_tls_address.
This commit moves the target_wait prototype from the GDB-specific
target.h header to the common target/target.h header. Then, it
creates a compatible implementation of target_wait on gdbserver using
the_target->wait, and adjusts the (only) caller (mywait function).
Pretty straightforward, no regressions introduced.
gdb/gdbserver/ChangeLog:
2016-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* target.c (mywait): Call target_wait instead of
the_target->wait.
(target_wait): New function.
gdb/ChangeLog:
2016-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* target.c (target_wait): Mention that the function's prototype
can be found at target/target.h.
* target.h (target_wait): Move prototype from here...
* target/target.h (target_wait): ... to here.
This commit implements a new function, target_continue, on top of the
target_resume function. Then, it replaces all calls to target_resume
by calls to target_continue or to the already existing
target_continue_no_signal.
This is one of the (many) necessary steps needed to consolidate the
target interface between GDB and gdbserver. In particular, I am
interested in the impact this change will have on the unification of
the fork_inferior function (which I have been working on).
Tested on the BuildBot, no regressions introduced.
gdb/gdbserver/ChangeLog:
2016-09-31 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c (start_inferior): New variable 'ptid'. Replace calls
to the_target->resume by target_continue{,_no_signal}, depending
on the case.
* target.c (target_stop_and_wait): Call target_continue_no_signal
instead of the_target->resume.
(target_continue): New function.
gdb/ChangeLog:
2016-09-31 Sergio Durigan Junior <sergiodj@redhat.com>
* fork-child.c (startup_inferior): Replace calls to target_resume
by target_continue{,_no_signal}, depending on the case.
* linux-nat.c (cleanup_target_stop): Call
target_continue_no_signal instead of target_resume.
* procfs.c (procfs_wait): Likewise.
* target.c (target_continue): New function.
* target/target.h (target_continue): New prototype.
This patch replaces "keep things single" with "keep things simple".
gdb:
2016-08-31 Yao Qi <yao.qi@linaro.org>
* record-full.c (record_full_insert_breakpoint): Fix typo.
This inserts missing parentheses in the calculation of the comparison
result between two different inferior numbers. The problem was found by
Philipp Rudo.
gdb/ChangeLog:
* thread.c (tp_array_compar): Insert missing parentheses.
gdb/testsuite/ChangeLog:
* gdb.multi/tids.exp: Test "thread apply all".
C++ does not officially support designators in initializer lists. Thus
some compilers may issue errors when encountering them. Modern versions
of GCC seem to allow them by default, as a GCC extension, even though
the GCC documentation explicitly states otherwise: "[...] This extension
is not implemented in GNU C++." But some older GCC versions (like
4.4.7) did indeed emit an error instead, like this:
.../gdb/xtensa-config.c:219: error: expected primary-expression before
‘.’ token
This patch removes the only such instance I've seen when building with
'--enable-targets=all'.
gdb/ChangeLog:
* xtensa-tdep.h (XTENSA_GDBARCH_TDEP_INSTANTIATE): Replace
designated initializer list by plain initializer list, for C++
compliance.
GLIBC BZ#20311 [1] proc_service.h install patch also remove 'const'
attributes from ps_get_thread_area and comment #15 discuss why to remove
the const attribute (basically since it a callback with the struct
ps_prochandle owned by the client it should be able to modify it if
it the case).
On default build this is not the issue and current g++ does not trigger
any issue with this mismatch declaration. However, on some bootstrap
build configuration where gdbserver is build with gcc instead this
triggers:
error: conflicting types for 'ps_get_thread_area'
This patch fixes it by syncing the declaration with GLIBC.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20311
gdb/ChangeLog:
2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64-linux-nat.c (ps_get_thread_area): Remove const from
struct ps_prochandle.
* amd64-linux-nat.c (ps_get_thread_area): Likewise.
* arm-linux-nat.c (ps_get_thread_area): Likewise.
* gdb_proc_service.h (ps_get_thread_area): Likewise.
* i386-linux-nat.c (ps_get_thread_area): Likewise.
* m68klinux-nat.c (ps_get_thread_area): Likewise.
* mips-linux-nat.c (ps_get_thread_area): Likewise.
* nat/aarch64-linux.c (aarch64_ps_get_thread_area): Likewise.
* nat/aarch64-linux.h (aarch64_ps_get_thread_area): Likewise.
* xtensa-linux-nat.c (ps_get_thread_area): Likewise.
gdb/gdbserver/ChangeLog:
2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org>
PR server/20491
* gdb_proc_service.h (ps_get_thread_area): Remove const from struct
ps_prochandle.
* linux-aarch64-low.c (ps_get_thread_area): Likewise.
* linux-arm-low.c (ps_get_thread_area): Likewise.
* linux-crisv32-low.c (ps_get_thread_area): Likewise.
* linux-m68k-low.c (ps_get_thread_area): Likewise.
* linux-mips-low.c (ps_get_thread_area): Likewise.
* linux-nios2-low.c (ps_get_thread_area): Likewise.
* linux-tic6x-low.c (ps_get_thread_area): Likewise.
* linux-x86-low.c (ps_get_thread_area): Likewise.
* linux-xtensa-low.c (ps_get_thread_area): Likewise.
This patch allows the user to set the inferior-tty to "empty", in order
to come back to the default behaviour of using the same tty as gdb is
using.
This is already supported in MI (and tested in gdb.mi/mi-basics.exp).
I added a new test, set-inferior-tty.exp, where I test only the setting
and unsetting of the parameter. It would be nice to actually test that
the inferior output properly goes to the separate tty, but that will be
for another day.
gdb/ChangeLog:
* infcmd.c (set_inferior_io_terminal): Set inferior terminal to
NULL if terminal_name is an empty string.
(_initialize_infcmd): Make the argument of "set inferior-tty"
optional, mention it in the help doc.
gdb/doc/ChangeLog:
* gdb.texinfo (Input/Output): Mention possibility to unset
inferior-tty.
gdb/testsuite/ChangeLog:
* gdb.base/set-inferior-tty.exp: New file.
* gdb.base/set-inferior-tty.c: New file.
It is my understanding that GDB used to require each architecture to
define a Frame Pointer (fp). However, this functionality was deprecated
some time ago so the call to setup the fp_reg was changed to deprecated
(set_gdbarch_deprecated_fp_regnum). It should have been removed from the
Power code.
That said, the code "set_gdbarch_deprecated_fp_regnum
(gdbarch, PPC_R0_REGNUM + 1);" sets up register r1 as the frame pointer.
Register r1 is no longer used to hold the frame pointer on Power. By
removing the fp definition for Power in GDB, it causes GDB to fall back
to the call get_frame_base_address (frame) which returns the correct value
depending on the specific senario but most of the time is the DWARF
canonical frame address.
gdb/ChangeLog
2016-08-24 Carl Love <cel@us.ibm.com>
* rs6000-tdep.c (rs6000_gdbarch_init): Remove call
set_gdbarch_deprecated_fp_regnum() from initialization function.
This patch fixes a problem that problem triggers if you start an
inferior, e.g., with the "start" command, in a UI created with the
new-ui command, and then run a foreground execution command in the
main UI. Once the program stops for the latter command, typing in the
main UI no longer echoes back to the user.
The problem revolves around this:
- gdb_has_a_terminal computes its result lazily, on first call.
that is what saves gdb's initial main UI terminal state (the UI
associated with stdin):
our_terminal_info.ttystate = serial_get_tty_state (stdin_serial);
This is the state that target_terminal_ours() restores.
- In this scenario, the gdb_has_a_terminal function happens to be
first ever called from within the target_terminal_init call in
startup_inferior:
(top-gdb) bt
#0 gdb_has_a_terminal () at src/gdb/inflow.c:157
#1 0x000000000079db22 in child_terminal_init_with_pgrp () at src/gdb/inflow.c:217
[...]
#4 0x000000000065bacb in target_terminal_init () at src/gdb/target.c:456
#5 0x00000000004676d2 in startup_inferior () at src/gdb/fork-child.c:531
[...]
#7 0x000000000046b168 in linux_nat_create_inferior () at src/gdb/linux-nat.c:1112
[...]
#9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:657
If the command to start the inferior is issued on the main UI, then
readline will have deprepped the terminal when we reach the above, and
the problem doesn't appear.
If however the command is issued on a non-main UI, then when we reach
that gdb_has_a_terminal call, the main UI's terminal state is still
set to whatever readline has sets it to in rl_prep_terminal, which
happens to have echo disabled. Later, when the following synchronous
execution command finishes, we'll call target_terminal_ours to restore
gdb's the main UI's terminal settings, and that restores the terminal
state with echo disabled...
Conceptually, the fix is to move the gdb_has_a_terminal call earlier,
to someplace during GDB initialization, before readline/ncurses have
had a chance to change terminal settings. Turns out that
"set_initial_gdb_ttystate" is exactly such a place.
I say conceptually, because the fix actually inlines the
gdb_has_a_terminal part that saves the terminal state in
set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since
there's no point in making gdb_has_a_terminal do lazy computation.
gdb/ChangeLog:
2016-08-23 Pedro Alves <palves@redhat.com>
PR gdb/20494
* inflow.c (our_terminal_info, initial_gdb_ttystate): Update
comments.
(enum gdb_has_a_terminal_flag_enum, gdb_has_a_terminal_flag):
Delete.
(set_initial_gdb_ttystate): Record our_terminal_info here too,
instead of ...
(gdb_has_a_terminal): ... here. Reimplement in terms of
initial_gdb_ttystate. Make static.
* terminal.h (gdb_has_a_terminal): Delete declaration.
(set_initial_gdb_ttystate): Add comment.
* top.c (show_interactive_mode): Use input_interactive_p instead
of gdb_has_a_terminal.
gdb/testsuite/ChangeLog:
2016-08-23 Pedro Alves <palves@redhat.com>
PR gdb/20494
* gdb.base/new-ui-echo.c: New file.
* gdb.base/new-ui-echo.exp: New file.
Loading a core dump that was either generated on a system running
pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused
set in the environment, solib-svr4.c:svr4_current_sos fails to filter
out the vDSO, resulting in:
(gdb) core-file corefile.core^M
[New LWP 2362]^M
warning: Could not load shared library symbols for linux-vdso.so.1.^M
Do you need "set solib-search-path" or "set sysroot"?^M
Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M
...
The problem is that gdbarch_vsyscall_range does not support core
inferiors at all.
When live debugging, we're finding the vDSO's start address with
auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the
corresponding mapping, by parsing /proc/PID/maps. When debugging a
core dump, we can also determine the starting address from
auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core
mappings out of the host's /proc. But we can instead look for a
corresponding load segment in the core's bfd.
gdb/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* linux-tdep.c (linux_vsyscall_range_raw): For core inferiors,
find the vDSO's start address with AT_SYSINFO_EHDR too, and
determine the vDSO's size by finding the PT_LOAD segment that
matches AT_SYSINFO_EHDR.
gdb/testsuite/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* gdb.base/vdso-warning.exp: Test core dumps too. Use
with_test_prefix. Factor out bits to ...
(test_no_vdso): ... this new procedure.
Nowadays, we only match pre-indexed STP in prologue. Due to the change
in gcc, https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html, it
may generate "STP with base register" in prologue, which GDB doesn't
handle. That is to say, previously GCC generates prologue like this,
sub sp, sp, #490
stp x29, x30, [sp, #-96]!
mov x29, sp
with the gcc patch above, GCC generates prologue like like this,
sub sp, sp, #4f0
stp x29, x30, [sp]
mov x29, sp
This patch is to teach GDB to recognize this instruction in prologue
analysis.
gdb:
2016-08-19 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_analyze_prologue): Handle register
based STP instruction.
If I build gdb with -fsanitize=address and run tests, I get error,
malformed linespec error: unexpected colon^M
(gdb) PASS: gdb.linespec/ls-errs.exp: lang=C: break :
break :=================================================================^M
==3266==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000051451 at pc 0x2b5797a972a8 bp 0x7fffd8e0f3c0 sp 0x7fffd8e0f398^M
READ of size 2 at 0x602000051451 thread T0
#0 0x2b5797a972a7 in __interceptor_strlen (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x322a7)^M
#1 0x7bd004 in compare_filenames_for_search(char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:316^M
#2 0x7bd310 in iterate_over_some_symtabs(char const*, char const*, int (*)(symtab*, void*), void*, compunit_symtab*, compunit_symtab*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:411^M
#3 0x7bd775 in iterate_over_symtabs(char const*, int (*)(symtab*, void*), void*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:481^M
#4 0x7bda15 in lookup_symtab(char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:527^M
#5 0x7d5e2a in make_file_symbol_completion_list_1 /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5635^M
#6 0x7d61e1 in make_file_symbol_completion_list(char const*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5684^M
#7 0x88dc06 in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:288
....
0x602000051451 is located 0 bytes to the right of 1-byte region [0x602000051450,0x602000051451)^M
mallocated by thread T0 here:
#0 0x2b5797ab97ef in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547ef)^M
#1 0xbbfb8d in xmalloc /home/yao/SourceCode/gnu/gdb/git/gdb/common/common-utils.c:43^M
#2 0x88dabd in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:273^M
#3 0x88e5ef in location_completer(cmd_list_element*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:531^M
#4 0x8902e7 in complete_line_internal /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:964^
The code in question is here
file_to_match = (char *) xmalloc (colon - text + 1);
strncpy (file_to_match, text, colon - text + 1);
it is likely that file_to_match is not null-terminated. The patch is
to strncpy 'colon - text' bytes and explicitly set '\0'.
gdb:
2016-08-19 Yao Qi <yao.qi@linaro.org>
* completer.c (linespec_location_completer): Make file_to_match
null-terminated.
Running the fast tracepoints tests against x32 gdbserver exposes a
latent bug. E.g.,:
(gdb)
continue
Continuing.
Reading /media/sf_host-pedro/gdb/mygit/build-ubuntu-x32/gdb/testsuite/outputs/gdb.trace/change-loc/change-loc-2.sl from remote target...
Thread 1 "change-loc" received signal SIGSEGV, Segmentation fault.
func4 () at /home/pedro/gdb/src/gdb/testsuite/gdb.trace/change-loc.h:24
24 }
(gdb) FAIL: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2
The test sets a fast tracepoint on a shared library. On x32, shared
libraries end up loaded somewhere in the upper 2GB of the 4GB address
space x32 has access to. When gdbserver needs to copy an instruction
to execute it in the jump pad, it asks gdb to relocate/adjust it, with
the qRelocInsn packet. gdb converts "call" instructions into a "push
$<2GB-4GB addr> + jmp" sequence, however, the "pushq" instruction sign
extends its operand, so later when the called function returns, it
returns to an incorrectly sign-extended address. E.g.,
0xfffffffffabc0000 instead of 0xfabc0000, resulting in the
segmentation fault.
Fix this by converting calls at such addresses to "sub + mov + jmp"
sequences instead.
gdb/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* amd64-tdep.c (amd64_relocate_instruction) <callq>: Handle return
addresses over 0x7fffffff.
gdb/ChangeLog:
* MAINTAINERS (Write After Approval): Add "Carl Love".
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
The patch fixes the record support of Hardware Transactional Memory
instructions on Power. It also solves a large number of unexpected failures
from gdb.reverse testcases sigall-precsave.exp and sigall-reverse.exp that
occur on distros which glibc uses HTM instructions.
gdb/ChangeLog
2016-08-18 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* rs6000-tdep.c (ppc_process_record_op31): Handle HTM instructions.
This error message should not contain the word symbol:
(gdb) remove-inferiors 1
Warning: Can not remove current symbol inferior 1.
gdb/ChangeLog:
* inferior.c (remove_inferior_command): Fix error message.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Fix
expected error message.
GLIBC BZ#20311 introduced a change to install proc_service.h so that gdb
didn't have to use the version it embeds in gdb_proc_service.h. The
embedded version is guarded by HAVE_PROC_SERVICE_H and
gdb_proc_service.h has a number other of includes and definitions, all
of which are uncondional except for an include for gregset.h. This is
only included if HAVE_PROC_SERIVCE_H is not defined.
This causes a build failure when cross compiling gdb with the latest
glibc because type definitions in gregset are used independently of
HAVE_PROC_SERIVCE_H. In particular, they are used in gdb_proc_service.h
when PRFPREGSET_T_BROKEN is set.
The error messages on the failure are
----
binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does
not name a type; did you mean ‘elf_fpregset_t’?
typedef gdb_fpregset_t gdb_prfpregset_t;
^~~~~~~~~~~~~~
elf_fpregset_t
binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does
not name a type; did you mean ‘elf_fpregset_t’?
typedef gdb_fpregset_t gdb_prfpregset_t;
^~~~~~~~~~~~~~
elf_fpregset_t
binutils-gdb/gdb/proc-service.c:218:15: error: ‘gdb_prfpregset_t’ does
not name a type; did you mean ‘gdb_fpregset_t’?
const gdb_prfpregset_t *fpregset)
^~~~~~~~~~~~~~~~
gdb_fpregset_t
----
This patch moves the include for gregset.h to before the code guarded by
HAVE_PROC_SERIVCE_H, so that it is always included. This is enough to
fix the build.
2016-08-15 Matthew Wahab <matthew.wahab@arm.com>
PR gdb/20457
* gdb_proc_service.h: Add an include of gregset.h
[!HAVE_PROC_SERVICE_H]: Remove the include of gregset.h.
I build GDB with -fsanitize=address, and see the error in tests,
(gdb) PASS: gdb.linespec/ls-errs.exp: lang=C++: break 3 foo
break -line 3 foo^M
=================================================================^M
==4401==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000047487 at pc 0x819d8e bp 0x7fff4e4e6bb0 sp 0x7fff4e4e6ba8^M
READ of size 1 at 0x603000047487 thread T0^[[1m^[[0m^M
#0 0x819d8d in explicit_location_lex_one /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:502^M
#1 0x81a185 in string_to_explicit_location(char const**, language_defn const*, int) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:556^M
#2 0x81ac10 in string_to_event_location(char**, language_defn const*) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:687^
the code in question is:
> /* Special case: C++ operator,. */
> if (language->la_language == language_cplus
> && strncmp (*inp, "operator", 8) <--- [1]
> && (*inp)[9] == ',')
> (*inp) += 9;
> ++(*inp);
The error is caused by the access to (*inp)[9] if 9 is out of its bounds.
However [1] looks odd to me, because if strncmp returns true (non-zero),
the following check "(*inp)[9] == ','" makes no sense any more. I
suspect it was a typo in the code we meant to "strncmp () == 0". Another
problem in the code above is that if *inp is "operator,", we first
increment *inp by 9, and then increment it by one again, which is wrong
to me. We should only increment *inp by 8 to skip "operator", and go
back to the loop header to decide where we stop.
gdb:
2016-08-15 Yao Qi <yao.qi@linaro.org>
* location.c (explicit_location_lex_one): Compare the return
value of strncmp with zero. Don't check (*inp)[9]. Increment
*inp by 8.
Fixes, on NIOS GNU/Linux:
In file included from
/scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../nat/linux-ptrace.c:26:0:
/scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../gregset.h:27:23:
error: unknown type name 'gregset_t'
#define GDB_GREGSET_T gregset_t
^
Fix this by including sys/procfs.h directly. We shouldn't really be
including a gdb-only header in a gdb/nat/ file, anyway. Whoops.
gdb/ChangeLog:
2016-08-11 Pedro Alves <palves@redhat.com>
PR gdb/20413
* nat/linux-ptrace.c: Include <sys/procfs.h> instead of
"gregset.h".
Right after a fork is detected, we detach breakpoints from the child
(detach_breakpoints), which calls into target_remove_breakpoint with
inferior_ptid pointing at the child process, but leaves the breakpoint
marked inserted (in the parent).
The problem is that record-full.c always deletes all knowledge of the
breakpoint. Then when we later really delete the breakpoint from the
parent, we fail the assertion, since the breakpoint is unexpectedly
not found in the record-full.c breakpoint table.
The fix is simply to not forget about the breakpoint if we're
detaching it from a fork child.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* record-full.c (record_full_remove_breakpoint): Don't remove the
breakpoint from the record_full_breakpoints VEC if we're detaching
the breakpoint from a fork child.
gdb/testsuite/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* gdb.reverse/waitpid-reverse.exp: Add comment and remove
setup_kfails.
Makes the code more obvious.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* breakpoint.c (insertion_state_t): Delete.
(enum remove_bp_reason): New.
(detach_breakpoints, remove_breakpoint_1, remove_breakpoint):
Adjust to use enum remove_bp_reason instead of insertion_state_t.
All callers pass mark_uninserted, so there's no need for the 'is'
parameter.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* breakpoint.c (remove_breakpoint): Remove 'is' parameter and
always pass mark_uninserted to remove_breakpoint_1.
(insert_breakpoint_locations, remove_breakpoints)
(remove_breakpoints_pid, update_global_location_list): Update
callers.
This is done by catching an exception number 0x406d1388 (it has no
documented name, though MSDN dubs it "MS_VC_EXCEPTION" in one code
example), which is thrown by the program. The exception record
contains an ID of a thread and a name to give it.
This requires rolling back some changes in handle_exception(), which
now again returns more than two distinct values. The new
HANDLE_EXCEPTION_IGNORED value means that gdb should just continue,
without returning the thread ID up the stack (which would result in
further handling of the exception, which is not what we want).
gdb/ChangeLog:
2016-08-10 Руслан Ижбулатов <lrn1986@gmail.com>
Pedro Alves <palves@redhat.com>
* windows-nat.c (MS_VC_EXCEPTION): New define.
(handle_exception_result): New enum.
(windows_delete_thread): Free the thread's name.
(handle_exception): Handle MS_VC_EXCEPTION.
(get_windows_debug_event): Handle HANDLE_EXCEPTION_IGNORED.
(windows_thread_name): New function.
(windows_target): Install it as to_thread_name method.
* NEWS: Mention the thread naming support on MS-Windows.
The ARI complains about this new file:
common/signals-state-save-restore.c:46: warning: gettext: All messages should be marked up with _.
common/signals-state-save-restore.c:59: warning: gettext: All messages should be marked up with _.
common/signals-state-save-restore.c:87: warning: gettext: All messages should be marked up with _.
common/signals-state-save-restore.c:92: warning: gettext: All messages should be marked up with _.
Since these are untranslatable strings, use () instead of _().
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
* common/signals-state-save-restore.c
(save_original_signals_state, restore_original_signals_state):
Wrap perror_with_name arguments with '()'.
When executing commands on a secondary UI running the MI interpreter,
some commands that should be synchronous are not. MI incorrectly
continues processing input right after the synchronous command is
sent, before the target stops.
The problem happens when we emit MI async events (=library-loaded,
etc.), and we go about restoring the previous terminal state, we end
up calling target_terminal_ours, which incorrectly always installs the
current UI's input_fd in the event loop... That is, code like this:
old_chain = make_cleanup_restore_target_terminal ();
target_terminal_ours_for_output ();
fprintf_unfiltered (mi->event_channel, "library-loaded");
...
do_cleanups (old_chain);
The fix is to move the add_file_handler/delete_file_handler calls out
of target_terminal_$foo, making these completely no-ops unless called
with the main UI as current UI.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/20418
* event-top.c (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New functions.
(async_enable_stdin): Register input in the event loop.
(async_disable_stdin): Unregister input from the event loop.
(gdb_setup_readline): Register input in the event loop.
* infrun.c (check_curr_ui_sync_execution_done): Register input in
the event loop.
* target.c (target_terminal_inferior): Don't unregister input from
the event loop.
(target_terminal_ours): Don't register input in the event loop.
* target.h (target_terminal_inferior)
(target_terminal_ours_for_output, target_terminal_ours): Update
comments.
* top.h (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New declarations.
* utils.c (ui_unregister_input_event_handler_cleanup)
(prepare_to_handle_input): New functions.
(defaulted_query, prompt_for_continue): Use
prepare_to_handle_input.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20418
* gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files.
* lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
