In a test I was writting, I needed a procedure that would connect to
the target, and do "load", or equivalent.
Years ago, boards would override gdb_load to implement that. Then
gdb_reload was added, and gdb_load was relaxed to allow boards avoid
the spawing and connecting to the target. This sped up gdbserver
testing. See
https://www.sourceware.org/ml/gdb-patches/2007-02/msg00318.html.
To actually spawn the target and load the executable on the target
side, gdb_reload was born:
# gdb_reload -- load a file into the target. Called before "running",
# either the first time or after already starting the program once,
# for remote targets. Most files that override gdb_load should now
# override this instead.
proc gdb_reload { } {
# For the benefit of existing configurations, default to gdb_load.
# Specifying no file defaults to the executable currently being
# debugged.
return [gdb_load ""]
}
Note the comment about specifying no file. Indeed looking at
config/sid.exp, or config/monitor.exp, we see examples of that.
However, the default gdb_load itself doesn't handle the case of no
file specified. When passed no file, it just calls gdb_file_cmd with
no file either, which ends up invocing the "file" command with no
argument, which means unloading the file and its symbols... That
means calling gdb_reload when testing against native targets is
broken. We don't see that today because the only call to gdb_reload
that exists today is guarded by target_info exists
gdb,do_reload_on_run.
The native-extended-gdbserver.exp board is likewise broken here. When
[gdb_load ""] is called, the board sets the remote exec-file to "" ...
Tested on x86_64 Fedora 17, native, remote gdbserver and
extended-remote gdbserver.
testsuite/
2014-05-01 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_load): Extend comment. Skip calling
gdb_file_cmd if no file is specified.
* boards/native-extended-gdbserver.exp (gdb_load): Use the
last_loaded_file to set the remote exec-file.
of address.
(mmo_write_chunk): When handling data remainder, assert that
previous remaining data is flushed.
(mmo_write_loc_chunk): Only look for trailing and leading zeros
when dealing with an aligned VMA and for aligned lengths. Don't skip
the last 32-bit-word of zeros.
(mmo_write_loc_chunk): Emit an error if the VMA is not aligned.
(mmo_scan) <case LOP_QUOTE>: Move re-alignment of vma before
emitting data, not after updating it.
<case LOP_LOC>: Call mmo_decide_section with aligned vma.
When connecting to a remote system, we use the compare-sections
command to verify that the box is running the code that we think it is
running. Since the system is up and running and *NOT* 'freshly
downloaded without yet executing anything', read-write sections, of
course, differ from what they were in the executable file.
Comparing read-write sections takes time and more importantly the
MIS-MATCHED output is confusing to some users.
The compare-sections command compares all loadable sections including
read-write sections. This patch gives the user the option to compare
just the loadable read-only sections.
gdb/
2014-05-01 David Taylor <dtaylor@emc.com>
* remote.c (compare_sections_command): Add -r option to compare
all loadable read-only sections.
gdb/doc/
2014-05-01 David Taylor <dtaylor@emc.com>
* gdb.texinfo (compare-sections): Document the new -r (read-only)
option.
0x9b (fwait) is both an instruction and an opcode prefix. When 0x9b is
treated as an instruction, we need to handle any prefixes before it.
This patch handles it properly.
gas/testsuite/
PR binutils/16891
* gas/i386/opcode.s: Add test for fwait with prefix.
* gas/i386/opcode-intel.d: Updated.
* gas/i386/opcode-suffix.d: Likewise.
* gas/i386/opcode.d: Likewise.
opcodes/
PR binutils/16891
* i386-dis.c (print_insn): Handle prefixes before fwait.
This adds a variant of local-remote-host-notty.exp that forces
pseudo-tty allocation, so that readline/editing is enabled.
$ ssh localhost gdb -q
(gdb) show editing
Editing of command lines as they are typed is off.
(gdb)
vs:
$ ssh -t localhost gdb -q
(gdb) show editing
Editing of command lines as they are typed is on.
We now get, e.g.:
Running ../../../src/gdb/testsuite/gdb.base/filesym.exp ...
PASS: gdb.base/filesym.exp: complete on "filesy"
PASS: gdb.base/filesym.exp: completion list for "filesym"
PASS: gdb.base/filesym.exp: set breakpoint at filesym
gdb/testsuite/
2014-05-01 Pedro Alves <palves@redhat.com>
* boards/local-remote-host.exp: New file.
When testing with this board, stdin is not a tty, and so
readline/editing is disabled:
$ ssh localhost gdb -q
(gdb) show editing
Editing of command lines as they are typed is off.
(gdb)
Rename the file, to make room for a version of this board that forces a pseudo-tty.
gdb/testsuite/
2014-05-01 Pedro Alves <palves@redhat.com>
* boards/local-remote-host.exp: Rename to ...
* boards/local-remote-host-notty.exp: ... this.
thought that an uncompressed .debug_str section was compressed.
* compress.c (bfd_is_section_compressed): When checking the
.debug_str section, also check the fifth byte in the section is
not part of a string.
* binutils-all/debug_str.s: New test.
* binutils-all/debug_str.d: New test control file.
* binutils-all/compress.exp: Run debug_str test.
This is all we should need to be able to run the eh_frame parts of
bfd_elf_discard_info before bfd_elf_size_dynamic_sections
* elf-eh-frame.c (struct cie.personality): Replace val with sym.
(find_merged_cie): Identify personality functions by (bfd_id,index)
pair when a local sym is used.
Outgoing section for relocations was computed by setting a shared
pointer to which section should be used. For TLS this was overriden to
use .rela.got since they use GOT entries but since the pointer is per
section that whole section was relocated to .rela.got, even non-TLS
relocations.
* elf32-or1k.c: Fix a bug where non-TLS relocations would be forced
into .rela.got if it contained TLS relocations as well.
... and others. The recent patch that fixed several "set remote
foo-packet on/off" commands introduced a regression, observable when
connecting GDB to QEMU. For instance:
(gdb) set debug remote 1
(gdb) tar rem :4444
Remote debugging using :4444
Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
Packet received: PacketSize=1000;qXfer:features:read+
Packet qSupported (supported-packets) is supported
Sending packet: $Hgp0.0#ad...Ack
Packet received: OK
Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
Packet received: [...]
Sending packet: $qXfer:features:read:arm-core.xml:0,ffb#08...Ack
Packet received: [...]
!!! -> Sending packet: $QNonStop:0#8c...Ack
Packet received:
Remote refused setting all-stop mode with:
The "QNonStop" feature is associated with the PACKET_QNonStop packet,
with a default of PACKET_DISABLE, so GDB should not be sending the
packet at all.
The patch that introduced the regression decoupled packet_config's
'detect' and 'support' fields, making the former (an auto_boolean)
purely the associated "set remote foo-packet" command's variable. In
the example above, the packet config's 'supported' field does end up
correctly set to PACKET_DISABLE. However, nothing is presently
initializing packet configs that don't actually have a command
associated. Those configs's 'detect' field then ends up set to
AUTO_BOOLEAN_TRUE, simply because that happens to be 0. This forces
GDB to assume the packet is supported, irrespective of what the target
claims it supports, just like if the user had done "set remote
foo-packet on" (this being the associated command, if there was one).
Ideally, all packet configs would have a command associated. While
that isn't true, make sure all packet configs are initialized, even if
no command is associated, and add an assertion that prevents adding
more packets/features without an associated command.
Tested on x86_64 Fedora 17, against pristine gdbserver, and against a
gdbserver with the QNonStop packet/feature disabled with a local hack.
gdb/
2014-04-29 Pedro Alves <palves@redhat.com>
* remote.c (struct packet_config) <detect>: Extend comment.
(add_packet_config_cmd): Don't set the config's detect or support
fields here.
(init_all_packet_configs): Also initialize the config's 'detect'
field.
(reset_all_packet_configs_support): New function.
(remote_open_1): Call reset_all_packet_configs_support instead of
init_all_packet_configs.
(_initialize_remote): Initialize all packet configs. Assert that
all packets have an associated command, except a few known
outliers.
This add a testcases that verifies correct handling of dynamicity
for lower bounds of arrays.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_arrayidx: New testcase.
Currently, read_subrange_type handles dynamicity only in the case of
the upper bound, and assumes that the lower bound is always static.
That's rooted in the fact that dynamicity was added to support C99
variable-length arrays, where the lower bound is always zero, and
therefore never dynamic. But the lower bound can, in fact, be dynamic
in other languages such as Ada.
Consider for instance the following declaration in Ada...
type Array_Type is array (L .. U) of Natural;
... where L and U are parameters of the function where the declaration
above was made, and whose value are 5 and 10. Currently, the debugger
is able to print the value of the upper bound correctly, but not the
lower bound:
(gdb) ptype array_type
type = array (1 .. 10) of natural
After this patch, the debugger now prints:
(gdb) ptype array_type
type = array (5 .. 10) of natural
gdb/ChangeLog:
* dwarf2read.c (read_subrange_type): Handle dynamic
DW_AT_lower_bound attributes.
Consider the following declaration in Ada...
type Array_Type is array (L .. U) of Natural;
... where L and U are parameters of the function where the declaration
above was made. At the moment, GDB relies on descriptive types in order
to properly decode the array bounds. For instance, if L was 5, and U
was 10, we would see the following:
(gdb) ptype array_type
type = array (5 .. 10) of natural
(gdb) maintenance set ada ignore-descriptive-types
(gdb) ptype array_type
type = array (1 .. 28544912) of natural
This patch enhances ada_discrete_type_{high,low}_bound to resolve
any dynamicity. This is sufficient to fix the case of the upper bound.
For the lower bound, the dwarf2read module does not handle dynamic
lower bounds yet, but once it does, the lower bound should be correctly
handled as well [1].
gdb/ChangeLog:
* ada-lang.c (ada_discrete_type_high_bound): Resolve the type's
dynamic bounds before computing its upper bound.
(ada_discrete_type_low_bound): Same as above with the lower bound.
[1]: The reason why we do not enhance dwarf2read to handle dynamic
lower bounds ahead of this patch is because it unveils some latent
issues such as this one.
This change breaks down the resolve_dynamic_bounds function which
works only on arrays and its index range types into two functions,
one that resolves range types, and one that resolves arrays (using
the new routine to resolve the array's index range type). The
is_dynamic_type and resolve_dynamic_type function are then re-organized
to handle range types as well.
One small change worth mentioning is the fact that, now that range
types are resolved on their own (rather than in the limited context
of array index types), the resolved range types are created from
a copy of the dynamic range type, rather than from scratch (first
parameter of create_range_type). This allows us to preserve as many
original properties in the resolved type as possible (Eg. the type's
name).
This is preparation work that will help better support dynamic range
types for languages that allow the declaration of such types (Eg. Ada).
gdb/ChangeLog:
* dwarf2read.c (is_dynamic_type): Return true for dynamic
range types. Adjust the array handling implementation to
take advantage of this change.
(resolve_dynamic_range): New function, mostly extracted from
resolve_dynamic_bounds.
(resolve_dynamic_array): New function, mostly extracted from
resolve_dynamic_bounds.
(resolve_dynamic_bounds): Delete.
(resolve_dynamic_type): Reimplement. Add handling of
TYPE_CODE_RANGE types.
ada-varobj.c::ada_varobj_describe_simple_array_child only ever gets
called after all GNAT encodings have been applied to (parent_value,
parent_type). So there is no point in redoing it partially by
checking for parallel XA types again.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_describe_simple_array_child): Remove
handling of parallel ___XA types.
In ada-lang.c::ada_evaluate_subexp, case OP_VAR_VALUE, when noside
is EVAL_AVOID_SIDE_EFFECTS, the first thing we do is set type as
follow:
type = static_unwrap_type (SYMBOL_TYPE (exp->elts[pc + 2].symbol));
Later on in the same block, we make the same call:
return value_zero
(to_static_fixed_type
(static_unwrap_type (SYMBOL_TYPE (exp->elts[pc + 2].symbol))),
not_lval);
This patch removes the second call, since it should result in the same
type being returned, so no point in making that call again.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <OP_VAR_VALUE>: Remove
unnecessary second call to static_unwrap_type.
The problem was that references to weak function symbols were being
incorrectly biased by definition's offset.
PR gas/16858
* config/tc-i386.c (md_apply_fix): Do not adjust value of
pc-relative fixes against weak symbols.
The makefile rule i386-avx512.c is to generate i386-avx512.c, but it
is written to i386-avx.c by mistake. This patch is to fix this typo.
gdb/gdbserver:
2014-04-28 Yao Qi <yao@codesourcery.com>
* Makefile.in (i386-avx512.c): Fix the typo of generated file
name.
When GDB debug DUMMY_FRAME, SIGTRAMP_FRAME and ARCH_FRAME, even if
"set disassemble-next-line on", it will not output the asm code:
(gdb) set disassemble-next-line on
(gdb) si
<signal handler called>
(gdb)
<signal handler called>
(gdb)
<signal handler called>
So make this patch make they can work together, it will become:
(gdb) si
<signal handler called>
=> 0xffffffff816bfb09 <int_with_check+0>: 65 48 8b 0c 25 c8 c7 00 00 mov %gs:0xc7c8,%rcx
(gdb)
<signal handler called>
=> 0xffffffff816bfb12 <int_with_check+9>: 48 81 e9 d8 1f 00 00 sub $0x1fd8,%rcx
(gdb)
<signal handler called>
=> 0xffffffff816bfb19 <int_with_check+16>: 8b 51 10 mov 0x10(%rcx),%edx
2014-04-27 Hui Zhu <hui@codesourcery.com>
* stack.c (print_frame_info): Call do_gdb_disassembly with
DUMMY_FRAME, SIGTRAMP_FRAME and ARCH_FRAME.
In Dwarf::assemble in dwz.exp, 10 is hard-coded in it,
subprogram {
{name main}
{low_pc main addr}
{high_pc "main + 10" addr}
}
however, the length of main function varies on architectures. The
hard-coded 10 here causes dwz.exp fails on some targets, such as
nios2.
This patch is to add some code to compute the length of function main,
which is similar to what we are doing in entry-values.exp.
gdb/testsuite:
2014-04-26 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Compile main.c to object. Restart GDB
and compute the length of function main. Save it in
$main_length.
(Dwarf::assemble): Use $main_length instead of hard-coded 10.
(top-level): Use gdb_compile to compile objects into
executable and restart GDB. Remove invocation to
prepare_for_testing.
2014-04-25 Pedro Alves <palves@redhat.com>
PR server/16255
* linux-low.c (linux_attach_fail_reason_string): New function.
(linux_attach_lwp): Delete.
(linux_attach_lwp_1): Rename to ...
(linux_attach_lwp): ... this. Take a ptid instead of a pid as
argument. Remove "initial" parameter. Return int instead of
void. Don't error or warn here.
(linux_attach): Adjust to call linux_attach_lwp. Call error on
failure to attach to the tgid. Call warning when failing to
attach to an lwp.
* linux-low.h (linux_attach_lwp): Take a ptid instead of a pid as
argument. Remove "initial" parameter. Return int instead of
void. Don't error or warn here.
(linux_attach_fail_reason_string): New declaration.
* thread-db.c (attach_thread): Adjust to linux_attach_lwp's
interface change. Use linux_attach_fail_reason_string.
On Linux, we need to explicitly ptrace attach to all lwps of a
process. Because GDB might not be connected yet when an attach is
requested, and thus it may not be possible to activate thread_db, as
that requires access to symbols (IOW, gdbserver --attach), a while ago
we make linux_attach loop over the lwps as listed by /proc/PID/task to
find the lwps to attach to.
linux_attach_lwp_1 has:
...
if (initial)
/* If lwp is the tgid, we handle adding existing threads later.
Otherwise we just add lwp without bothering about any other
threads. */
ptid = ptid_build (lwpid, lwpid, 0);
else
{
/* Note that extracting the pid from the current inferior is
safe, since we're always called in the context of the same
process as this new thread. */
int pid = pid_of (current_inferior);
ptid = ptid_build (pid, lwpid, 0);
}
That "safe" comment referred to linux_attach_lwp being called by
thread-db.c. But this was clearly missed when a new call to
linux_attach_lwp_1 was added to linux_attach. As a result,
current_inferior will be set to some random process, and non-initial
lwps of the second inferior get assigned the pid of the wrong
inferior. E.g., in the case of attaching to two inferiors, for the
second inferior (and so on), non-initial lwps of the second inferior
get assigned the pid of the first inferior. This doesn't trigger on
the first inferior, when current_inferior is NULL, add_thread switches
the current inferior to the newly added thread.
Rather than making linux_attach switch current_inferior temporarily
(thus avoiding further reliance on global state), or making
linux_attach_lwp_1 get the tgid from /proc, which add extra syscalls,
and will be wrong in case of the user having originally attached
directly to a non-tgid lwp, and then that lwp spawning new clones (the
ptid.pid field of further new clones should be the same as the
original lwp's pid, which is not the tgid), we note that callers of
linux_attach_lwp/linux_attach_lwp_1 always have the right pid handy
already, so they can pass it down along with the lwpid.
The only other reason for the "initial" parameter is to error out
instead of warn in case of attach failure, when we're first attaching
to a process. There are only three callers of
linux_attach_lwp/linux_attach_lwp_1, and each wants to print a
different warn/error string, so we can just move the error/warn out of
linux_attach_lwp_1 to the callers, thus getting rid of the "initial"
parameter.
There really nothing gdbserver-specific about attaching to two
threaded processes, so this adds a new test under gdb.multi/. The
test passes cleanly against the native GNU/Linux target, but
fails/triggers the bug against GDBserver (before the patch), with the
native-extended-remote board (as plain remote doesn't support
multi-process).
Tested on x86_64 Fedora 17, with the native-extended-gdbserver board.
gdb/gdbserver/
2014-04-25 Pedro Alves <palves@redhat.com>
PR server/16255
* linux-low.c (linux_attach_fail_reason_string): New function.
(linux_attach_lwp): Delete.
(linux_attach_lwp_1): Rename to ...
(linux_attach_lwp): ... this. Take a ptid instead of a pid as
argument. Remove "initial" parameter. Return int instead of
void. Don't error or warn here.
(linux_attach): Adjust to call linux_attach_lwp. Call error on
failure to attach to the tgid. Call warning when failing to
attach to an lwp.
* linux-low.h (linux_attach_lwp): Take a ptid instead of a pid as
argument. Remove "initial" parameter. Return int instead of
void. Don't error or warn here.
(linux_attach_fail_reason_string): New declaration.
* thread-db.c (attach_thread): Adjust to linux_attach_lwp's
interface change. Use linux_attach_fail_reason_string.
gdb/
2014-04-25 Pedro Alves <palves@redhat.com>
PR server/16255
* common/linux-ptrace.c (linux_ptrace_attach_warnings): Rename to ...
(linux_ptrace_attach_fail_reason): ... this. Remove "warning: "
and newline from built string.
* common/linux-ptrace.h (linux_ptrace_attach_warnings): Rename to ...
(linux_ptrace_attach_fail_reason): ... this.
* linux-nat.c (linux_nat_attach): Adjust to use
linux_ptrace_attach_fail_reason.
gdb/testsuite/
2014-04-25 Simon Marchi <simon.marchi@ericsson.com>
Pedro Alves <palves@redhat.com>
PR server/16255
* gdb.multi/multi-attach.c: New file.
* gdb.multi/multi-attach.exp: New file.
For several RSP packets, there's a corresponding "set remote
foo-packet on/off/auto" command that one can use do bypass
auto-detection of support for the packet or feature. However, I
noticed that setting several of these commands to 'on' or 'off'
doesn't actually have any effect. These are, at least:
set remote breakpoint-commands-packet
set remote conditional-breakpoints-packet
set remote fast-tracepoints-packet
set remote static-tracepoints-packet
set remote install-in-trace-packet
These are commands that control a remote protocol feature that doesn't
have a corresponding regular packet, and because of that we cache the
knowledge of the remote side support as returned by the qSupported
packet in the remote_state object.
E.g., in the case of the 'set remote breakpoint-commands-packet'
command, whether the feature is supported is recorded in the
'breakpoint_commands' field of the remote_state object.
Whether to bypass packet support auto-detection or not is controlled
by the 'detect' field of the corresponding packet's packet_config
structure. That field is the variable associated directly with the
"set remote foo-packet" command. Actual remote stub support for the
packet (or feature) is recorded in the 'support' field of the same
structure.
However, when the user toggles the command, the 'support' field is
also correspondingly updated to PACKET_ENABLE/DISABLE/SUPPORT_UNKNOWN,
discarding the knowledge of whether the target actually supports the
feature. If one toggles back to 'auto', it's no big issue for real
packets, as they'll just end up re-probed the next time they might be
necessary. But features whose support is only reported through
qSupported don't get their corresponding (manually added/maintained)
fields in remote_state objected updated. As we lost the actual status
of the target support for the feature, GDB would need to probe the
qSupported features again, which GDB doesn't do.
But we can avoid that extra traffic, and clean things up, IMO.
Instead of going in that direction, this patch completely decouples
struct packet_config's 'detect' and 'support' fields. E.g., when the
user does "set remote foo-packet off", instead of setting the packet
config's 'support' field to PACKET_DISABLE, the 'support' field is not
touched at all anymore. That is, we end up respecting this simple
table:
| packet_config->detect | packet_config->support | should use packet/feature? |
|-----------------------+------------------------+----------------------------|
| auto | PACKET_ENABLE | PACKET_ENABLE |
| auto | PACKET_DISABLE | PACKET_DISABLE |
| auto | PACKET_UNKNOWN | PACKET_UNKNOWN |
| yes | don't care | PACKET_ENABLE |
| no | don't care | PACKET_DISABLE |
This is implemented by the new packet_support function. With that, we
need to update this pattern throughout:
if (remote_protocol_packets[PACKET_foo].support == PACKET_DISABLE)
to do this instead:
if (packet_support (PACKET_qAttached) == PACKET_DISABLE)
where as mentioned, the packet_support function takes struct
packet_config's 'detect' field into account, like in the table above.
As when the packet is force-disabled or force-enabled, the 'support'
field is just ignored, if the command is set back to auto, we'll
resume respecting whatever the target said it supports. IOW, the end
result is that the 'support' field always represents whether the
target actually supports the packet or not.
After all that, the manually maintained breakpoint_commands and
equivalent fields of struct remote_state can then be eliminated, with
references replaced by checking the result of calling the
packet_support function on the corresponding packet or feature. This
required adding new PACKET_foo enum values for several features that
didn't have it yet. (The patch does not add corresponding "set remote
foo-packet" style commands though, focusing only on bug fixing and
laying the groundwork).
Tested on x86_64 Fedora 17, native GDBserver. The new tests all fail
without this patch.
gdb/
2014-04-25 Pedro Alves <palves@redhat.com>
* remote.c (struct remote_state): Remove multi_process_aware,
non_stop_aware, cond_tracepoints, cond_breakpoints,
breakpoint_commands, fast_tracepoints, static_tracepoints,
install_in_trace, disconnected_tracing,
enable_disable_tracepoints, string_tracing, and
augmented_libraries_svr4_read fields.
(remote_multi_process_p): Move further below in the file.
(struct packet_config): Add comments.
(update_packet_config): Delete function.
(show_packet_config_cmd): Use packet_config_support.
(add_packet_config_cmd): Use NULL as set callback.
(packet_ok): "set remote foo-packet"-style commands no longer
change config->supported -- adjust.
(PACKET_ConditionalTracepoints, PACKET_ConditionalBreakpoints)
(PACKET_BreakpointCommands, PACKET_FastTracepoints)
(PACKET_StaticTracepoints, PACKET_InstallInTrace): Add comments.
(PACKET_QNonStop, PACKET_multiprocess_feature)
(PACKET_EnableDisableTracepoints_feature, PACKET_tracenz_feature)
(PACKET_DisconnectedTracing_feature)
(PACKET_augmented_libraries_svr4_read_feature): New enum values.
(set_remote_protocol_packet_cmd): Delete function.
(packet_config_support, packet_support): New functions.
(set_remote_protocol_Z_packet_cmd): Don't call
update_packet_config.
(remote_query_attached, remote_pass_signals)
(remote_program_signals, remote_threads_info)
(remote_threads_extra_info, remote_start_remote): Use
packet_support.
(remote_start_remote): Use packet_config_support and
packet_support.
(init_all_packet_configs): Set all packets to unknown support,
instead of calling update_packet_config.
(remote_check_symbols): Use packet_support.
(remote_supported_packet): Unconditionally set the packet config's
support status.
(remote_multi_process_feature, remote_non_stop_feature)
(remote_cond_tracepoint_feature, remote_cond_breakpoint_feature)
(remote_breakpoint_commands_feature)
(remote_fast_tracepoint_feature, remote_static_tracepoint_feature)
(remote_install_in_trace_feature)
(remote_disconnected_tracing_feature)
(remote_enable_disable_tracepoint_feature)
(remote_string_tracing_feature)
(remote_augmented_libraries_svr4_read_feature): Delete functions.
(remote_protocol_features): Adjust to use remote_supported_packet
for "augmented-libraries-svr4-read", "multiprocess", "QNonStop",
"ConditionalTracepoints", "ConditionalBreakpoints",
"BreakpointCommands", "FastTracepoints", "StaticTracepoints",
"InstallInTrace", "DisconnectedTracing", "DisconnectedTracing",
"EnableDisableTracepoints", and "tracenz".
(remote_query_supported): Use packet_support.
(remote_open_1): Adjust.
(extended_remote_attach_1): Use packet_support. Switch on the
result of packet_ok instead of checking whether the packet ended
up disabled.
(remote_vcont_resume): Use packet_support.
(remote_resume, remote_stop_ns, fetch_register_using_p)
(remote_prepare_to_store, store_register_using_P)
(check_binary_download, remote_write_bytes): Use packet_support.
(remote_vkill): Use packet_support. Switch on the result of
packet_ok instead of checking whether the packet ended up
disabled.
(extended_remote_supports_disable_randomization): Use
packet_support.
(extended_remote_run): Switch on the result of packet_ok instead
of checking whether the packet ended up disabled.
(remote_insert_breakpoint, remote_remove_breakpoint)
(remote_insert_watchpoint, remote_remove_watchpoint)
(remote_insert_hw_breakpoint, remote_remove_hw_breakpoint): Use
packet_support.
(remote_search_memory): Use packet_config_support.
(remote_get_thread_local_address, remote_get_tib_address)
(remote_hostio_send_command, remote_can_execute_reverse): Use
packet_support.
(remote_supports_cond_tracepoints)
(remote_supports_cond_breakpoints)
(remote_supports_fast_tracepoints)
(remote_supports_static_tracepoints)
(remote_supports_install_in_trace)
(remote_supports_enable_disable_tracepoint)
(remote_supports_string_tracing)
(remote_can_run_breakpoint_commands): Rewrite, checking whether
the packet config says the feature is enabled or disabled.
(remote_download_tracepoint, remote_trace_set_readonly_regions)
(remote_get_trace_status): Use packet_support.
(remote_set_disconnected_tracing): Adjust to check whether the
feature is enabled with packet_support.
(remote_set_trace_buffer_size, remote_use_agent)
(remote_can_use_agent, remote_supports_btrace): Use
packet_support.
(remote_enable_btrace, remote_disable_btrace, remote_read_btrace):
Use packet_config_support.
(remote_augmented_libraries_svr4_read): Rewrite, checking whether
the packet config says the feature is enabled or disabled.
(set_range_stepping): Use packet_support.
gdb/testsuite/
2014-04-25 Pedro Alves <palves@redhat.com>
* gdb.base/cond-eval-mode.exp (warning): Move trailing \r\n to
user.
(top level): Test that "set remote conditional-breakpoints-packet
off" works as intended.
* gdb.base/dprintf.exp: Test that "set remote
breakpoint-commands-packet off" works as intended.
* gdb.trace/change-loc.exp (tracepoint_install_in_trace_disabled):
New function.
(top level): Call it.
* gdb.trace/ftrace.exp (test_fast_tracepoints): Test that "set
remote fast-tracepoints-packet off" works as intended.
* gdb.trace/qtro.exp (gdb_is_target_remote): Moved ...
* lib/gdb.exp (gdb_is_target_remote): ... here.
versions of gcc complain about part of a conditional expression always
evaluating to false because of the size of the operands involved, even when
the entire expression is already known to be false.
* peXXigen.c (_bfd_XXi_swap_sym_out): Another fix for building on
a 342-bit host. This time for older versions of gcc.
gdb/testsuite/
* gdb.base/catch-syscall.c: Make unreferenced statics non-static to
ensure clang would not discard them.
* gdb.base/gdbvars.c: Ditto.
* gdb.base/memattr.c: Ditto.
* gdb.base/whatis.c: Ditto.
* gdb.python/py-prettyprint.c: Ditto.
* gdb.trace/actions.c: Ditto.
* gdb.cp/ptype-cv-cp.cc: Mark unused global const int as used to
ensure clang would not discard it.
gdb/testsuite/
* gdb.stabs/gdb11479.c (tag_dummy_enum): introduce a variable to cause
clang to emit the full definition of type required by the test
* gdb.stabs/gdb11479.exp (do_test): correct a typo in a test message
gdb/testsuite/
* gdb.cp/pr10728-x.cc: Return by value instead of pointer to coax
Clang into emitting the definition of the type.
* gdb.cp/pr10728-x.h: Ditto.
* gdb.cp/pr10728-y.cc: Ditto.
gdb/testsuite/
* gdb.base/label.exp: XFAIL label related tests under Clang.
* gdb.cp/cplabel.exp: Ditto.
* gdb.linespec/ls-errs.exp: Refactor tests to execute directly
and XFAIL under Clang those using labels.
I happen to see that 'double_label' isn't used in dwz.exp dwarf assembler.
Similarly, partial_label and double_label aren't used in dwzbuildid.exp.
This patch is to remove them.
gdb/testsuite:
2014-04-25 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp (Dwarf::assemble): Remove unused
double_label.
* gdb.dwarf2/dwzbuildid.exp (Dwarf::assemble): Remove
partial_label and double_label.
