Andrew Burgess [Fri, 16 Oct 2015 09:58:02 +0000 (11:58 +0200)]
objdump: Handle 32-bit base address in debug_ranges / debug_loc.
When the DWARF address size is 32-bit, but the host machine is 64-bit,
objdump fails to spot base addresses specified in the .debug_ranges and
.debug_loc lists.
As an example, here is the output when dumping an example .debug_ranges
section with the pre-patched objdump:
Pedro Alves [Sat, 28 Nov 2015 16:39:32 +0000 (16:39 +0000)]
Adjust GDB to demangler API change
Before commit 3a8724032abf, DEMANGLE_COMPONENT_CAST was used for both
casts and conversion operators. We now have
DEMANGLE_COMPONENT_CONVERSION for the latter.
gdb/ChangeLog:
2014-11-28 Pedro Alves <palves@redhat.com>
* cp-name-parser.y (conversion_op): Use
DEMANGLE_COMPONENT_CONVERSION instead of DEMANGLE_COMPONENT_CAST.
Maxim Ostapenko [Sat, 28 Nov 2015 16:39:32 +0000 (16:39 +0000)]
libsanitizer merge from upstream r250806, compiler part.
gcc/
* asan.c (asan_emit_stack_protection): Don't pass local stack to
asan_stack_malloc_[n] anymore. Check if asan_stack_malloc_[n] returned
NULL and use local stack than.
(asan_finish_file): Insert __asan_version_mismatch_check_v[n] call
in addition to __asan_init.
* sanitizer.def (BUILT_IN_ASAN_INIT): Rename to __asan_init.
(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK): Add new builtin call.
* asan.h (asan_intercepted_p): Handle new string builtins.
* ubsan.c (ubsan_use_new_style_p): New function.
(ubsan_instrument_float_cast): If location is unknown, assign
input_location to loc. Propagate loc to ubsan_create_data if
ubsan_use_new_style_p returned true.
config/
* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
LSAN_OPTIONS=detect_leaks.
Rainer Orth [Sat, 28 Nov 2015 16:39:32 +0000 (16:39 +0000)]
Port libvtv to Solaris
libstdc++-v3:
* acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY) <solaris2*>: Use
-Wl,-R in VTV_CXXLINKFLAGS.
* configure: Regenerate.
* testsuite/18_support/bad_exception/23591_thread-1.c: Use
-fvtable-verify=none on Solaris 12+.
libgcc:
* Makefile.in (VTV_CFLAGS): New variable.
(vtv_start$(objext), vtv_end$(objext), vtv_end$(objext))
(vtv_start_preinit$(objext), vtv_end_preinit$(objext)): Use it.
* config.host (*-*-solaris2*): Add t-crtstuff-pic to tmake_file.
Add vtv_start.o, vtv_end.o, vtv_start_preinit.o, vtv_end_preinit.o
to extra_parts if $enable_vtable_verify = yes.
libvtv:
* configure.tgt (*-*-solaris2.[1-9]*): Declare supported.
* configure.ac: Call AC_USE_SYSTEM_EXTENSIONS.
<*-*-solaris2*>: Check for init priority support.
Check for getexecname, __fortify_fail, _obstack_begin.
(VTV_NO_OBSTACK): New conditional.
* configure: Regenerate.
* Makefile.am [VTV_NO_OBSTACK] (obstack.c): Use new condition.
Create empty config.h
* Makefile.in: Regenerate.
* vtv_rts.cc [HAVE_GETEXECNAME] (program_invocation_name): New
variable.
(read_section_offset_and_length) [HAVE_GETEXECNAME]: Set it.
(dl_iterate_phdr_callback) [HAVE_GETEXECNAME]: Set it.
(__fortify_fail): Wrap in HAVE___FORTIFY_FAIL
[!HAVE___FORTIFY_FAIL]: Provide non-Cygwin implementation.
(read_section_offset_and_length): Assert sh_size >= VTV_PAGE_SIZE.
(iterate_modules): Fix typo.
Use VTV_PAGE_SIZE.
(dl_iterate_phdr_callback): Fix typo.
Use VTV_PAGE_SIZE.
(__VLTChangePermission): Fix typos.
The 'function_temp<int>' instantiation above mangles to:
_Z13function_tempIiEv1AIXszcvT_Li999EEE
The demangler parses this as:
typed name
template
name 'function_temp'
template argument list
builtin type int
function type
builtin type void
argument list
template (*)
name 'A'
template argument list
unary operator
operator sizeof
unary operator
cast
template parameter 0 (**)
literal
builtin type int
name '999'
And after the fix for 59195, due to:
static void
d_print_cast (struct d_print_info *dpi, int options,
const struct demangle_component *dc)
{
...
/* For a cast operator, we need the template parameters from
the enclosing template in scope for processing the type. */
if (dpi->current_template != NULL)
{
dpt.next = dpi->templates;
dpi->templates = &dpt;
dpt.template_decl = dpi->current_template;
}
when printing the template argument list of A (what should be "<sizeof
(int)>"), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print. This leads to infinite recursion, and stack exaustion. The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.
Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:
struct A { template <typename U> explicit operator U(); };
We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.
The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.
Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.
I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:
leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.
g++'s testsuite actually generates three symbols that crash the
demangler in the same way. I've added those as tests in the demangler
testsuite as well.
And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957
Bootstrapped and regtested on x86_64 Fedora 20.
Also ran this through GDB's testsuite. GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.
libiberty/
2015-11-27 Pedro Alves <palves@redhat.com>
PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
<DEMANGLE_COMPONENT_CONVERSION>: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this. Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.
Iain Sandoe [Sat, 28 Nov 2015 16:39:30 +0000 (16:39 +0000)]
Fix PR63758 by using the _NSGetEnviron() API on Darwin
include/
Roland McGrath <roland@gnu.org>
PR other/63758
* environ.h: New file.
libiberty/
Roland McGrath <roland@gnu.org>
Iain Sandoe <iain@codesourcery.com>
PR other/63758
* pex-unix.c: Obtain the environment interface from settings in environ.h
rather than in-line code. Update copyright date.
* setenv.c: Likewise.
* xmalloc.c: Likewise.
Mikhail Maltsev [Sat, 28 Nov 2015 16:39:29 +0000 (16:39 +0000)]
Fix several crashes of C++ demangler on fuzzed input.
libiberty/
* cp-demangle.c (d_dump): Fix syntax error.
(d_identifier): Adjust type of len to match d_source_name.
(d_expression_1): Fix out-of-bounds access. Check code variable for
NULL before dereferencing it.
(d_find_pack): Do not recurse for FIXED_TYPE, DEFAULT_ARG and NUMBER.
(d_print_comp_inner): Add NULL pointer check.
* cp-demangle.h (d_peek_next_char): Define as inline function when
CHECK_DEMANGLER is defined.
(d_advance): Likewise.
* testsuite/demangle-expected: Add new testcases.
ARMv8.2 adds 16-bit floating point operations as an optional extension
to the ARMv8 FP support. This patch adds the new FP16 instructions,
making them available when the architecture extension +fp+fp16 is
specified.
The instructions added are:
- Comparisons and conditionals: FCMP, FCCMPE, FCMP, FCMPE and FCSEL.
- Arithmetic: FABS, FNEG, FSQRT, FMUL, FDIV, FADD, FSUB, FMADD, FMSUB,
FNMADD and FNMSUB.
- Rounding: FRINTN, FRINTP, FRINTM, FRINTZ, FRINTA, FRINTX and FRINTI.
- Conversions: SCVTF (fixed-point), SCVTF (integer), UCVTF (fixed-point)
UCVTF (integer), FCVTZS (fixed-point), FCVTZS (integer), FCVTZU
(fixed-point), FCVTZU (integer), FCVTNS, FCVTNU, FCVTAS, FCVTAU,
FCVTPS, FCVTPU, FCVTMS and FCVTMU.
- Scalar FMOV: immediate, general and register
gas/testsuite/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
Matthew Wahab [Fri, 27 Nov 2015 16:25:52 +0000 (16:25 +0000)]
[AArch64][PATCH 2/3] Adjust a utility function for floating point values.
ARMv8.2 adds 16-bit floating point operations as an optional
extension. This patch adjusts the utility function expand_fp_imm to
support 16-bit values.
The function is intended to convert an 8-bit immediate representing a
floating point value to a representation that can be passed to
fprintf. Because of the limited use of the results, the only change made
to the function is to treat a request for a 16-bit float as a request
for a 32-bit float.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-opc.c (half_conv_t): New.
(expand_fp_imm): Replace is_dp flag with the parameter size to
specify the number of bytes for the required expansion. Treat
a 16-bit expansion like a 32-bit expansion. Add check for an
unsupported size request. Update comment.
(aarch64_print_operand): Update to support 16-bit floating point
values. Update for changes to expand_fp_imm.
Matthew Wahab [Fri, 27 Nov 2015 15:47:53 +0000 (15:47 +0000)]
[AArch64][PATCH 1/3] Support ARMv8.2 FP16 floating point instructions.
ARMv8.2 adds 16-bit floating point operations as an optional extension
to the ARMv8 FP support. This patch set adds support for the 16-bit FP
instructions to binutils, enabling the instructions when both +fp and
+fp16 architecture extensions are enabled.
The patches in this series:
- Add a feature macro for use by the encoding/decoding mechanism.
- Adjust a utility function, used when disassembling, to support 16-bit
floating point values.
- Add the new scalar floating-point instructions.
This patch adds the feature macro FP_F16 to the AArch64 encoding/decoding
mechanism, enabling it when both +fp and +fp16 are selected.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
Matthew Wahab [Fri, 27 Nov 2015 15:25:08 +0000 (15:25 +0000)]
[AArch64] Add ARMv8.2 instructions BFC and REV64.
ARMv8.2 adds two new instructions: BFC as an alias for BFM and REV64 as
an alias for REV. This patch set adds support for these to binutils,
enabled when the -march=armv8.2-a is given. It depends on the support
for an instruction being its preferred form which was added in an
earlier patch.
This patch adds the alias BFC <Rd>, #<imm>, #<width> as the preferred
form for BFM when the source is a zero register and the conditions for
using the BFI form are met (in other words, BFC is the preferred form
for BFI <Rd>, <Rs>, #<imm>, #<width> when the <Rs> is a zero register).
gas/testsuite/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
Matthew Wahab [Fri, 27 Nov 2015 15:02:26 +0000 (15:02 +0000)]
[AArch64] Let aliased instructions be their preferred form.
Although the AArch64 backend supports aliased instructions, the aliasing
forms are always preferred over the real instruction. This makes it
awkward to handle instructions which have aliases but which are their
own preferred form.
This patch includes the instruction being aliased in the list of
alternatives which is searched when considering which form to use.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-dis.c: Weaken assert.
* aarch64-gen.c: Include the instruction in the list of its
possible aliases.
Yao Qi [Fri, 27 Nov 2015 14:53:32 +0000 (14:53 +0000)]
[AArch64] Only check breakpoint alignment on inserting
This patch fixes the GDB internal error on AArch64 when running
watchpoint-fork.exp
top?bt 15
internal_error (file=file@entry=0x79d558 "../../binutils-gdb/gdb/linux-nat.c", line=line@entry=4866, fmt=0x793b20 "%s: Assertion `%s' failed.")
at ../../binutils-gdb/gdb/common/errors.c:51
#1 0x0000000000495bc4 in linux_nat_thread_address_space (t=<optimized out>, ptid=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/linux-nat.c:4866
#2 0x00000000005db2c8 in delegate_thread_address_space (self=<optimized out>, arg1=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/target-delegates.c:2447
#3 0x00000000005e8c7c in target_thread_address_space (ptid=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/target.c:2727
#4 0x000000000054eef8 in get_thread_arch_regcache (ptid=..., gdbarch=0xad51e0) at ../../binutils-gdb/gdb/regcache.c:529
#5 0x000000000054efcc in get_thread_regcache (ptid=...) at ../../binutils-gdb/gdb/regcache.c:546
#6 0x000000000054f120 in get_thread_regcache_for_ptid (ptid=...) at ../../binutils-gdb/gdb/regcache.c:560
#7 0x00000000004a2278 in aarch64_point_is_aligned (is_watchpoint=0, addr=34168, len=2) at ../../binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:122
#8 0x00000000004a2e68 in aarch64_handle_breakpoint (type=hw_execute, addr=34168, len=2, is_insert=0, state=0xae8880)
at ../../binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:465
#9 0x000000000048edf0 in aarch64_linux_remove_hw_breakpoint (self=<optimized out>, gdbarch=<optimized out>, bp_tgt=<optimized out>)
at ../../binutils-gdb/gdb/aarch64-linux-nat.c:657
#10 0x00000000005da8dc in delegate_remove_hw_breakpoint (self=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
at ../../binutils-gdb/gdb/target-delegates.c:492
#11 0x0000000000536a24 in bkpt_remove_location (bl=<optimized out>) at ../../binutils-gdb/gdb/breakpoint.c:13065
#12 0x000000000053351c in remove_breakpoint_1 (bl=0xb3fe70, is=is@entry=mark_inserted) at ../../binutils-gdb/gdb/breakpoint.c:4026
#13 0x000000000053ccc0 in detach_breakpoints (ptid=...) at ../../binutils-gdb/gdb/breakpoint.c:3930
#14 0x00000000005a3ac0 in handle_inferior_event_1 (ecs=0x7ffffff048) at ../../binutils-gdb/gdb/infrun.c:5042
After the fork, GDB will physically remove the breakpoints from the child
process (in frame #14), but at that time, GDB doesn't create an inferior
yet for child, but inferior_ptid is set to child's ptid (in frame #13).
In aarch64_point_is_aligned, we'll get the regcache of current_lwp_ptid
to determine if the current process is 32-bit or 64-bit, so the inferior
can't be found, and the internal error is caused.
I don't find a better fix other than not checking alignment on removing
breakpoint.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* nat/aarch64-linux-hw-point.c (aarch64_dr_state_remove_one_point):
Don't assert on alignment.
(aarch64_handle_breakpoint): Only check alignment when IS_INSERT
is true.
Yao Qi [Fri, 27 Nov 2015 14:50:30 +0000 (14:50 +0000)]
New test gdb.arch/arm-neon.exp
Both ARM and AArch64 have defined some SIMD data types in arm_neon.h,
but we don't have a test case for passing them and returning them in
inferior call. This test also covers passing and returning
homogeneous short vector aggregate (defined by AArch64 ABI document)
in inferior call too.
Yao Qi [Fri, 27 Nov 2015 14:50:30 +0000 (14:50 +0000)]
[AArch64] Handle HFA and HVA together
AArch64 AAPCS defined HFA (homogeneous floating-point aggregate)
and HVF (homogeneous short vector aggregate), bug GDB only handles the
former. In the AAPCS doc, both types are treated exactly the same
in terms of alignment and passing locations (on registers or stack).
This patch is to extend is_hfa to handle both HFA and HVA.
Yao Qi [Fri, 27 Nov 2015 14:50:30 +0000 (14:50 +0000)]
[AArch64] Support gnu vector in inferior call
As defined in AArch64 AAPCS, short vectors are passed through V
registers, and its maximum alignment is 16-byte. This patch is
to reflect these rules in GDB. This patch fixes some fails in
gdb.base/gnu_vector.exp.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_type_align): For vector type, return
its length, but with the maximum of 16 bytes.
(is_hfa): Return zero for vector type.
(aarch64_push_dummy_call): Handle short vectors.
(aarch64_extract_return_value): Likewise.
(aarch64_store_return_value): Likewise.
Yao Qi [Fri, 27 Nov 2015 14:21:47 +0000 (14:21 +0000)]
Allow multiple occurrences of the frames-invalid annotation in gdb.cp/annota2.exp
Hi,
I see one fail on aarch64-linux testing,
FAIL: gdb.cp/annota2.exp: watch triggered on a.x (timeout)
because GDB prints two frames-invalid annotation but the test expects
only one.
next^M
^M
^Z^Zpost-prompt^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
^M
^Z^Zframes-invalid^M
^M
Note I also see the fail on Debian-s390x-m64 too.
https://sourceware.org/ml/gdb-testers/2015-q4/msg07291.html
The test shouldn't only expect one frames-invalid annotation, because
there can be multiple times of stop/resume before the user visible
stop. Ulrich did something similar before
https://www.sourceware.org/ml/gdb-patches/2009-06/msg00118.html
This patch only changes ${frames_invalid} to \(${frames_invalid}\)*
in the regexp pattern.
The patch below fixes the fail on aarch64-linux.
gdb/testsuite:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* gdb.cp/annota2.exp: Allow multiple occurrences of the
frames-invalid annotation.
Matthew Wahab [Fri, 27 Nov 2015 13:44:10 +0000 (13:44 +0000)]
[Aarch64] Support an ARMv8.2 system register.
ARMv8.2 adds a new system register id_aa64mmfr2_el1. This patch adds
support for the register to binutils, making it available when
-march=armv8.2-a is selected.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
Matthew Wahab [Fri, 27 Nov 2015 13:19:50 +0000 (13:19 +0000)]
[AArch64] Add feature flags and command line for ARMv8.2 FP16 support.
ARMv8.2 adds optional support for 16-bit operations to the FP and
Adv.SIMD instructions. This patch adds a feature macro for this support
with a new command line option "+fp16" to enable/disable it.
Although the command line option is added as an architecture extension,
it only affects instructions available with when +fp or +simd is
enabled. If +fp16 is specified then it will also enable +fp.
There are currently no FP16 instructions implemented in binutils, this
patch is to enable subsequent work on supporting the extension.
gas/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
Simon Marchi [Thu, 26 Nov 2015 14:49:04 +0000 (09:49 -0500)]
Add test for thread names
I couldn't find a test that verified the thread name functionality, so I
created a new one.
A target board can define gdb,no_thread_names if it doesn't support thread
names and wants to skip the tests that uses them.
This test has been made with Linux in mind. Not all platforms use
pthread_setname_np to set the thread name, but some #ifdefs can be added
later in order to support other platforms.
Tested on x86-64 Ubuntu 14.04, native and remote.
gdb/testsuite/ChangeLog:
* gdb.threads/names.exp: New file.
* gdb.threads/names.c: New file.
* README: Mention gdb,no_thread_names.
Simon Marchi [Thu, 26 Nov 2015 14:49:04 +0000 (09:49 -0500)]
Display names of remote threads
This patch adds support for thread names in the remote protocol, and
updates gdb/gdbserver to use it. The information is added to the XML
description sent in response to the qXfer:threads:read packet.
gdb/ChangeLog:
* linux-nat.c (linux_nat_thread_name): Replace implementation by call
to linux_proc_tid_get_name.
* nat/linux-procfs.c (linux_proc_tid_get_name): New function,
implementation inspired by linux_nat_thread_name.
* nat/linux-procfs.h (linux_proc_tid_get_name): New declaration.
* remote.c (struct private_thread_info) <name>: New field.
(free_private_thread_info): Free name field.
(remote_thread_name): New function.
(thread_item_t) <name>: New field.
(clear_threads_listing_context): Free name field.
(start_thread): Get name xml attribute.
(thread_attributes): Add "name" attribute.
(remote_update_thread_list): Copy name field.
(init_remote_ops): Assign remote_thread_name callback.
* target.h (target_thread_name): Update comment.
* NEWS: Mention remote thread name support.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_target_ops): Use linux_proc_tid_get_name.
* server.c (handle_qxfer_threads_worker): Refactor to include thread
name in reply.
* target.h (struct target_ops) <thread_name>: New field.
(target_thread_name): New macro.
gdb/doc/ChangeLog:
* gdb.texinfo (Thread List Format): Mention thread names.
Simon Marchi [Thu, 26 Nov 2015 14:49:03 +0000 (09:49 -0500)]
Constify thread name return path
Since this code path returns a string owned by the target (we don't know how
it's allocated, could be a static read-only string), it's safer if we return
a constant string. If, for some reasons, the caller wishes to modify the
string, it should make itself a copy.
Markus Metzger [Thu, 19 Nov 2015 13:33:41 +0000 (14:33 +0100)]
btrace: diagnose "record btrace pt" without libipt
If GDB has been configured without libipt support, i.e. HAVE_LIBIPT is
undefined, and is running on a system that supports Intel(R) Processor Trace,
GDB will run into an internal error when trying to decode the trace.
(gdb) record btrace
(gdb) s
usage (name=0x7fffffffe954 "fib-64")
at src/fib.c:12
12 fprintf(stderr, "usage: %s <num>\n", name);
(gdb) info record
Active record target: record-btrace
Recording format: Intel(R) Processor Trace.
Buffer size: 16kB.
gdb/btrace.c:971: internal-error: Unexpected branch trace format.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This requires a system with Linux kernel 4.1 or later running on a 5th
Generation Intel Core processor or later.
The issue is documented as PR 19297.
When trying to enable branch tracing, in addition to checking the target
support for the requested branch tracing format, also check whether GDB
supports. it.
gdb/
* btrace.c (btrace_enable): Check whether HAVE_LIBIPT is defined.
testsuite/
* lib/gdb.exp (skip_btrace_pt_tests): Check for a "GDB does not
support" error.
* gas/arm/thumb2_ldr_immediate_armv6t2.s: Added high register
tests.
* gas/arm/thumb2_ldr_immediate_armv6t2.d: Accounted for new test
cases.
* gas/arm/thumb2_ldr_immediate_highregs_armv6t2.s: New.
* gas/arm/thumb2_ldr_immediate_highregs_armv6t2.d: New.
Pedro Alves [Tue, 24 Nov 2015 18:11:22 +0000 (18:11 +0000)]
List checkpoints in ascending order
Before:
(gdb) info checkpoints
3 process 29132 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
After:
(gdb) info checkpoints
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
3 process 29132 at 0x4008ad, file foo.c, line 81
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Pedro Alves [Tue, 24 Nov 2015 18:11:21 +0000 (18:11 +0000)]
List inferiors/threads/pspaces in ascending order
Before:
(gdb) info threads
Id Target Id Frame
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
After:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
gdb/doc/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.texinfo (Inferiors and Programs): Adjust "maint info
program-spaces" example to ascending order listing.
(Threads): Adjust "info threads" example to ascending order
listing.
(Forks): Adjust "info inferiors" example to ascending order
listing.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* inferior.c (add_inferior_silent): Append the new inferior to the
end of the list.
* progspace.c (add_program_space): Append the new pspace to the
end of the list.
* thread.c (new_thread): Append the new thread to the end of the
list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
Pedro Alves [Tue, 24 Nov 2015 18:11:20 +0000 (18:11 +0000)]
Linux: dump the signalled thread first
... like the kernel does.
gcore-thread.exp has a check to make sure the signalled thread is the
current thread after loading the core back, but that just works by
accident, because the signalled thread happened to be the last thread
on the thread list, and gdb currently iterates over threads in reverse
order.
So this fixes gcore-thread.exp once we start walking threads in
ascending number.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
* linux-tdep.c (find_stop_signal): Delete.
(struct linux_corefile_thread_data) <pid>: Remove field.
(linux_corefile_thread_callback): Rename to ...
(linux_corefile_thread): ... this. Now takes a struct
linux_corefile_thread_data pointer rather than a void pointer.
Remove thread state and thread pid checks.
(linux_make_corefile_notes): Prefer dumping the signalled thread
first. Use ALL_NON_EXITED_THREADS instead of
iterate_over_threads.
Matthew Wahab [Tue, 24 Nov 2015 10:21:52 +0000 (10:21 +0000)]
[ARM][GAS] Fix invalid arm-wince-pe tests.
There are a number of failures for the arm-wince-pe targets, most are due
to the test being invalid for the target.
This patch adjusts the invalid tests to either make them valid or to set
them as skipped for arm-wince-pe targets.
gas/testsuite
2015-11-24 Matthew Wahab <matthew.wahab@arm.com>
* gas/arm/armv7e-m+fpv5-d16.d: Skip test for *-*-pe, *-wince-* and
for *-*-coff targets.
* gas/arm/armv7e-m+fpv5-sp-d16.d: Likewise.
* gas/arm/blx-bl-convert.d: Likewise.
* gas/arm/ldst-offset0.d: Likewise.
* gas/arm/thumb2_ldr_immediate_armv6t2.d: Likewise.
* gas/arm/armv8-a+pan.s: Adjust test to make it
valid for non-ELF targets.
* gas/arm/wince.d: Add assembler option "-mccs".
* gas/arm/wince_inst.d: Update expected output.
Simon Marchi [Mon, 23 Nov 2015 23:47:09 +0000 (18:47 -0500)]
Fix internal error when saving fast tracepoint definitions
When trying to save fast tracepoints to file, gdb returns internal failure:
gdb/breakpoint.c:13446: internal-error: unhandled tracepoint type 27
A problem internal to GDB has been detected, further debugging may prove unreliable.
And no file including the fast tracepoints definition is created.
The patch also extends save-trace.exp to test saving tracepoint with a
fast tracepoint in there. Note that because this test doesn't actually
inserts the tracepoints in the program, we can run it with targets that
don't actually support fast tracepoints (or tracepoints at all).
gdb/ChangeLog:
* breakpoint.c (tracepoint_print_recreate): Fix logic error
if -> else if.
gdb/testsuite/ChangeLog:
* gdb.trace/actions.c: Include trace-common.h.
(main): Add a location for a fast tracepoint.
* gdb.trace/save-trace.exp: Set a fast tracepoint in addition to
the normal tracepoints.
(gdb_verify_tracepoints): Adjust number of expected tracepoints.
Simon Marchi [Mon, 23 Nov 2015 23:47:08 +0000 (18:47 -0500)]
Refactor gdb.trace/save-trace.exp
Some code is duplicated, to run the test twice with absolute and
relative paths, so I factored it out in a few procs. It uses
with_test_prefix to differentiate between test runs.
I replaced usages of "save-tracepoints" with "save tracepoint", since
the former is deprecated.
I also removed the "10.x", as it doesn't make much sense anymore. It
isn't used in general in the testsuite, and I don't think it's really
useful.
gdb/testsuite/ChangeLog:
* save-trace.exp: Factor out code to these...
(gdb_save_tracepoints): New.
(gdb_load_tracepoints): New.
(do_save_load_test): New.
Kevin Buettner [Sat, 14 Nov 2015 20:15:45 +0000 (13:15 -0700)]
minsyms.c: Scan backwards over all zero sized symbols.
The comment for the code in question says:
/* If the minimal symbol has a zero size, save it
but keep scanning backwards looking for one with
a non-zero size. A zero size may mean that the
symbol isn't an object or function (e.g. a
label), or it may just mean that the size was not
specified. */
As written, the code in question will only scan past the first symbol
of zero size. My change fixes the implementation to match the
comment.
Having this correct is important when the compiler generates several
local labels that are left in place by the linker. (I've been told
that the linker should eliminate these symbols, but I know of one
architecture for which this is not happening.)
I've created a test case called asmlabel.c. It's pretty simple:
main (int argc, char **argv)
{
asm ("L0:");
v = 0;
asm ("L1:");
v = 1; /* set L1 breakpoint here */
asm ("L2:");
v = 2; /* set L2 breakpoint here */
return 0;
}
If breakpoints are placed on the lines indicated by the comments,
this is the behavior of GDB built without my patch:
(gdb) continue
Continuing.
Breakpoint 2, L1 () at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
Note that L1 appears as the function instead of main. This is not
what we want to happen. With my patch in place, we see the desired
behavior instead:
(gdb) continue
Continuing.
Breakpoint 2, main (argc=1, argv=0x7fffffffdb88) at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
gdb/ChangeLog:
* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Scan backwards
over all zero-sized symbols.
gdb/testsuite/ChangeLog:
* gdb.base/asmlabel.exp: New test.
* gdb.base/asmlabel.c: New test case.
Joel Brobecker [Mon, 23 Nov 2015 18:02:50 +0000 (10:02 -0800)]
error/internal-error printing local variable during "bt full".
One of our users reported an internal error using the "bt full"
command. In their situation, reproducing involved the following
scenario:
(gdb) frame 1
(gdb) bt full
#0 0xf7783430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf5550aeb in waitpid () at ../sysdeps/unix/syscall-template.S:81
No locals.
[...]
#6 0x0fe83139 in xxxx (arg=...)
[...some locals printed, and then...]
<S17b> =
[...]/dwarf2loc.c:364: internal-error: dwarf_expr_frame_base: Assertion
`framefunc != NULL' failed.
As shown above, the error happens while GDB is trying to print the value
of <S17b>, which is a local string internally generated by the compiler.
For that, it finds that the array lives in memory, and therefore tries
to create a struct value for it via:
Unfortunately for us, TYPE happens to be an array whose bounds
are dynamic. More precisely, the bounds of our arrays are described
in the debugging info as being...
As a result of the above, value_at_lazy indirectly triggers
a resolution of TYPE (via value_from_contents_and_address),
which means a resolution of TYPE's bounds, and as seen in
the DW_AT_location attribute above for our bounds, computing
the bound's location requires the frame (its location expression
uses DW_OP_fbreg).
Unfortunately for us, value_at_lazy does not get passed a frame,
we've lost the relevant frame when we try to resolve the array's
bounds. Instead, resolve_dynamic_range gets calls dwarf2_evaluate_property
with NULL as the frame:
static struct type *
resolve_dynamic_range (struct type *dyn_range_type,
struct property_addr_info *addr_stack)
{
[...]
if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
^^^^
... which then handles this by using the selected frame instead:
In our case, the selected frame happens to be frame #1, which is
a frame where we have a minimal amount of debugging info, and in
particular, no debug info for the function itself. And because of that,
when we try to determine the frame's base...
... framefunc ends up being NULL, which triggers the assert
in that same function:
gdb_assert (framefunc != NULL);
This patches avoids the issue by temporarily setting the selected_frame
before printing the locals of each frames.
This patch also adds a small testcase, which reproduces the same
issue, but with a slightly different outcome:
(gdb) bt full
#0 0x000000000040049a in opaque_routine ()
No symbol table info available.
#1 0x0000000000400532 in main () at wrong_frame_bt_full-main.c:20
my_table_size = 3
my_table = <error reading variable my_table (frame address is not available.)>
With this patch, the output becomes:
(gdb) bt full
[...]
my_table = {0, 1, 2}
gdb/ChangeLog:
* stack.c (print_frame_local_vars): Temporarily set the selected
frame to FRAME while printing the frame's local variables.
gdb/testsuite/ChangeLog:
* gdb.base/wrong_frame_bt_full-main.c: New file.
* gdb.base/wrong_frame_bt_full-opaque.c: New file.
* gdb.base/wrong_frame_bt_full.exp: New file.
The problem happens while GDB is trying to handle the thread termination
event of the thread that hit the breakpoint. It started happening after
the following change was made:
Reset current_thread and make sure 'remove_process' is used
after all associated threads have been removed first.
More precisely:
. GDBserver receives the execution-resume order;
. lynx-low resumes it succesfully, and then relies on lynx_wait_1
to wait for the next event;
. We quickly receive one, which lynx_wait_1 analyzes to be
a "thread exit" event, and therefore does...
case SIGTHREADEXIT:
remove_thread (find_thread_ptid (new_ptid));
lynx_continue (new_ptid);
goto retry;
=> remove_thread causes current_thread to be set to NULL...
(that's the recent change mentioned above)
=> ... which causes problems during lynx_continue, because
it calls lynx_resume, which calls regcache_invalidate,
which unfortunately assumes that CURRENT_THREAD is not NULL:
void
regcache_invalidate (void)
{
/* Only update the threads of the current process. */
SEGV!--> int pid = ptid_get_pid (current_thread->entry.id);
Since the problem at hand is caused by trying to figure out which
inferior to reset the regcache for, and since lynx_resume actually
had that info, this patch fixes the problem by introducing a new
routine called regcache_invalidate_pid, which invalidates the cache
of the given pid; and then modifies lynx_resume use that new routine
rather than relying on regcache_invalidate to invalidate the regcache
of the expected inferior.
gdb/gdbserver/ChangeLog:
* regcache.h (regcache_invalidate_pid): Add declaration.
* regcache.c (regcache_invalidate_pid): New function, extracted
from regcache_invalidate.
(regcache_invalidate): Reimplement using regcache_invalidate_pid.
Add trivial documentation comment.
* lynx-low.c: Use regcache_invalidate_pid instead of
regcache_invalidate.
Joel Brobecker [Mon, 23 Nov 2015 17:53:31 +0000 (09:53 -0800)]
infinite loop stopping at "pop" insn on x64-windows
We noticed the following hang trying to run a program where one
of the subroutines we built without debugging info (opaque_routine):
$ gdb my_program
(gdb) break opaque_routine
(gdb) run
[...hangs...]
The problem comes from the fact that, at the breakpoint's address,
we have the following code:
=> 0x0000000000401994 <+4>: pop %rbp
At some point after hitting the breakpoint and stopping, GDB calls
amd64_windows_frame_decode_epilogue, which then gets stuck in the
following infinite loop:
| /* We don't care about the instruction deallocating the frame:
| if it hasn't been executed, the pc is still in the body,
| if it has been executed, the following epilog decoding will work. */
|
| /* First decode:
| - pop reg [41 58-5f] or [58-5f]. */
|
| while (1)
| {
| /* Read opcode. */
| if (target_read_memory (pc, &op, 1) != 0)
| return -1;
|
| if (op >= 0x40 && op <= 0x4f)
| {
| /* REX prefix. */
| rex = op;
|
| /* Read opcode. */
| if (target_read_memory (pc + 1, &op, 1) != 0)
| return -1;
| }
| else
| rex = 0;
|
| if (op >= 0x58 && op <= 0x5f)
| {
| /* pop reg */
| gdb_byte reg = (op & 0x0f) | ((rex & 1) << 3);
|
| cache->prev_reg_addr[amd64_windows_w2gdb_regnum[reg]] = cur_sp;
| cur_sp += 8;
| }
| else
| break;
|
| /* Allow the user to break this loop. This shouldn't happen as the
| number of consecutive pop should be small. */
| QUIT;
| }
Nothing in that loop updates PC, and therefore, because the instruction
we stopped at is a "pop", we keep looping forever doing the same thing
over and over!
This patch fixes the issue by advancing PC to the beginning of
the next instruction if the current one is a "pop reg" instruction.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_frame_decode_epilogue):
Increment PC in while loop skipping "pop reg" instructions.
Joel Brobecker [Mon, 23 Nov 2015 17:50:55 +0000 (09:50 -0800)]
[ARM] "svc" insn check at irrelevant address in ARM unwind info sniffer
The following issue has been observed on arm-android, trying to step
over the following line of code:
Put_Line (">>> " & Integer'Image (Message (I)));
Below is a copy of the GDB transcript:
(gdb) cont
Breakpoint 1, q.dump (message=...) at q.adb:11
11 Put_Line (">>> " & Integer'Image (Message (I)));
(gdb) next
0x00016000 in system.concat_2.str_concat_2 ()
The expected behavior for the "next" command is to step over
the call to Put_Line and stop at line 12:
(gdb) next
12 I := I + 1;
What happens during the next step is that the code for line 11
above make a call to system.concat_2.str_concat_2 (to implement
the '&' string concatenation operator) before making the call
to Put_Line. While stepping, GDB stops eventually stops at the
first instruction of that function, and fails to detect that
it's a function call from where we were before, and so decides
to stop stepping.
And the reason why it fails to detect that we landed inside a function
call is because it fails to unwind from that function:
(gdb) bt
#0 0x00016000 in system.concat_2.str_concat_2 ()
#1 0x0001bc74 in ?? ()
Debugging GDB, I found that GDB decides to use the ARM unwind info
for that function, which contains the following data:
0x16000 <system__concat_2__str_concat_2>: 0x80acb0b0
Compact model index: 0
0xac pop {r4, r5, r6, r7, r8, r14}
0xb0 finish
0xb0 finish
But, in fact, using that data is wrong, in this case, because
it mentions a pop of 6 registers, and therefore hints at a frame
size of 24 bytes. The problem is that, because we're at the first
instruction of the function, the 6 registers haven't been pushed
to the stack yet. In other words, using the ARM unwind entry above,
GDB is tricked into thinking that the frame size is 24 bytes, and
that the return address (r14) is available on the stack.
One visible manifestation of this issue can been seen by looking
at the value of the stack pointer, and the frame's base address:
(gdb) p /x $sp
$2 = 0xbee427b0
(gdb) info frame
Stack level 0, frame at 0xbee427c8:
^^^^^^^^^^
||||||||||
The frame's base address should be equal to the value of the stack
pointer at entry. And you eventually get the correct frame address,
as well as the correct backtrace if you just single-step one additional
instruction, past the push:
(gdb) x /i $pc
=> 0x16000 <system__concat_2__str_concat_2>:
push {r4, r5, r6, r7, r8, lr}
(gdb) stepi
(gdb) bt
#0 0x00016004 in system.concat_2.str_concat_2 ()
#1 0x00012b6c in q.dump (message=...) at q.adb:11
#2 0x00012c3c in q () at q.adb:19
Digging further, I found that GDB tries to use the ARM unwind info
only when sure that it is relevant, as explained in the following
comment:
/* The ARM exception table does not describe unwind information
for arbitrary PC values, but is guaranteed to be correct only
at call sites. We have to decide here whether we want to use
ARM exception table information for this frame, or fall back [...]
There is one case where it decides that the info is relevant,
described in the following comment:
/* We also assume exception information is valid if we're currently
blocked in a system call. The system library is supposed to
ensure this, so that e.g. pthread cancellation works.
For that, it just parses the instruction at the address it believes
to be the point of call, and matches it against an "svc" instruction.
For instance, for a non-thumb instruction, it is at...
get_frame_pc (this_frame) - 4
... and the code checking looks like the following.
However, the reason why this doesn't work in our case is that
because we are at the first instruction of a function in the innermost
frame. That frame can't possibly be making a call, and therefore
be stuck on a system call.
What the code above ends up doing is checking the instruction
just before the start of our function, which in our case is not
even an actual instruction, but unlucky for us, happens to match
the pattern it is looking for, thus leading GDB to improperly
trust the ARM unwinding data.
gdb/ChangeLog:
* arm-tdep.c (arm_exidx_unwind_sniffer): Do not check for a frame
stuck on a system call if the given frame is the innermost frame.
Joel Brobecker [Mon, 23 Nov 2015 17:44:16 +0000 (09:44 -0800)]
gdb/dwarf2read: Minimal handling of non-constant struct sizes.
Using the gdb.ada/var_rec_arr.exp test, where the program declares
an array of variant records...
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
... and then a variable A1 of type Array_Type, the following command
ocassionally trigger an internal error trying to allocate more memory
than we have left:
(gdb) ptype a1(1)
[...]/utils.c:1089: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
[...]
What happens is that recent versions of GNAT are able to generate
DWARF expressions for type Record_Type, and therefore the record's
DW_AT_byte_size is not a constant, which unfortunately breaks
an assumption made by dwarf2read.c:read_structure_type when it does:
As a result of this, when ada_evaluate_subexp tries to create
a value_zero for a1(1) while processing the OP_FUNCALL operator
as part of evaluating the subscripting operation in no-side-effect
mode, we try to allocate a value with a bogus size, potentially
triggering the out-of-memory internal error.
This patch avoids this issue by setting the length to zero in
this case. Until we decide to start supporting dynamic type
lengths in GDB's type struct, and it's not clear yet that
this is worth the effort (see added comment), that's probably
the best we can do.
gdb/ChangeLog:
* dwarf2read.c (read_structure_type): Set the type's length
to zero if it has a DW_AT_byte_size attribute which is not
a constant.
Mike Frysinger [Sat, 20 Jun 2015 09:36:26 +0000 (15:21 +0545)]
sim: common: add PRI printf defines
Keeping track of the right printf formats for the various types can be
a pretty big hassle, especially in common code which has to support a
variety of bitsizes. Take a page from the existing standards and add
a set of PRI macros which hide the details in a common header.
Mike Frysinger [Sun, 22 Nov 2015 05:12:59 +0000 (21:12 -0800)]
sim: avr: switch to common sim-reg
This is not entirely useful as avr doesn't (yet) store its register
state in the cpu state, but it does allow for switching to the common
code for these functions.
Don Breazeal [Fri, 20 Nov 2015 17:45:44 +0000 (09:45 -0800)]
Fix '-data-read-memory-bytes' typo/assertion
This patch fixes a typo in target.c:read_memory_robust, where
it calls read_whatever_is_readable with the function arguments
in the wrong order. Depending on the address being read, it
can cause an xmalloc with a huge size, resulting in an assertion
failure, or just read something other than what was requested.
The problem only arises when GDB is handling an MI
"-data-read-memory-bytes" request and the initial target_read returns
an error status. Note that read_memory_robust is only called from
the MI code.
gdb/ChangeLog:
* gdb/target.c (read_memory_robust): Call
read_whatever_is_readable with arguments in the correct order.
MIPS/GAS/testsuite: Tighten negative-match NaN tests
Fix a test quality regression introduced with commit 351cdf24 [[MIPS]
Implement O32 FPXX, FP64 and FP64A ABI extensions] where MIPS ABI flags
match patterns have been added to negative-match tests covering ELF file
header flags. Negative-match tests succeed whenever there is a failure
in matching output produced and consequently the likelihood of a false
success increases when patterns to match irrelevant output are added.
Therefore remove the irrelevant paterns so that the tests complete as
soon as the line concerned has been seen.
MIPS/LD: Fix little-endian `mti' and `img' ELF emulations
Make the little-endian emulation the default for the `mips*el-mti-elf*'
and `mips*el-img-elf*' targets, fixing the issue of LD rejecting, in its
default configuration, object files produced by GAS also in its default
configuration.
Matthew Wahab [Fri, 20 Nov 2015 16:09:34 +0000 (16:09 +0000)]
[AArch64] Add support for ARMv8.1 Virtulization Host Extensions.
The ARMv8.1 architecture includes the Virtualization Host Extensions
which add a number of system registers. This patch adds support for
these system registers, making them available when -march=armv8.1-a is
selected.
include/opcode/
2015-11-20 Matthew Wahab <matthew.wahab@arm.com>
Jose E. Marchesi [Fri, 20 Nov 2015 10:36:07 +0000 (11:36 +0100)]
callfuncs.exp: avoid spurious register differences in sparc64 targets.
The Linux kernel disables the FPU upon returning to userland. This
introduces spurious failures in the register preservation tests in
callfuncs.exp, since the pstate.PEF bit gets cleared after system
calls.
This patch filters out the pstate register in sparc64-*-linux-gnu
targets, so the relevant tests are no longer fooled and pass.
gdb/testsuite/ChangeLog:
2015-11-20 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/callfuncs.exp (fetch_all_registers): Filter out the
pstate register when comparing registers values in
sparc64-*-linux-gnu targets to avoid spurious differences.
gdb/testsuite/
* gdb.base/nested-subp1.exp: Pass executable, not executable name,
as type argument to gdb_compile.
* gdb.base/nested-subp2.exp: Likewise.
* gdb.base/nested-subp3.exp: Likewise.
The target_process_qsupported method is called for each qSupported
feature that the common code does not recognize. The only current
implementation, for x86 Linux (x86_linux_process_qsupported), assumes
that it either is called with the "xmlRegisters=i386" feature, or that
it is isn't called at all, indicating the connected GDB predates x86
XML descriptions.
That's a bad assumption however. If GDB sends in a new/unknown (to
core gdbserver) feature after "xmlRegisters=i386", say, something like
qSupported:xmlRegisters=i386;UnknownFeature+, then when
target_process_qsupported is called for "UnknownFeature+",
x86_linux_process_qsupported clears the 'use_xml' global and calls
x86_linux_update_xmltarget, and gdbserver ends up _not_ reporting a
XML description...
This commit changes the target_process_qsupported API to instead pass
down a vector of unprocessed qSupported features in one go.
(There's an early call to target_process_qsupported(NULL) that
indicates "starting qSupported processing". There's no matching call
to mark the end of processing, though. I first fixed this by passing
(char *)-1 to indicate that, and adjusted the x86 backend to only
clear 'use_xml' when qSupported processing starts, and then only call
x86_linux_update_xmltarget() when (char *)-1 was passed. However, I
wasn't that happy with the hack and came up this alternative version.)
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_process_qsupported): Change prototype.
Adjust.
* linux-low.h (struct linux_target_ops) <process_qsupported>:
Change prototype.
* linux-x86-low.c (x86_linux_process_qsupported): Change prototype
and adjust to loop over all features.
* server.c (handle_query) <qSupported>: Adjust to call
target_process_qsupported once, passing it a vector of unprocessed
features.
* target.h (struct target_ops) <process_qsupported>: Change
prototype.
(target_process_qsupported): Adjust.
Pedro Alves [Thu, 19 Nov 2015 18:31:49 +0000 (18:31 +0000)]
gdb: Workaround bad gdbserver qSupported:xmlRegisters=i386;UnknwnFeat+ handling
gdbserver's target_process_qsupported is called for each feature that
the gdbserver common code does not recognize. The only current
implementation, for x86 Linux, does this:
static void
x86_linux_process_qsupported (const char *query)
{
/* Return if gdb doesn't support XML. If gdb sends "xmlRegisters="
with "i386" in qSupported query, it supports x86 XML target
descriptions. */
use_xml = 0;
if (query != NULL && startswith (query, "xmlRegisters="))
{
char *copy = xstrdup (query + 13);
char *p;
for (p = strtok (copy, ","); p != NULL; p = strtok (NULL, ","))
{
if (strcmp (p, "i386") == 0)
{
use_xml = 1;
break;
}
}
free (copy);
}
x86_linux_update_xmltarget ();
}
Notice that this clears use_xml and calls x86_linux_update_xmltarget
each time target_process_qsupported is called. So if gdb sends in any
unknown feature after "xmlRegisters=i386", like e.g.,
"xmlRegisters=i386;UnknownFeature+" gdbserver ends up not reporting a
XML description...
Work around this by having GDB send the "xmlRegisters=" feature last.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* remote.c (remote_query_supported): Send the "xmlRegisters="
feature last.