The message displayed by gdb is different when the inferior exits with
zero and non-zero values, this fix takes that into account.
gdb/testsuite/ChangeLog:
2014-05-13 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_expect_stop): Expect message for
inferiors that exit with non-zero exit code.
This patch fixes mi-file.exp fails on remote host. First, we can't
assume ${srcdir}/${subdir}/${srcfile} directory exists on remote host,
so this patch changes it to match ${srcfile} only on remote host.
Second, regexp pattern ".*/${srcfile}" isn't friendly to Windows path.
The file name is "basics.c" in my test env and can't match the pattern
due to "/" in it. Remove "/" from the pattern.
gdb/testsuite:
2014-05-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-file.exp (test_file_list_exec_source_file): Don't
match absolute path on remote host.
(test_file_list_exec_source_files): Remove "/" from the
pattern.
After I run test like this,
$ make check RUNTESTFLAGS='--host_board=local-remote-host dw2-basic.exp'
gdb.dwarf2/file1.txt in source tree was removed. In some gdb.dwarf2/*.exp,
file1.txt is copied to host and then removed at the end. However, in
local-remote-host-notty.exp, ${board}_download doesn't copy the file but
return the absolute path of the src file. 'remote_file host delete' at
the end will remove the file in source tree.
This patch is to overwrite ${board}_file, and specially make "delete"
option do nothing. This approach is used in gdbserver-base.exp and
remote-stdio-gdbserver.exp too.
gdb/testsuite:
2014-05-14 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-notty.exp (${board}_file): New
proc.
gdb/Changelog:
* aarch64-tdep.c (aarch64_software_single_step): New function.
(aarch64_gdbarch_init): Handle single stepping of atomic sequences
with aarch64_software_single_step.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-atomic-inst.c: New file.
* gdb.arch/aarch64-atomic-inst.exp: New file.
Hi,
I recently see the fail in dwzbuildid.exp below on some targets,
(gdb) print the_int
No symbol "the_int" in current context.
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: print the_int
Looks the pattern expects to see "No symbol table is loaded", which
is emitted in c-exp.y,
variable: name_not_typename
....
if (msymbol.minsym != NULL)
write_exp_msymbol (pstate, msymbol);
else if (!have_full_symbols () && !have_partial_symbols ())
error (_("No symbol table is loaded. Use the \"file\" command."));
else
error (_("No symbol \"%s\" in current context."),
copy_name ($1.stoken));
it is expected to have no full symbols nor partial symbols, but something
brings full symbols or partial symbols in. I added "maint info symtabs"
and "maint info psymtabs" in dwzbuildid.exp, and it shows symbols are from
ld.so, which has debug information. Then, I reproduce the fail like this,
$ make check RUNTESTFLAGS="CFLAGS_FOR_TARGET='-Wl,-rpath=${glibc_build}:${glibc_build}/math -Wl,--dynamic-linker=${glibc_build}/elf/ld.so' dwzbuildid.exp"
${glibc_build} is the glibc build tree. Debug information is not striped,
so the test fail. However, if I strip debug information from libc.so, libm.so
and ld.so. The test passes.
This patch is to relax the pattern to match the both cases that glibc build
has and has not debug information.
gdb/testsuite:
2014-05-07 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwzbuildid.exp: Match output "No symbol "the_int" in
current context" too.
2014-05-05 Keith Seitz <keiths@redhat.com>
* linespec.c (linespec_parse_basic): Run cleanups if a convenience
variable or history value is successfully parsed.
2014-05-05 Keith Seitz <keiths@redhat.com>
* gdb.linespec/ls-dollar.exp: Add test for linespec
file:convenience_variable.
In gdb.trace/unavailable.exp, an action is defined to collect
struct_b.struct_a.array[2] and struct_b.struct_a.array[100],
struct StructB
{
int d, ef;
StructA struct_a;
int s:1;
static StructA static_struct_a;
const char *string;
};
and the other files are not collected.
When GDB examine traceframe collected by the action, "struct_b" is
unavailable completely, which is wrong.
(gdb) p struct_b
$1 = <unavailable>
When GDB reads 'struct_b', it will request to read memory at struct_b's address
of length LEN. Since struct_b.d is not collected, no 'M' block
includes the first part of the desired range, so tfile_xfer_partial returns
TARGET_XFER_UNAVAILABLE and GDB thinks the whole requested range is unavailable.
In order to fix this problem, in the iteration to 'M' blocks, we record the
lowest address of blocks within the request range. If it has, the requested
range isn't unavailable completely. This applies to ctf too. With this patch
applied, the result looks good and fails in unavailable.exp is fixed.
(gdb) p struct_b
$1 = {d = <unavailable>, ef = <unavailable>, struct_a = {a = <unavailable>, b = <unavailable>, array = {<unavailable>,
<unavailable>, -1431655766, <unavailable> <repeats 97 times>, -1431655766, <unavailable> <repeats 9899 times>}, ptr = <unavailable>, bitfield = <unavailable>}, s = <unavailable>, static static_struct_a = {a = <unavailable>, b = <unavailable>, array = {<unavailable> <repeats 10000 times>}, ptr = <unavailable>,
bitfield = <unavailable>}, string = <unavailable>}
gdb:
2014-05-05 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* tracefile-tfile.c (tfile_xfer_partial): Record the lowest
address of blocks that intersects the requested range. Trim
LEN up to LOW_ADDR_AVAILABLE if read from executable read-only
sections.
* ctf.c (ctf_xfer_partial): Likewise.
gdb/testsuite:
2014-05-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Save
traceframes into tfile and ctf trace files. Read data from
trace file and test collected data.
(gdb_collect_locals_test): Likewise.
(gdb_unavailable_registers_test): Likewise.
(gdb_unavailable_floats): Likewise.
(gdb_collect_globals_test): Likewise.
(top-level): Append "ctf" to trace_file_targets if GDB
supports.
This patch moves traceframe checking code out of traceframe generation,
so that we can generation traceframe once, and do the checking in multiple
times (with target remote, tfile and ctf respectively). This is a
pure refactor, not functional changes in unavailable.exp.
gdb/testsuite:
2014-05-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Move some
code to ...
(gdb_collect_args_test_1): ... it. New proc.
(gdb_collect_locals_test): Move some code to ...
(gdb_collect_locals_test_1): ... it. New proc.
(gdb_unavailable_registers_test): Move some code to ...
(gdb_unavailable_registers_test_1): ... it. New proc.
(gdb_unavailable_floats): Move some code to ...
(gdb_unavailable_floats_1): ... it. New proc.
This commit is actually an update to make the parser in
gdb/stap-probe.c be aware of all the possible prefixes that a probe
argument can have. According to the section "Argument Format" in:
<https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation>
The bitness of the arguments can be 8, 16, 32 or 64 bits, signed or
unsigned. Currently GDB recognizes only 32 and 64-bit arguments.
This commit extends this. It also provides a testcase, only for
x86_64 systems.
gdb/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (enum stap_arg_bitness): New enums to represent 8
and 16-bit signed and unsigned arguments. Update comment.
(stap_parse_probe_arguments): Extend code to handle such
arguments. Use warning instead of complaint to notify about
unrecognized bitness.
gdb/testsuite/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-stap-optional-prefix.S (main): Add several
probes to test for bitness recognition.
* gdb.arch/amd64-stap-optional-prefix.exp
(test_probe_value_without_reg): New procedure.
Add code to test for different kinds of bitness.
This commit fixes PR breakpoints/16889, which is about a bug that
triggers when GDB tries to parse probes whose arguments do not contain
the initial (and optional) "N@" part. For reference sake, the de
facto format is described here:
<https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation>
Anyway, this PR actually uncovered two bugs (related) that were
happening while parsing the arguments. The first one was that the
parser *was* catching *some* arguments that were missing the "N@"
part, but it wasn't correctly setting the argument's type. This was
causing a NULL pointer being dereferenced, ouch...
The second bug uncovered was that the parser was not catching all of
the cases for a probe which did not provide the "N@" part. The fix
for that was to simplify the check that the code was making to
identify non-prefixed probes. The code is simpler and easier to read
now.
I am also providing a testcase for this bug, only for x86_64
architectures.
gdb/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16889
* stap-probe.c (stap_parse_probe_arguments): Simplify
check for non-prefixed probes (i.e., probes whose
arguments do not start with "N@"). Always set the
argument type to a sane value.
gdb/testsuite/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16889
* gdb.arch/amd64-stap-optional-prefix.S: New file.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
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.
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.
This add a testcases that verifies correct handling of dynamicity
for lower bounds of arrays.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_arrayidx: New testcase.
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.
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.
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.
gdb/testsuite/
* gdb.cp/cpexprs.cc: Move braces to the same line as the start
of the function to work across GCC and Clang.
* gdb.cp/cpexprs.exp: Account for GCC/Clang difference in vtable
pointer types (const void ** const V void **).
This patch adds support for the Intel(R) Advanced Vector
Extensions 512 (Intel(R) AVX-512) registers. Native and remote
debugging are covered by this patch.
Intel(R) AVX-512 is an extension to AVX to support 512-bit wide
SIMD registers in 64-bit mode (XMM0-XMM31, YMM0-YMM31, ZMM0-ZMM31).
The number of available registers in 32-bit mode is still 8
(XMM0-7, YMM0-7, ZMM0-7). The lower 256-bits of the ZMM registers
are aliased to the respective 256-bit YMM registers. The lower
128-bits are aliased to the respective 128-bit XMM registers.
There are also 8 new, dedicated mask registers (K0-K7) in both 32-bit
mode and 64-bit mode.
For more information please see
Intel(R) Developer Zone: Intel(R) AVX
http://software.intel.com/en-us/intel-isa-extensions#pid-16007-1495
Intel(R) Architecture Instruction Set Extensions Programming Reference:
http://software.intel.com/en-us/file/319433-017pdf
2014-04-24 Michael Sturm <michael.sturm@mintel.com>
Walfred Tedeschi <walfred.tedeschi@intel.com>
* amd64-linux-nat.c (amd64_linux_gregset32_reg_offset): Add
AVX512 registers.
(amd64_linux_read_description): Add code to handle AVX512 xstate
mask and return respective tdesc.
* amd64-linux-tdep.c: Include features/i386/amd64-avx512-linux.c
and features/i386/x32-avx512-linux.c.
(amd64_linux_gregset_reg_offset): Add AVX512 registers.
(amd64_linux_core_read_description): Add code to handle AVX512
xstate mask and return respective tdesc.
(_initialize_amd64_linux_tdep): Initialize AVX512 tdesc.
* amd64-linux-tdep.h (AMD64_LINUX_ORIG_RAX_REGNUM): Adjust regnum
calculation.
(AMD64_LINUX_NUM_REGS): Adjust to new number of registers.
(tdesc_amd64_avx512_linux): New prototype.
(tdesc_x32_avx512_linux): Likewise.
* amd64-tdep.c: Include features/i386/amd64-avx512.c and
features/i386/x32-avx512.c.
(amd64_ymm_avx512_names): New register names for pseudo
registers YMM16-31.
(amd64_ymmh_avx512_names): New register names for raw registers
YMMH16-31.
(amd64_k_names): New register names for K registers.
(amd64_zmmh_names): New register names for ZMM raw registers.
(amd64_zmm_names): New registers names for ZMM pseudo registers.
(amd64_xmm_avx512_names): New register names for XMM16-31
registers.
(amd64_pseudo_register_name): Add code to return AVX512 pseudo
registers.
(amd64_init_abi): Add code to intitialize AVX512 tdep variables
if feature is present.
(_initialize_amd64_tdep): Call AVX512 tdesc initializers.
* amd64-tdep.h (enum amd64_regnum): Add AVX512 registers.
(AMD64_NUM_REGS): Adjust to new number of registers.
* i386-linux-nat.c (GETXSTATEREGS_SUPPLIES): Extend range of
registers supplied via XSTATE by AVX512 registers.
(i386_linux_read_description): Add case for AVX512.
* i386-linux-tdep.c: Include i386-avx512-linux.c.
(i386_linux_gregset_reg_offset): Add AVX512 registers.
(i386_linux_core_read_description): Add case for AVX512.
(i386_linux_init_abi): Install supported register note section
for AVX512.
(_initialize_i386_linux_tdep): Add call to tdesc init function for
AVX512.
* i386-linux-tdep.h (I386_LINUX_NUM_REGS): Set number of
registers to be number of zmm7h + 1.
(tdesc_i386_avx512_linux): Add tdesc for AVX512 registers.
* i386-tdep.c: Include features/i386/i386-avx512.c.
(i386_zmm_names): Add ZMM pseudo register names array.
(i386_zmmh_names): Add ZMM raw register names array.
(i386_k_names): Add K raw register names array.
(num_lower_zmm_regs): Add constant for the number of lower ZMM
registers. AVX512 has 16 more ZMM registers than there are YMM
registers.
(i386_zmmh_regnum_p): Add function to look up register number of
ZMM raw registers.
(i386_zmm_regnum_p): Likewise for ZMM pseudo registers.
(i386_k_regnum_p): Likewise for K raw registers.
(i386_ymmh_avx512_regnum_p): Likewise for additional YMM raw
registers added by AVX512.
(i386_ymm_avx512_regnum_p): Likewise for additional YMM pseudo
registers added by AVX512.
(i386_xmm_avx512_regnum_p): Likewise for additional XMM registers
added by AVX512.
(i386_register_name): Add code to hide YMMH16-31 and ZMMH0-31.
(i386_pseudo_register_name): Add ZMM pseudo registers.
(i386_zmm_type): Construct and return vector registers type for ZMM
registers.
(i386_pseudo_register_type): Return appropriate type for YMM16-31,
ZMM0-31 pseudo registers and K registers.
(i386_pseudo_register_read_into_value): Add code to read K, ZMM
and YMM16-31 registers from register cache.
(i386_pseudo_register_write): Add code to write K, ZMM and
YMM16-31 registers.
(i386_register_reggroup_p): Add code to include/exclude AVX512
registers in/from respective register groups.
(i386_validate_tdesc_p): Handle AVX512 feature, add AVX512
registers if feature is present in xcr0.
(i386_gdbarch_init): Add code to initialize AVX512 feature
variables in tdep structure, wire in pseudo registers and call
initialize_tdesc_i386_avx512.
* i386-tdep.h (struct gdbarch_tdep): Add AVX512 related
variables.
(i386_regnum): Add AVX512 registers.
(I386_SSE_NUM_REGS): New define for number of SSE registers.
(I386_AVX_NUM_REGS): Likewise for AVX registers.
(I386_AVX512_NUM_REGS): Likewise for AVX512 registers.
(I386_MAX_REGISTER_SIZE): Change to 64 bytes, ZMM registers are
512 bits wide.
(i386_xmm_avx512_regnum_p): New prototype for register look up.
(i386_ymm_avx512_regnum_p): Likewise.
(i386_k_regnum_p): Likewise.
(i386_zmm_regnum_p): Likewise.
(i386_zmmh_regnum_p): Likewise.
* i387-tdep.c : Update year in copyright notice.
(xsave_ymm_avx512_offset): New table for YMM16-31 offsets in
XSAVE buffer.
(XSAVE_YMM_AVX512_ADDR): New macro.
(xsave_xmm_avx512_offset): New table for XMM16-31 offsets in
XSAVE buffer.
(XSAVE_XMM_AVX512_ADDR): New macro.
(xsave_avx512_k_offset): New table for K register offsets in
XSAVE buffer.
(XSAVE_AVX512_K_ADDR): New macro.
(xsave_avx512_zmm_h_offset): New table for ZMM register offsets
in XSAVE buffer.
(XSAVE_AVX512_ZMM_H_ADDR): New macro.
(i387_supply_xsave): Add code to supply AVX512 registers to XSAVE
buffer.
(i387_collect_xsave): Add code to collect AVX512 registers from
XSAVE buffer.
* i387-tdep.h (I387_NUM_XMM_AVX512_REGS): New define for number
of XMM16-31 registers.
(I387_NUM_K_REGS): New define for number of K registers.
(I387_K0_REGNUM): New define for K0 register number.
(I387_NUM_ZMMH_REGS): New define for number of ZMMH registers.
(I387_ZMM0H_REGNUM): New define for ZMM0H register number.
(I387_NUM_YMM_AVX512_REGS): New define for number of YMM16-31
registers.
(I387_YMM16H_REGNUM): New define for YMM16H register number.
(I387_XMM16_REGNUM): New define for XMM16 register number.
(I387_YMM0_REGNUM): New define for YMM0 register number.
(I387_KEND_REGNUM): New define for last K register number.
(I387_ZMMENDH_REGNUM): New define for last ZMMH register number.
(I387_YMMH_AVX512_END_REGNUM): New define for YMM31 register
number.
(I387_XMM_AVX512_END_REGNUM): New define for XMM31 register
number.
* common/i386-xstate.h: Add AVX 3.1 feature bits, mask and XSTATE
size.
* features/Makefile: Add AVX512 related files.
* features/i386/32bit-avx512.xml: New file.
* features/i386/64bit-avx512.xml: Likewise.
* features/i386/amd64-avx512-linux.c: Likewise.
* features/i386/amd64-avx512-linux.xml: Likewise.
* features/i386/amd64-avx512.c: Likewise.
* features/i386/amd64-avx512.xml: Likewise.
* features/i386/i386-avx512-linux.c: Likewise.
* features/i386/i386-avx512-linux.xml: Likewise.
* features/i386/i386-avx512.c: Likewise.
* features/i386/i386-avx512.xml: Likewise.
* features/i386/x32-avx512-linux.c: Likewise.
* features/i386/x32-avx512-linux.xml: Likewise.
* features/i386/x32-avx512.c: Likewise.
* features/i386/x32-avx512.xml: Likewise.
* regformats/i386/amd64-avx512-linux.dat: New file.
* regformats/i386/amd64-avx512.dat: Likewise.
* regformats/i386/i386-avx512-linux.dat: Likewise.
* regformats/i386/i386-avx512.dat: Likewise.
* regformats/i386/x32-avx512-linux.dat: Likewise.
* regformats/i386/x32-avx512.dat: Likewise.
* NEWS: Add note about new support for AVX512.
testsuite/
* Makefile.in (EXECUTABLES): Added i386-avx512.
* gdb.arch/i386-avx512.c: New file.
* gdb.arch/i386-avx512.exp: Likewise.
gdbserver/
* Makefile.in: Added rules to handle new files
i386-avx512.c i386-avx512-linux.c amd64-avx512.c
amd64-avx512-linux.c x32-avx512.c x32-avx512-linux.c.
* configure.srv (srv_i386_regobj): Add i386-avx512.o.
(srv_i386_linux_regobj): Add i386-avx512-linux.o.
(srv_amd64_regobj): Add amd64-avx512.o and x32-avx512.o.
(srv_amd64_linux_regobj): Add amd64-avx512-linux.o and
x32-avx512-linux.o.
(srv_i386_32bit_xmlfiles): Add i386/32bit-avx512.xml.
(srv_i386_64bit_xmlfiles): Add i386/64bit-avx512.xml.
(srv_amd64_xmlfiles): Add i386/amd64-avx512.xml and
i386/x32-avx512.xml.
(srv_i386_linux_xmlfiles): Add i386/i386-avx512-linux.xml.
(srv_amd64_linux_xmlfiles): Add i386/amd64-avx512-linux.xml and
i386/x32-avx512-linux.xml.
* i387-fp.c (num_avx512_k_registers): New constant for number
of K registers.
(num_avx512_zmmh_low_registers): New constant for number of
lower ZMM registers (0-15).
(num_avx512_zmmh_high_registers): New constant for number of
higher ZMM registers (16-31).
(num_avx512_ymmh_registers): New contant for number of higher
YMM registers (ymm16-31 added by avx521 on x86_64).
(num_avx512_xmm_registers): New constant for number of higher
XMM registers (xmm16-31 added by AVX512 on x86_64).
(struct i387_xsave): Add space for AVX512 registers.
(i387_cache_to_xsave): Change raw buffer size to 64 characters.
Add code to handle AVX512 registers.
(i387_xsave_to_cache): Add code to handle AVX512 registers.
* linux-x86-low.c (init_registers_amd64_avx512_linux): New
prototypei from generated file.
(tdesc_amd64_avx512_linux): Likewise.
(init_registers_x32_avx512_linux): Likewise.
(tdesc_x32_avx512_linux): Likewise.
(init_registers_i386_avx512_linux): Likewise.
(tdesc_i386_avx512_linux): Likewise.
(x86_64_regmap): Add AVX512 registers.
(x86_linux_read_description): Add code to handle AVX512 XSTATE
mask.
(initialize_low_arch): Add code to initialize AVX512 registers.
doc/
* gdb.texinfo (i386 Features): Add description of AVX512
registers.
Change-Id: Ifc4c08c76b85dbec18d02efdbe6182e851584438
Signed-off-by: Michael Sturm <michael.sturm@intel.com>
breakpoint table handling. This is a patch in five parts (all committed
here in one commit).
----- 1/5: parse_args
parse_args is a very useful utility function which allows you to do
getopt-y kinds of things in Tcl.
Example:
proc myproc {foo args} {
parse_args {{bar} {baz "abc"} {qux}}
# ...
}
myproc ABC -bar -baz DEF peanut butter
will define the following variables in myproc:
foo (=ABC), bar (=1), baz (=DEF), and qux (=0)
args will be the list {peanut butter}
----- 2/5: mi_build_kv_pairs
build_kv_pairs simply does what it says: given the input list
and an option join string, it combines list elements into kv-pairs
for MI handling. It knows how to handle tuples and other special
MI types.
Example:
mi_build_kv_pairs {a b c d e f g \[.*\]}
returns a=\"b\",c=\"d\",e=\"f\",g=\[.*\]
----- 3/5: mi_make_breakpoint
This function builds breakpoint regexps, such as
"bkpt={number=\".*\", [snip]}".
Note that ONLY the options given to mi_make_breakpoint/mi_create_breakpoint
will actually be tested. So if -number is omitted, the regexp will allow
anything [number=\".*\"]
Examples:
mi_make_breakpoint -number 3
mi_create_breakpoint "myfile.c:21" -file myfile.c -line 21
----- 4/5: mi_make_breakpoint_table
This function builds MI breakpoint table regexps.
Example:
set bps {}
lappend bps [mi_make_breakpoint -number 1 -func "main" \
-file ".*/myfile.c" -line 42
lappend bps [mi_make_breakpoint -number 2 -func "marker" \
-file ".*myfile.c" -line 21
gdb_test "-break-info" "\\^done,[mi_make_breakpoint_table $bps]" \
"breakpoint list"
----- 5/5: Update all callers
Self-explanatory
testsuite/ChangeLog
2014-04-23 Keith Seitz <keiths@redhat.com>
* lib/mi-support.exp (mi_list_breakpoints): Delete.
(mi_make_breakpoint_table): New procedure.
(mi_create_breakpoint): Use mi_make_breakpoint
and return the result.
(mi_make_breakpoint): New procedure.
(mi_build_kv_pairs): New procedure.
* gdb.mi/mi-break.exp: Remove unused globals,
update mi_create_breakpoint usage, and use mi_make_breakpoint_table.
All callers updated.
* gdb.mi/mi-dprintf.exp: Use variable to track command
number.
Update all callers of mi_create_breakpoint and use
mi_make_breakpoint_table.
Remove any unused global variables.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.mi/mi-nsmoribund.exp: Likewise.
* gdb.mi/mi-nsthrexec.exp: Likewise.
* gdb.mi/mi-reverse.exp: Likewise.
* gdb.mi/mi-simplerun.exp: Likewise.
* gdb.mi/mi-stepn.exp: Likewise.
* gdb.mi/mi-syn-frame.exp: Likewise.
* gdb.mi/mi-until.exp: Likewise.
* gdb.mi/mi-var-cp.exp: Likewise.
* gdb.mi/mi-var-display.exp: Likewise.
* gdb.mi/mi2-amd64-entry-value.exp: Likewise.
* gdb.mi/mi2-var-child.exp: Likewise.
* gdb.mi/mi-vla-c99.exp: Likewise.
* lib/mi-support.exp: Likewise.
From Ian Lance Taylor <iant@cygnus.com>:
* lib/gdb.exp (parse_args): New procedure.
Without the code portion of the patch, we get these failures:
FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue
FAIL: gdb.base/break-unload-file.exp: always-inserted on: hbreak: continue
FAIL: gdb.base/sym-file.exp: stale bkpts: continue to breakpoint: end here
They all looks like random SIGTRAPs:
continue
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000400541 in foo () at ../../../src/gdb/testsuite/gdb.base/break-unload-file.c:21
21 }
(gdb) FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue
(This is a regression caused by the remove-symbol-file command
series.)
break-unload-file.exp is about having breakpoints inserted, and then
doing "file". I caught this while writing a test that does "file
PROGRAM", while PROGRAM was already loaded, which internally does
"file" first, because I wanted to force a breakpoint_re_set, but the
test is more explicit in case GDB ever optimizes out that re-set.
The problem is that unloading the file with "file" ends up in
disable_breakpoints_in_freed_objfile, which marks all breakpoint
locations of the objfile as both shlib_disabled, _and_ clears the
inserted flag, without actually removing the breakpoints from the
inferior. Now, usually, in all-stop, breakpoints will already be
removed from the inferior before the user can issue the "file"
command, but, with non-stop, or breakpoints always-inserted on mode,
breakpoints stay inserted even while the user has the prompt. In the
latter case, then, if we let the program continue, and it executes the
address where we had previously set the breakpoint, it'll actually
execute the breakpoint instruction that we left behind...
Now, one issue is that the intent of
disable_breakpoints_in_freed_objfile is really to handle the unloading
of OBJF_USERLOADED objfiles. These are objfiles that were added with
add-symbol-file and that are removed with remove-symbol-file.
"add-symbol-file"'s docs in the manual clearly say these commands are
used to let GDB know about dynamically loaded code:
You would use this command when @var{filename} has been dynamically
loaded (by some other means) into the program that is running.
Similarly, the online help says:
(gdb) help add-symbol-file
Load symbols from FILE, assuming FILE has been dynamically loaded.
So it makes sense to, like when shared libraries are unloaded through
the generic solib machinery, mark the breakpoint locations as
shlib_disabled. But, the "file" command is not about dynamically
loaded code, it's about the main program. So the patch makes
disable_breakpoints_in_freed_objfile skip all objfiles but
OBJF_USERLOADED ones, thus skipping the main objfile.
Then, the reason that disable_breakpoints_in_freed_objfile was
clearing the inserted flag isn't clear, but likely to avoid breakpoint
removal errors, assuming remove-symbol-file was called after the
dynamic object was already unmapped from the inferior. In that case,
it'd okay to simply clear the inserted flag, but not so if the user
for example does remove-symbol-file to remove the library because he
made a mistake in the library's address, and wants to re-do
add-symbol-file with the correct address.
To address all that, I propose an alternative implementation, that
handles both cases. The patch includes changes to sym-file.exp to
cover them.
This implementation leaves the inserted flag alone, and handles
breakpoint insertion/removal failure gracefully when the locations are
in OBJF_USERLOADED objfiles, just like we handle insertion/removal
failure gracefully for locations in shared libraries.
To try to make sure we aren't patching back stale shadow memory
contents into the inferior, in case the program mapped a different
library at the same address where we had the breakpoint, without the
user having had a chance of remove-symbol-file'ing before, this adds a
new memory_validate_breakpoint function that checks if the breakpoint
instruction is still in memory. ppc_linux_memory_remove_breakpoint
does this unconditionally for all memory breakpoints, and questions
whether memory_remove_breakpoint should be changed to do this for all
breakpoints. Possibly yes, though I'm not certain, hence this
baby-steps patch.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2014-04-23 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Tolerate errors if the
breakpoint is set in a user-loaded objfile.
(remove_breakpoint_1): Likewise. Also tolerate errors if the
location is marked shlib_disabled. If the breakpoint is set in a
user-loaded objfile is a GDB-side memory breakpoint, validate it
before uninsertion. (disable_breakpoints_in_freed_objfile): Skip
non-OBJF_USERLOADED objfiles. Don't clear the location's inserted
flag.
* mem-break.c (memory_validate_breakpoint): New function.
* objfiles.c (userloaded_objfile_contains_address_p): New
function.
* objfiles.h (userloaded_objfile_contains_address_p): Declare.
* target.h (memory_validate_breakpoint): New declaration.
gdb/testsuite/
2014-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/break-unload-file.c: New file.
* gdb.base/break-unload-file.exp: New file.
* gdb.base/sym-file-lib.c (baz): New function.
* gdb.base/sym-file-loader.c (struct segment) <mapped_size>: New
field.
(load): Store the segment's mapped size.
(unload): New function.
(unload_shlib): New function.
* gdb.base/sym-file-loader.h (unload_shlib): New declaration.
* gdb.base/sym-file-main.c (main): Unload, and reload the library,
set a breakpoint at baz, and call it.
* gdb.base/sym-file.exp: New tests for stale breakpoint
instructions.
libraries.
As explained in
https://sourceware.org/ml/gdb-patches/2008-08/msg00361.html, after a
shared library was unloaded, we can no longer insert or remove
breakpoints into/from its (no longer present) code segment. That'll
fail with memory errors. However, that concern does not apply to
hardware breakpoints. By definition, hardware breakpoints are
implemented using a mechanism that is not dependent on being able to
modify the target's memory. Usually, by setting up CPU debug
registers. IOW, we should be able to set hw breakpoints in an
unmapped address. We don't seem to have a test that exercises that,
so this patch adds one.
I noticed the error supression because of a related issue -- the
target_insert_hw_breakpoint/target_remove_hw_breakpoint interfaces
don't really distinguish "not supported" from "error" return, and so
remote.c returns -1 in both cases. This results in hardware
breakpoints set in shared libraries silently ending up pending forever
even though the target doesn't actually support hw breakpoints.
(gdb) set breakpoint always-inserted on
(gdb) set remote Z-packet off
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) hbreak shrfunc
Hardware assisted breakpoint 3 at 0x7ffff7dfb657: file ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c, line 21.
(gdb) info break
Num Type Disp Enb Address What
3 hw breakpoint keep y <PENDING> shrfunc
After the patch we get the expected:
(gdb) hbreak shrfunc
Hardware assisted breakpoint 3 at 0x7ffff7dfb657: file ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c, line 21.
Warning:
Cannot insert hardware breakpoint 3.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
(gdb) info break
Num Type Disp Enb Address What
3 hw breakpoint keep y 0x00007ffff7dfb657 in shrfunc at ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c:21
(HW breakpoints set in the main executable, when the target doesn't
support HW breakpoints always resulted in the latter output.)
We probably should improve the insert/remove interface to return a
different error code for unsupported. But I chose to fix the error
supression first, as it's a deeper and wider issue.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2014-04-23 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location, remove_breakpoint_1): If
the breakpoint is set in a shared library, only suppress
errors for software breakpoints, not hardware breakpoints.
gdb/testsuite/
2014-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/hbreak-in-shr-unsupported-shr.c: New file.
* gdb.base/hbreak-in-shr-unsupported.c: New file.
* gdb.base/hbreak-in-shr-unsupported.exp: New file.
* gdb.base/hbreak-unmapped.c: New file.
* gdb.base/hbreak-unmapped.exp: New file.
* gdb.trace/qtro.exp (gdb_is_target_remote): Move ...
* lib/gdb.exp (gdb_is_target_remote): ... here.
If a thread trips on a breakpoint that needs stepping over just after
finishing a step over, GDB currently fails an assertion. This is a
regression caused by the "Handle multiple step-overs." patch
(99619beac6) at
https://sourceware.org/ml/gdb-patches/2014-02/msg00765.html.
(gdb) x /4i $pc
=> 0x400540 <main+4>: movl $0x0,0x2003da(%rip) # 0x600924 <i>
0x40054a <main+14>: movl $0x1,0x2003d0(%rip) # 0x600924 <i>
0x400554 <main+24>: movl $0x2,0x2003c6(%rip) # 0x600924 <i>
0x40055e <main+34>: movl $0x3,0x2003bc(%rip) # 0x600924 <i>
(gdb) PASS: gdb.base/consecutive-step-over.exp: get breakpoint addresses
break *0x40054a
Breakpoint 2 at 0x40054a: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 23.
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set breakpoint
condition $bpnum condition
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set condition
break *0x400554
Breakpoint 3 at 0x400554: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 24.
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set breakpoint
condition $bpnum condition
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set condition
break *0x40055e
Breakpoint 4 at 0x40055e: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 25.
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set breakpoint
condition $bpnum condition
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set condition
break 27
Breakpoint 5 at 0x400568: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 27.
(gdb) continue
Continuing.
../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
FAIL: gdb.base/consecutive-step-over.exp: continue to breakpoint: break here (GDB internal error)
The assertion fails, because the code is not expecting that the event
thread itself might need another step over. IOW, not expecting that
TP in:
tp = find_thread_needs_step_over (stepping_thread != NULL,
stepping_thread);
could be the event thread.
A small fix for this would be to clear the event thread's
trap_expected earlier, before asserting. But looking deeper, although
currently_stepping_or_nexting_callback's intention is finding the
thread that is doing a step/next, it also returns the thread that is
doing a step-over dance, with trap_expected set. If there ever was a
reason for that (it was I who added
currently_stepping_or_nexting_callback , but I can't recall why I put
trap_expected there in the first place), the only remaining reason
nowadays is to aid in implementing switch_back_to_stepped_thread's
assertion that is now triggering, by piggybacking on the walk over all
threads, thus avoiding a separate walk. This is quite obscure, and I
think we can do even better, by merging the walks that look for the
stepping thread, and the walk that looks for some thread that might
need a step over.
Tested on x86_64 Fedora 17, native and gdbserver, and also native on
top of my "software single-step on x86_64" series.
gdb/
2014-04-22 Pedro Alves <palves@redhat.com>
* infrun.c (schedlock_applies): New function, factored out from
find_thread_needs_step_over.
(find_thread_needs_step_over): Use it.
(switch_back_to_stepped_thread): Always clear trap_expected if the
step over is finished. Return early if scheduler locking applies.
Look for the stepping thread and a potential step-over thread with
a single loop.
(currently_stepping_or_nexting_callback): Delete.
2014-04-22 Pedro Alves <palves@redhat.com>
* gdb.base/consecutive-step-over.c: New file.
* gdb.base/consecutive-step-over.exp: New file.
This switches the gdb_continue_to_breakpoint routine to use
gdb_test_multiple instead of send_gdb/gdb_expect, so that an internal
error is detected immediately, instead of failing on timeout.
gdb/testsuite/
2014-04-22 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_continue_to_breakpoint): Use gdb_test_multiple
instead of send_gdb/gdb_expect.
In gdb.trace/tfile.exp, we execute binary to generate tracefile,
remote_exec target "$binfile"
however, this fails on bare metal target. This patch is to
handle binary execution failure by running binary in GDB.
The binary will do some io operation to generate tracefile, so
we need a check 'target_info exists gdb,nofileio'.
This patch is to check whether tracefile is generated. tfile.exp can
be skipped if generation is failed, while test_tfind_tfile in
mi-traceframe-changed.exp is skipped if generated failed. The rest of
the mi-traceframe-changed.exp can still be executed, because on some
bare metal targets, the remote stub supports tracepoint but doesn't
support fileio.
gdb/testsuite:
2014-04-22 Yao Qi <yao@codesourcery.com>
* lib/trace-support.exp (generate_tracefile): New procedure.
* gdb.trace/tfile.exp: Skip the test if generate_tracefile
return 0.
* gdb.trace/mi-traceframe-changed.exp: Invoke test_tfind_tfile
if generate_tracefile returns 1.
This PR is about an assertion failure in GDB that can be triggered by
setting "backtrace limit" to a value that causes GDB to stop unwinding
after an inline frame. In this case, an assertion in
inline_frame_this_id will trigger:
/* We need a valid frame ID, so we need to be based on a valid
frame. (...). */
gdb_assert (frame_id_p (*this_id));
Looking at the function:
static void
inline_frame_this_id (struct frame_info *this_frame,
void **this_cache,
struct frame_id *this_id)
{
struct symbol *func;
/* In order to have a stable frame ID for a given inline function,
we must get the stack / special addresses from the underlying
real frame's this_id method. So we must call get_prev_frame.
Because we are inlined into some function, there must be previous
frames, so this is safe - as long as we're careful not to
create any cycles. */
*this_id = get_frame_id (get_prev_frame (this_frame));
we see we're computing the frame id for the inline frame. If this is
an inline frame, which is a virtual frame constructed based on debug
info, on top of a real stack frame, we should _always_ be able to find
where the frame was inlined into, as that ultimately just means
peeling off the virtual frames on top of the real stack frame. If
there ultimately was no prev (real) stack frame, then we wouldn't have
been able to construct the inline frame either, by design. That's
what the assertion catches.
So we have an inline frame, we should _always_ be able to compute its
ID, even if that means bypassing the user backtrace limits to get at
the real stack frame's info. The problem is that inline_frame_id
calls get_prev_frame, and that takes user backtrace limits into
account. Code that wants to bypass the limits calls get_prev_frame_1
instead.
Note how get_prev_frame_1 already skips all checks for inline frames:
/* If we are unwinding from an inline frame, all of the below tests
were already performed when we unwound from the next non-inline
frame. We must skip them, since we can not get THIS_FRAME's ID
until we have unwound all the way down to the previous non-inline
frame. */
if (get_frame_type (this_frame) == INLINE_FRAME)
return get_prev_frame_if_no_cycle (this_frame);
And note how the related frame_unwind_caller_id function also uses
get_prev_frame_1:
struct frame_id
frame_unwind_caller_id (struct frame_info *next_frame)
{
struct frame_info *this_frame;
/* Use get_prev_frame_1, and not get_prev_frame. The latter will truncate
the frame chain, leading to this function unintentionally
returning a null_frame_id (e.g., when a caller requests the frame
ID of "main()"s caller. */
next_frame = skip_artificial_frames (next_frame);
this_frame = get_prev_frame_1 (next_frame);
if (this_frame)
return get_frame_id (skip_artificial_frames (this_frame));
else
return null_frame_id;
}
get_prev_frame_1 is currently static in frame.c. As a _1 suffix is
not a good name for an extern function, I've renamed it.
Tested on x86-64 Fedora 17.
gdb/
2014-04-18 Pedro alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
PR backtrace/15558
* frame.c (get_prev_frame_1): Rename to ...
(get_prev_frame_always): ... this, and make extern. Adjust.
(skip_artificial_frames): Use get_prev_frame_always.
(frame_unwind_caller_id, frame_pop, get_prev_frame)
(get_frame_unwind_stop_reason): Adjust to rename.
* frame.h (get_prev_frame_always): Declare.
* inline-frame.c: Include frame.h.
(inline_frame_this_id): Use get_prev_frame_always.
gdb/testsuite/
2014-04-18 Tom Tromey <palves@redhat.com>
Pedro alves <tromey@redhat.com>
PR backtrace/15558
* gdb.opt/inline-bt.exp: Test backtracing from an inline function
with a backtrace limit.
* gdb.python/py-frame-inline.exp: Test running to an inline
function with a backtrace limit, and printing the newest frame.
* gdb.python/py-frame-inline.c (main): Call f.
Hi,
We find gdb.base/printcmds.exp fails a lot on windows host, like this,
p ctable1[163]
$204 = 163 '£'
(gdb) FAIL: gdb.base/printcmds.exp: p ctable1[163]
however, on linux host,
p ctable1[163]
$205 = 163 '\243'
(gdb) PASS: gdb.base/printcmds.exp: p ctable1[163]
The printing related code is in valprint.c:print_wchar,
if (gdb_iswprint (w) && (!need_escape || (!gdb_iswdigit (w)
&& w != LCST ('8')
&& w != LCST ('9'))))
{
gdb_wchar_t wchar = w;
if (w == gdb_btowc (quoter) || w == LCST ('\\'))
obstack_grow_wstr (output, LCST ("\\"));
obstack_grow (output, &wchar, sizeof (gdb_wchar_t));
}
else
{
// print W in hex or octal digits
}
When I debug gdb on different hosts, I find
on windows host, gdb_iswprint (iswprint) returns true if 'w' is 163.
However, on linux host, iswprint returns false if 'w' is 163. Looks
this difference is caused by the charset. On Linux host,
the target-charset is ANSI_X3.4-1968, while on windows host, the
target-charset is CP1252.
We can see how target-charset affects the output. On linux host,
(gdb) set target-charset ASCII
(gdb) p ctable1[163]
$1 = 163 '\243'
(gdb) set target-charset CP1252
(gdb) p ctable1[163]
$2 = 163 '£'
we can print the pound sign too, and it shows target-charset does
affect the output.
This patch is to set target-charset temporarily to ASCII for some
charset-sensitive tests. Tested on arm-none-eabi and
powerpc-linux-gnu on mingw32 host. More than one hundred fails are
fixed.
gdb/testsuite:
2014-04-17 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (with_target_charset): New proc.
* gdb.base/printcmds.exp (test_print_all_chars): Wrap tests with
with_target_charset.
(test_print_strings): Likewise.
(test_repeat_bytes): Likewise.
* gdb.base/setvar.exp: Set target-charset to ASCII temporarily
for some tests.
Install some sanity checks that sibling DIE offsets are not beyond the
defined limits of the DWARF input buffer in read_partial_die and skip_one_die.
2014-03-20 Keith Seitz <keiths@redhat.com>
PR gdb/15827
* dwarf2read.c (skip_one_die): Check that all relative-offset
sibling DIEs fall within range of the current reader's buffer.
(read_partial_die): Likewise.
2014-03-20 Keith Seitz <keiths@redhat.com>
PR gdb/15827
* gdb.dwarf2/corrupt.c: New file.
* gdb.dwarf2/corrupt.exp: New file.
[forgot to commit/push these with previous push]
If lookup_symbol_file tries to locate a member variable with NULL name:
/* A simple lookup failed. Check if the symbol was defined in
a base class. */
cleanup = make_cleanup (null_cleanup, NULL);
/* Find the name of the class and the name of the method,
variable, etc. */
prefix_len = cp_entire_prefix_len (name);
/* If no prefix was found, search "this". */
if (prefix_len == 0)
{
struct type *type;
struct symbol *this;
this = lookup_language_this (language_def (language_cplus), block);
if (this == NULL)
{
do_cleanups (cleanup);
return NULL;
}
type = check_typedef (TYPE_TARGET_TYPE (SYMBOL_TYPE (this)));
klass = xstrdup (TYPE_NAME (type));
nested = xstrdup (name);
}
TYPE_NAME (type) is NULL, so xstrdup (NULL) and boom!
This can happen, e.g., with clang++. See testsuite/gdb.cp/namelessclass.exp
or the bugzilla report.
This patch simply adds a fencepost against this case, allowing the caller
of lookup_symbol_file to search other blocks for the right symbol.
* lib/gdbserver-support.exp (gdbserver_default_get_remote_address):
Add comment.
(gdbserver_default_get_comm_port): New function.
(gdbserver_start): Check if board file provided
"gdbserver,get_comm_port" and use it if so.
* boards/native-stdio-gdbserver.exp (sockethost): Set to "".
(gdb,socketport): Set to "stdio".
(gdbserver,get_comm_port): Set to ${board}_get_comm_port.
(stdio_gdbserver_template): Delete.
(${board}_get_remote_address): Update.
(${board}_build_remote_cmd): Delete.
(${board}_get_comm_port): New function.
(${board}_spawn): Update.
* boards/remote-stdio-gdbserver.exp (${board}_build_remote_cmd):
Delete.
(${board}_get_remote_address): Update.
(${board}_get_comm_port): New function.
https://sourceware.org/ml/gdb-patches/2014-04/msg00210.html
Improve the regexp used in the memattr.exp test so allow for different
memory regions (.data / .bss) being laid out in different orders.
gdb/testsuite/ChangeLog:
* gdb.base/memattr.exp: Improve regexps to handle memory regions
appearing in any order.
This test uses a simple custom elf loader, implemented in
gdb.base/sym-file-loader.h|c. This loader doesn't have a dlclose-like
function today, but I'll need one. But, I found that the guts of the
loader are exposed too much to the client, making the interface more
complicated than necessary. It's simpler if the loader just exports a
few dlopen/dlsym -style functions. That's what this patch does.
Tested on x86_86 Fedora 17, native and gdbserver.
gdb/testsuite/
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file-loader.h: Move inclusion of <inttypes.h>,
<ansidecl.h>, <elf/common.h> and <elf/external.h> to
sym-file-loader.c.
(Elf_External_Phdr, Elf_External_Ehdr, Elf_External_Shdr)
(Elf_External_Sym, Elf_Addr, GET, GETADDR, struct segment): Move
to sym-file-loader.c.
(struct library): Forward declare.
(load_shlib, lookup_function): Change prototypes.
(find_shstrtab, find_strtab, find_shdr, find_symtab)
(translate_offset): Remove declarations.
(get_text_addr): New declaration.
* gdb.base/sym-file-loader.c: Move inclusion of <inttypes.h>,
<ansidecl.h>, <elf/common.h> and <elf/external.h> here from
sym-file-loader.h.
(Elf_External_Phdr, Elf_External_Ehdr, Elf_External_Shdr)
(Elf_External_Sym, Elf_Addr, GET, GETADDR, struct segment): Move
here from sym-file-loader.h.
(struct library): New structure.
(load_shlib, lookup_function): Change prototypes and adjust to
work with a struct library.
(find_shstrtab, find_strtab, find_shdr, find_symtab)
(translate_offset): Make static.
(get_text_addr): New function.
* gdb.base/sym-file-main.c (main): Adjust to new loader interface.
SELF_LINK, not SELK_LINK...
gdb/testsuite/
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file-loader.c: Fix typo. SELF_LINK, not SELK_LINK.
The main issue here is that this test passes the host's absolute path
to the library to load to the "dlopen"-like routine, which doesn't
work when either the target or the host are remote, unless a shared
filesystem has been set up.
Tests that dynamically load a library solve this by dlopen'ing by
basename, and setting rpath to $ORIGIN. See gdb_compile.
This test doesn't use dlopen, but instead uses its own simple elf
loader. The fix is to pass this loader the library basename, and
teach it to look up the library by basename in the executable's
directory as well, i.e., assuming/emulating RPATH=$ORIGIN.
Tested on x86_64 Fedora 17, native and gdbserver.
I looked around in the web to figure out Linux's /proc/self/exe
equivalents in other ELF OSs. I think I covered all relevant, but if
not, I think it'll be simple enough to add more. (Note the test is
skipped on non-ELF targets.)
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/testsuite/
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file-loader.c: Include <limits.h>.
(SELF_LINK): New define.
(get_origin): New function.
(load_shlib): Use it.
* gdb.base/sym-file.exp: Don't early return if the target is
remote. Use runto_main, and issue fail is that fails. Use
gdb_load_shlibs.
(shlib_name): Delete.
(lib_so, lib_syms, lib_dlopen): New globals. Use them throughout.
Remove regex characters from test message, and don't refer to
breakpoint numbers in test messages (subsequent patches will add more
breakpoints, changing these numbers). Result:
-PASS: gdb.base/sym-file.exp: add-symbol-file .*sym-file-lib\.so addr
+PASS: gdb.base/sym-file.exp: add-symbol-file sym-file-lib.so addr
-PASS: gdb.base/sym-file.exp: check if Breakpoint 2 is pending.
-PASS: gdb.base/sym-file.exp: check if Breakpoint 3 is pending.
+PASS: gdb.base/sym-file.exp: breakpoint at foo is pending
+PASS: gdb.base/sym-file.exp: breakpoint at bar is pending
gdb/testsuite/
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file.exp: Remove regex characters from test
message. Don't refer to breakpoint numbers in test messages.
PR c++/16253.
symbol_matches_domain was permitting searches for a VAR_DOMAIN
symbol to also match STRUCT_DOMAIN symbols for languages like C++
where STRUCT_DOMAIN symbols also define a typedef of the same name,
e.g., "struct foo {}" introduces a typedef of the name "foo".
Problems occur if there exists both a VAR_DOMAIN and STRUCT_DOMAIN
symbol of the same name. Then it is essentially a race between which
symbol is found first. The other symbol is obscurred.
[This is a relatively common idiom: enum e { ... } e;]
This patchset moves this "language defines a typedef" logic to
lookup_symbol[_in_language], looking first for a symbol in the given
domain and falling back to searching STRUCT_DOMAIN when/if appropriate.
2014-04-14 Keith Seitz <keiths@redhat.com>
PR c++/16253
* ada-lang.c (ada_symbol_matches_domain): Moved here and renamed
from symbol_matches_domain in symtab.c. All local callers
of symbol_matches_domain updated.
(standard_lookup): If DOMAIN is VAR_DOMAIN and no symbol is found,
search STRUCT_DOMAIN.
(ada_find_any_type_symbol): Do not search STRUCT_DOMAIN
independently. standard_lookup will do that automatically.
* cp-namespace.c (cp_lookup_symbol_nonlocal): Explain when/why
VAR_DOMAIN searches may return a STRUCT_DOMAIN match.
(cp_lookup_symbol_in_namespace): Likewise.
If no VAR_DOMAIN symbol is found, search STRUCT_DOMAIN.
(cp_lookup_symbol_exports): Explain when/why VAR_DOMAIN searches
may return a STRUCT_DOMAIN match.
(lookup_symbol_file): Search for the class name in STRUCT_DOMAIN.
* cp-support.c: Include language.h.
(inspect_type): Explicitly search STRUCT_DOMAIN before searching
VAR_DOMAIN.
* psymtab.c (match_partial_symbol): Compare the requested
domain with the symbol's domain directly.
(lookup_partial_symbol): Likewise.
* symtab.c (lookup_symbol_in_language): Explain when/why
VAR_DOMAIN searches may return a STRUCT_DOMAIN match.
If no VAR_DOMAIN symbol is found, search STRUCT_DOMAIN for
appropriate languages.
(symbol_matches_domain): Renamed `ada_symbol_matches_domain'
and moved to ada-lang.c
(lookup_block_symbol): Explain that this function only returns
symbol matching the requested DOMAIN.
Compare the requested domain with the symbol's domain directly.
(iterate_over_symbols): Compare the requested domain with the
symbol's domain directly.
* symtab.h (symbol_matches_domain): Remove.
2014-04-14 Keith Seitz <keiths@redhat.com>
PR c++/16253
* gdb.cp/var-tag.cc: New file.
* gdb.cp/var-tag.exp: New file.
* gdb.dwarf2/dw2-ada-ffffffff.exp: Set the language to C++.
* gdb.dwarf2/dw2-anon-mptr.exp: Likewise.
* gdb.dwarf2/dw2-double-set-die-type.exp: Likewise.
* gdb.dwarf2/dw2-inheritance.exp: Likewise.
This adds support for the C++11 "enum class" feature. This is
PR c++/15246.
I chose to use the existing TYPE_DECLARED_CLASS rather than introduce
a new type code. This seemed both simple and clear to me.
I made overloading support for the new enum types strict. This is how
it works in C++; and it didn't seem like an undue burden to keep this,
particularly because enum constants are printed symbolically by gdb.
Built and regtested on x86-64 Fedora 20.
2014-04-14 Tom Tromey <tromey@redhat.com>
PR c++/15246:
* c-exp.y (type_aggregate_p): New function.
(qualified_name, classify_inner_name): Use it.
* c-typeprint.c (c_type_print_base): Handle TYPE_DECLARED_CLASS
and TYPE_TARGET_TYPE of an enum type.
* dwarf2read.c (read_enumeration_type): Set TYPE_DECLARED_CLASS on
an enum type.
(determine_prefix) <case DW_TAG_enumeration_type>: New case;
handle TYPE_DECLARED_CLASS.
* gdbtypes.c (rank_one_type): Handle TYPE_DECLARED_CLASS on enum
types.
* gdbtypes.h (TYPE_DECLARED_CLASS): Update comment.
* valops.c (enum_constant_from_type): New function.
(value_aggregate_elt): Use it.
* cp-namespace.c (cp_lookup_nested_symbol): Handle
TYPE_CODE_ENUM.
2014-04-14 Tom Tromey <tromey@redhat.com>
* gdb.cp/classes.exp (test_enums): Handle underlying type.
* gdb.dwarf2/enum-type.exp: Add test for enum with underlying
type.
* gdb.cp/enum-class.exp: New file.
* gdb.cp/enum-class.cc: New file.
Simon Marchi