Fixes:
Running .../src/gdb/testsuite/gdb.base/solib-nodir.exp ...
FAIL: gdb.base/solib-nodir.exp: library loaded
... by using the new "set cwd" command.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* gdb.base/solib-nodir.exp: Split is_remote and skip_shlib_tests
calls and add comments. Skip test if use_gdb_stub is set.
(top level): Use "set cwd" command instead of "cd" command.
This commit makes --target_board=native-gdbserver (and in principle
all other is_remote boards) pass all the same gdb.base/scope.exp tests
as native testing.
I first wrote the gdb.base/scope.exp change described in the ChangeLog
below and in the new comments in the patch, knowing that gdb_file_cmd
was the right thing to use here.
However, that revealed that the native-extended-gdbserver board should
be overriding gdb_file_cmd+gdb_reload instead of gdb_load, as is
hinted at by the comments on top of the default implementations in
testsuite/lib/gdb.exp, because otherwise a gdb_run_cmd after
gdb_file_cmd misses setting "set remote exec-file". However, if we do
that and remove gdb_load, then we regress gdb.base/dbx.exp, so for now
keep the gdb_load override as well.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.base/scope.exp: Use build_executable + clean_restart +
gdb_file_cmd instead of prepare_for_testing and no longer skip
"before run" tests on is_remote target boards. Update comments.
* boards/native-extended-gdbserver.exp
(extended_gdbserver_load_last_file): New, factored out from ...
(gdb_load): ... this. Move further below and add comment.
(extended_gdbserver_gdb_file_cmd, gdb_file_cmd, gdb_reload): New.
I'm not sure whether this gdb64 was ever a thing in the upstream repo,
but it certainly doesn't exist nowadays.
AFAICT, this came in with the original big merge with the HP tree:
https://sourceware.org/ml/gdb-patches/1999-q2/msg00149.html
gdb/testsuite/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
* gdb.base/attach.exp: Remove references to gdb64.
* gdb.base/dbx.exp: Remove references to gdb64.
This works fine with remote target boards.
gdb/testsuite/ChangeLog:
2017-10-12 Simon Marchi <simon.marchi@polymtl.ca>
Pedro Alves <palves@redhat.com>
* gdb.base/label.exp: Remove is_remote target check.
Currently we get:
Running .../src/gdb/testsuite/gdb.base/auxv.exp ...
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
After this commit we get all the same PASSes as when native testing.
The problem is that the testcase wants to create a core dump in a
temporary directory and it is using the "cd" command to start the
inferior with that directory as current directory, but that command
only affects the inferior's cwd when native debugging. Fix it by
using using the new "set cwd" command instead, which works with
gdbserver as well.
This still won't work with stub-like targets, because with those when
we connect the inferior is already running. It'd be possible to make
it work by making the inferior itself change dirs, but we'll need to
make the native-gdbserver board no longer set is_remote first.
gdb/testsuite/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
* gdb.base/auvx.exp (coredir): Update comment.
(top level) <core_works>: Use "set cwd" command instead of "cd"
command.
Another case of a stale check. We support following forks in the
remote protocol nowadays.
gdb/testsuite/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* gdb.base/catch-fork-static.exp: No longer skip on is_remote
target boards.
This gets rid of a number of FAILs with
--target_board=native-extended-gdbserver.
The fact that checkpointing does not work has nothing to do with
dejagnu's native and remote concepts. It only works with native Linux
targets because the implementation is currently baked with
linux-nat.c.
gdb/testsuite/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* gdb.base/checkpoint.exp: Don't check is_remote or isnative.
Instead skip if there's any gdb_protocol set.
1. is_remote is not the right check.
2. Both Simon & Pedro ran it continuously for some time against
native-gdbserver and didn't see a failure.
3. The test has been running against native-extended-gdbserver anyway.
gdb/testsuite/ChangeLog:
2017-10-12 Simon Marchi <simon.marchi@polymtl.ca>
Pedro Alves <palves@redhat.com>
* gdb.base/dprintf-non-stop.exp: Remove is_remote target check.
Check for gdbserver instead of dejagnu remote. Unlike what the
comment says, the test actually fails with target remote + gdbserver
(it does pass with extended-remote). The result is:
FAIL -> KFAIL with --target_board=native-gdbserver
KPASS -> PASS with --target_board=native-extended-gdbserver
gdb/testsuite/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* gdb.base/argv0-symlink.exp: kfail on remote gdbserver,
instead of on dejagnu remote boards.
We support follow-fork in the remote protocol nowadays.
Also, the right way to enable non-stop mode is to do it before
connecting, and for use_gdb_stub boards, that means we have to do it
at gdb_load time. The "modern" pattern for that is to pass non-stop
in GDBFLAGS.
This makes the test pass with --target_board=native-gdbserver.
gdb/testsuite/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* gdb.base/inferior-died.exp: Remove is_remote and isnative
checks. Use build_executable + clean_restart instead of
prepare_for_testing. Pass "set non-stop on" via GDBFLAGS instead
of enabling non-stop after starting gdb.
This commit makes the gdb.threads/non-ldr-exc-*.exp tests run (and
pass) with --target_board=native-gdbserver.
(These tests were already running with
--target_board=native-extended-gdbserver, because that board is not
is_remote.)
The "No exec event support in the remote protocol." comment is stale.
It's actually supported.
gdb/ChangeLog:
2017-10-12 Pedro Alves <palves@redhat.com>
* gdb.threads/non-ldr-exc-1.exp: No longer skip if is_remote target.
* gdb.threads/non-ldr-exc-2.exp: Ditto.
* gdb.threads/non-ldr-exc-3.exp: Ditto.
* gdb.threads/non-ldr-exc-4.exp: Ditto.
There was a problem with generation of the disassembler options for ARC in GDB,
because a BFD architecture name was used as a CPU name, but they have different
meaning even if some architectures have same name as respective CPUs. Target
description specifies a BFD architecture, which is different from ARC CPU, as
accepted by the disassembler (and most other ARC tools), because CPU values are
much more fine grained - there can be multiple CPU values per single BFD
architecture. As a result this code should translate architecture to some CPU
value. Since there is no info on exact CPU configuration, it is best to use
the most feature-rich CPU, so that the disassembler will recognize all
instructions available to the specified architecture.
gdb/ChangeLog
yyyy-mm-dd Anton Kolesov <Anton.Kolesov@synopsys.com>
* arc-tdep.c (arc_gdbarch_init): Pass proper cpu value to disassembler.
* arc-tdep.h (arc_arch_is_em): New function.
(arc_arch_is_hs): Likewise.
gdb/testsuite/ChangeLog
yyyy-mm-dd Anton Kolesov <Anton.Kolesov@synopsys.com>
* gdb.arch/arc-tdesc-cpu.exp: New file.
* gdb.arch/arc-tdesc-cpu.xml: Likewise.
The get_integer_valueof outputs the value it has read as part of the
test name. This causes test names to vary from run to run, and adds
some noise when diffing test results. e.g.:
-PASS: gdb.threads/process-dies-while-detaching.exp: multi-process: continue: killed outside: get integer valueof "mypid" (28770)
+PASS: gdb.threads/process-dies-while-detaching.exp: multi-process: continue: killed outside: get integer valueof "mypid" (32238)
This patch removes that, since it's probably not very useful.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (get_integer_valueof): Don't output read value in test name.
This patch gets rid of catch_exceptions / catch_exceptions_with_msg.
The latter is done mostly by getting rid of the three remaining
vestigial libgdb wrapper functions, which are really pointless
nowadays. This results in a good number of simplifications.
(I checked that Insight doesn't use those functions.)
The gdb.mi/mi-pthreads.exp change is necessary because this actually
fixes a bug, IMO -- the patch stops MI's -thread-select causing output
on the CLI stream.
I.e., before:
-thread-select 123456789
&"Thread ID 123456789 not known.\n"
^error,msg="Thread ID 123456789 not known."
(gdb)
After:
-thread-select 123456789
^error,msg="Thread ID 123456789 not known."
(gdb)
gdb/ChangeLog
2017-10-10 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* breakpoint.c (struct captured_breakpoint_query_args)
(do_captured_breakpoint_query, gdb_breakpoint_query): Delete.
(print_breakpoint): New.
* breakpoint.h (print_breakpoint): Declare.
* common/common-exceptions.h (enum return_reason): Remove
references to catch_exceptions.
* exceptions.c (catch_exceptions, catch_exceptions_with_msg):
Delete.
* exceptions.h (catch_exceptions_ftype, catch_exceptions)
(catch_exception_ftype, catch_exceptions_with_msg): Delete.
* gdb.h: Delete.
* gdbthread.h (thread_select): Declare.
* mi/mi-cmd-break.c: Don't include gdb.h.
(breakpoint_notify): Use print_breakpoint.
* mi/mi-cmd-catch.c: Don't include gdb.h.
* mi/mi-interp.c: Don't include gdb.h.
(mi_print_breakpoint_for_event): New.
(mi_breakpoint_created, mi_breakpoint_modified): Use
mi_print_breakpoint_for_event.
* mi/mi-main.c: Don't include gdb.h.
(mi_cmd_thread_select): Parse the global thread ID here. Use
thread_select instead of gdb_thread_select.
(mi_cmd_thread_list_ids): Output "thread-ids" tuple here instead
of using gdb_list_thread_ids.
* remote-fileio.c (do_remote_fileio_request): Change type. Reply
FILEIO_ENOSYS here.
(remote_fileio_request): Use TRY/CATCH instead of
catch_exceptions.
* symfile-mem.c (struct symbol_file_add_from_memory_args)
(symbol_file_add_from_memory_wrapper): Delete.
(add_vsyscall_page): Use TRY/CATCH instead of catch_exceptions.
* thread.c: Don't include gdb.h.
(do_captured_list_thread_ids, gdb_list_thread_ids): Delete.
(thread_alive): Use thread_select.
(do_captured_thread_select): Delete, parts salvaged as ...
(thread_select): ... this new function.
(gdb_thread_select): Delete.
gdb/testsuite/ChangeLog
2017-10-10 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-pthreads.exp (check_mi_thread_command_set): Don't
expect CLI output.
If you want to use catch_errors with a function with parameters, then
currently you have to manually write a "capture" struct wrapping the
arguments and marshall/unmarshall that.
https://sourceware.org/ml/gdb-patches/2017-09/msg00834.html proposed
adjusting catch_errors to use gdb::function_view, which would allow
passing lambdas with automatic captures. However, it seems like using
TRY/CATCH directly instead ends up producing clearer and easier to
debug code. This is what this commit does.
Note that removing catch_errors exposes further cleanup opportunities
around no longer having to follow catch_errors callback type, and also
removes a few cleanups.
I didn't do anything to save/restore current_uiout because I think
that should be the responsibility of the code that changes
current_uiout in the first place.
(Another approach could be to make catch_errors a variadic template
like:
template<typename Function, typename... Args>
int catch_errors (const char *errstring, return_mask mask,
Function &&func, Args... args);
and then with:
extern void function_with_args (int, int);
extern void function_with_no_args ();
calls to the above functions would be wrapped like this:
catch_errors ("some error happened", RETURN_MASK_ERROR,
function_with_args, arg1, arg2);
catch_errors ("some error happened", RETURN_MASK_ERROR,
function_with_no_args);
but I'm thinking that that doesn't improve much if at all either.)
gdb/ChangeLog
2017-10-10 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* breakpoint.c (breakpoint_cond_eval): Change return type to bool
and reverse logic.
(WP_DELETED, WP_VALUE_CHANGED, WP_VALUE_NOT_CHANGED, WP_IGNORE):
No longer macros. Instead ...
(enum wp_check_result): They're now values of this new
enumeration.
(watchpoint_check): Change return type to wp_check_result and
parameter type to bpstat.
(bpstat_check_watchpoint): Use TRY/CATCH instead of catch_errors.
(bpstat_check_breakpoint_conditions): Use TRY/CATCH instead of
catch_errors. Reverse logic of watchpoint_check call.
(breakpoint_re_set_one): Now returns void and takes a breakpoint
pointer as parameter.
(breakpoint_re_set): Use TRY/CATCH instead of catch_errors.
* common/common-exceptions.c (throw_exception_sjlj): Update
comments to avoid mentioning catch_errors.
* exceptions.c (catch_errors): Delete.
* exceptions.h: Update comments to avoid mentioning catch_errors.
(catch_errors_ftype, catch_errors): Delete.
* infrun.c (normal_stop): Use TRY/CATCH instead of catch_errors.
(hook_stop_stub): Delete.
(restore_selected_frame): Change return type to void, and
parameter type to const frame_id &.
(restore_infcall_control_state): Use TRY/CATCH instead of
catch_errors.
* main.c (captured_command_loop): Return void and remove
parameter. Remove references to catch_errors.
(captured_main): Use TRY/CATCH instead of catch_errors.
* objc-lang.c (objc_submethod_helper_data)
(find_objc_msgcall_submethod_helper): Delete.
(find_objc_msgcall_submethod): Use TRY/CATCH instead of
catch_errors.
* record-full.c (record_full_message): Return void.
(record_full_message_args, record_full_message_wrapper): Delete.
(record_full_message_wrapper_safe): Return bool and use TRY/CATCH
instead of catch_errors.
* solib-aix.c (solib_aix_open_symbol_file_object): Change
parameter type to int.
* solib-darwin.c (open_symbol_file_object): Ditto.
* solib-dsbt.c (open_symbol_file_object): Ditto.
* solib-frv.c (open_symbol_file_object): Ditto.
* solib-svr4.c (open_symbol_file_object): Ditto.
* solib-target.c (solib_target_open_symbol_file_object): Ditto.
* solib.c (update_solib_list): Use TRY/CATCH instead of
catch_errors.
* solist.h (struct target_so_ops) <open_symbol_file_object>:
Change type.
* symmisc.c (struct print_symbol_args): Remove.
(dump_symtab_1): Use TRY/CATCH instead of catch_errors.
(print_symbol): Change type.
* windows-nat.c (handle_load_dll, handle_unload_dll): Return void
and remove parameters.
(catch_errors): New.
(get_windows_debug_event): Adjust.
gdb/testsuite/ChangeLog:
2017-10-10 Pedro Alves <palves@redhat.com>
* lib/selftest-support.exp (selftest_setup): Update for
captured_command_loop's prototype change.
The gdb.multi/multi-arch-exec.exp testcase currently tests execing
from -m64 to -m32, but does not test the other direction. For
thoroughness, this commit fixes that. Without the fix in the previous
commit for example ("Multi-arch exec, more register reading
avoidance"), on x86_64 we would get different symptoms depending on
"execing direction". Vis:
Continuing.
Truncated register 50 in remote 'g' packet
Truncated register 50 in remote 'g' packet
(gdb) FAIL: gdb.multi/multi-arch-exec.exp: first_arch=1: selected_thread=2: follow_exec_mode=same: continue across exec that changes architecture
Vs:
Continuing.
Remote 'g' packet reply is too long (expected 440 bytes, got 816 bytes): daffffffffffffff0000[snip]
Remote 'g' packet reply is too long (expected 440 bytes, got 816 bytes): daffffffffffffff0000[snip]
(gdb) FAIL: gdb.multi/multi-arch-exec.exp: first_arch=2: selected_thread=2: follow_exec_mode=same: continue across exec that changes architecture
gdb/testsuite/ChangeLog:
2017-10-09 Pedro Alves <palves@redhat.com>
Test both arch1=>arch2 and arch2=>arch1.
* gdb.multi/multi-arch-exec.exp (exec1, srcfile1, binfile1, exec2)
(srcfile2, binfile2, march1, march2): Remove globals. Largely
factored out to...
(append_arch1_options, append_arch2_options, append_arch_options)
(build_executables): New procedures.
(do_test): New 'first_arch' parameter. Use it to define 'from_exec'
local.
(top level): Add new 'first_arch' testing axis.
As mentioned in commit bf93d7ba99 ("Add thread after updating
gdbarch when exec'ing"), we should avoid doing register reads after a
process does an exec and before we've updated that inferior's gdbarch.
Otherwise, we may interpret the registers using the wrong
architecture.
There's still (at least) one case where we still read registers
post-exec with the pre-exec architecture. That's when infrun decides
it needs to switch context to the exec'ing thread. I.e., if the exec
event is processed at a time when the current thread is not already
the exec'ing thread, then we get (with the test added by this commit):
continue
Continuing.
Truncated register 50 in remote 'g' packet
Truncated register 50 in remote 'g' packet
(gdb) FAIL: gdb.multi/multi-arch-exec.exp: selected_thread=2: follow_exec_mode=same: continue across exec that changes architecture
The fix is to avoid reading registers when switching context in this
case.
(I'd be nice to get rid of the constant stop_pc reading when switching
threads, but that'd be a deeper change.)
gdb/ChangeLog:
2017-10-09 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event_1) <TARGET_WAITKIND_EXECD>: Skip
reading registers when switching context.
gdb/testsuite/ChangeLog:
2017-10-09 Pedro Alves <palves@redhat.com>
* gdb.multi/multi-arch-exec.c: Include <pthread.h> and <assert.h>.
(barrier): New.
(thread_start, all_started): New functions.
(main): Spawn new thread and wait until it is scheduled.
* gdb.multi/multi-arch-exec.exp: Build $srcfile1 with the pthreads
option.
(do_test): Add 'selected_thread' parameter. Run to all_started
instead of main. Explicitly set the breakpoint at main. Switch
to the SELECTED_THREAD thread.
(top level): Test handling the exec event with either the main
thread or the second thread selected.
Fix a typo introduced in commit c56e7c4390 ("Make ctxobj.exp and
print-file-var.exp work on all platforms.").
This doesn't really affect the outcome of the testcase. I only
noticed the typo because I stepped through the program manually.
To avoid such problems if the test is extended, this moves the STOP
marker until after the program self-validates the values. With the
typo in place, this alone would have resulted in a test FAIL. I.e.,
it'd have caught the typo.
gdb/testsuite/ChangeLog:
2017-10-09 Pedro Alves <palves@redhat.com>
* gdb.base/print-file-var-main.c: Fix get_version_2 value check
logic. Move STOP marker after the value checks.
* gdb.base/print-file-var.exp (continue to STOP marker): Tighten
regexp.
This cleans up a number of interfaces in dfp.c / dfp.h. Specifically:
- The decimal_from_string / decimal_to_string routines are C++-ified
to operate on std::string instead of character buffers. In the
decimal_from_string, the boolean return value now actually is bool
instead of an int.
- The decimal_from_integral and decimal_from_doublest routines take
an struct value as input. This is not really appropriate at the low
level the DFP routines sit, so this replaced them with new routines
decimal_from_longest / decimal_from_ulongest / decimal_from_doublest
that operate on contents instead.
- To mirror the decimal_from_[u]longest, a new decimal_to_longest
routine is added as well, which can be used in unpack_long to
avoid an unnecessary conversion via DOUBLEST.
Note that the decimal_from_longest / decimal_from_ulongest routines
are actually more powerful than decimal_from_integral: the old routine
would only accept integer *types* of at most four bytes size, while
the new routines accept all integer *values* that fit in an [u]int32_t,
no matter which type they came from. The DFP tests are updated to
allow for this larger range of integers that can be converted.
gdb/ChangeLog:
2017-10-05 Ulrich Weigand <uweigand@de.ibm.com>
* dfp.h (MAX_DECIMAL_STRING): Move to dfp.c.
(decimal_to_string): Return std::string object.
(decimal_from_string): Accept std::string object. Return bool.
(decimal_from_integral, decimal_from_doublest): Remove.
(decimal_from_longest): Add prototype.
(decimal_from_ulongest): Likewise.
(decimal_to_longest): Likewise.
(decimal_from_doublest): Likewise.
* dfp.c: Do not include "gdbtypes.h" or "value.h".
(MAX_DECIMAL_STRING): Move here.
(decimal_to_string): Return std::string object.
(decimal_from_string): Accept std::string object. Return bool.
(decimal_from_integral): Remove, replace by ...
(decimal_from_longest, decimal_from_ulongest): ... these new functions.
(decimal_to_longest): New function.
(decimal_from_floating): Remove, replace by ...
(decimal_from_doublest): ... this new function.
(decimal_to_doublest): Update to new decimal_to_string interface.
* value.c (unpack_long): Use decimal_to_longest.
* valops.c (value_cast): Use decimal_from_doublest instead of
decimal_from_floating. Use decimal_from_[u]longest isntead of
decimal_from_integral.
* valarith.c (value_args_as_decimal): Likewise.
* valprint.c (print_decimal_floating): Update to new
decimal_to_string interface.
* printcmd.c (printf_decfloat): Likewise.
* c-exp.y (parse_number): Update to new decimal_from_string interface.
gdb/testsuite/ChangeLog:
2017-10-05 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.base/dfp-exprs.exp: Update tests to larger range of supported
integer-to-dfp conversion.
* gdb.base/dfp-test.exp: Likewise.
When debugging two inferiors (or more) against gdbserver, and the
inferiors have different architectures, such as e.g., on x86_64
GNU/Linux and one inferior is 64-bit while the other is 32-bit, then
GDB can get confused with the different architectures in a couple
spots.
In both cases I ran into, GDB incorrectly ended up using the
architecture of whatever happens to be the selected inferior instead
of the architecture of some other given inferior:
#1 - When parsing the expedited registers in stop replies.
#2 - In the default implementation of the target_thread_architecture
target method.
These resulted in instances of the infamous "Remote 'g' packet reply
is too long" error. For example, with the test added in this commit,
we get:
~~~
Continuing.
Remote 'g' packet reply is too long (expected 440 bytes, got 816 bytes): ad064000000000000[snip]
(gdb) FAIL: gdb.multi/multi-arch.exp: inf1 event with inf2 selected: continue to hello_loop
c
Continuing.
Truncated register 50 in remote 'g' packet
(gdb) PASS: gdb.multi/multi-arch.exp: inf2 event with inf1 selected: c
~~~
This commit fixes that.
gdb/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* remote.c (get_remote_arch_state): New 'gdbarch' parameter. Use
it instead of target_gdbarch.
(get_remote_state, get_remote_packet_size): Adjust
get_remote_arch_state calls, passing down target_gdbarch
explicitly.
(packet_reg_from_regnum, packet_reg_from_pnum): New parameter
'gdbarch' and use it instead of target_gdbarch.
(get_memory_packet_size): Adjust get_remote_arch_state calls,
passing down target_gdbarch explicitly.
(struct stop_reply) <arch>: New field.
(remote_parse_stop_reply): Use the stopped thread's architecture,
not the current inferior's. Save the architecture in the
stop_reply.
(process_stop_reply): Use the stop reply's architecture.
(process_g_packet, remote_fetch_registers)
(remote_prepare_to_store, store_registers_using_G)
(remote_store_registers): Adjust get_remote_arch_state calls,
using the regcache's architecture.
(remote_get_trace_status): Adjust get_remote_arch_state calls,
passing down target_gdbarch explicitly.
* spu-multiarch.c (spu_thread_architecture): Defer to the target
beneath instead of calling target_gdbarch.
* target.c (default_thread_architecture): Use the specified
inferior's architecture, instead of the current inferior's
architecture (via target_gdbarch).
gdb/testsuite/ChangeLog:
2017-10-04 Pedro Alves <palves@redhat.com>
* gdb.multi/hangout.c: Include <unistd.h>.
(hangout_loop): New function.
(main): Call alarm. Call hangout_loop in a loop.
* gdb.multi/hello.c: Include <unistd.h>.
(hello_loop): New function.
(main): Call alarm. Call hangout_loop in a loop.
* gdb.multi/multi-arch.exp: Test running to a breakpoint one
inferior with the other selected.
New in v3:
- Replace use_gdb_stub with can_spawn_for_attach.
- Call kill_wait_spawned_process on spawn_ids.
Commit
Use std::set in mi-main.c
52f9abe4c7
changed the logic of the "-list-thread-groups --available" by mistake
when a pid is passed. It prints all the processes except the one
specified by the given pid. The correct behavior is to only print the
process corresponding to that pid. this patch fixes that and adds a test.
gdb/ChangeLog:
* mi/mi-main.c (list_available_thread_groups): Reverse filter logic.
gdb/testsuite/ChangeLog:
* gdb.mi/list-thread-groups-available.exp: New file.
* gdb.mi/list-thread-groups-available.c: New file.
This is the "natural" extension necessary for the "set cwd" command
(and the whole "set the inferior's cwd" logic) to work on gdbserver.
The idea here is to have a new remote packet, QSetWorkingDir (name
adopted from LLDB's extension to the RSP, as can be seen at
<https://raw.githubusercontent.com/llvm-mirror/lldb/master/docs/lldb-gdb-remote.txt>),
which sends an hex-encoded string representing the working directory
that the remote inferior will use. There is a slight difference from
the packet proposed by LLDB: GDB's version will accept empty
arguments, meaning that the user wants to clear the previously set
working directory for the inferior (i.e., "set cwd" without arguments
on GDB).
For UNIX-like targets this feature is already implemented on
nat/fork-inferior.c, and all gdbserver has to do is to basically
implement "set_inferior_cwd" and call it whenever such packet arrives.
For other targets, like Windows, it is possible to use the existing
"get_inferior_cwd" function and do the necessary steps to make sure
that the inferior will use the specified working directory.
Aside from that, the patch consists basically of updates to the
testcase (making it available on remote targets) and the
documentation.
No regressions found.
gdb/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS (Changes since GDB 8.0): Add entry about new
'set-cwd-on-gdbserver' feature.
(New remote packets): Add entry for QSetWorkingDir.
* common/common-inferior.h (set_inferior_cwd): New prototype.
* infcmd.c (set_inferior_cwd): Remove "static".
(show_cwd_command): Expand text to include remote debugging.
* remote.c: Add PACKET_QSetWorkingDir.
(remote_protocol_features) <QSetWorkingDir>: New entry for
PACKET_QSetWorkingDir.
(extended_remote_set_inferior_cwd): New function.
(extended_remote_create_inferior): Call
"extended_remote_set_inferior_cwd".
(_initialize_remote): Call "add_packet_config_cmd" for
QSetWorkingDir.
gdb/gdbserver/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* inferiors.c (set_inferior_cwd): New function.
* server.c (handle_general_set): Handle QSetWorkingDir packet.
(handle_query): Inform that QSetWorkingDir is supported.
* win32-low.c (create_process): Pass the inferior's cwd to
CreateProcess.
gdb/testsuite/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/set-cwd.exp: Make it available on
native-extended-gdbserver.
gdb/doc/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Starting your Program) <The working directory.>:
Mention remote debugging.
(Working Directory) <Your Program's Working Directory>:
Likewise.
(Connecting) <Remote Packet>: Add "set-working-dir"
and "QSetWorkingDir" to the table.
(Remote Protocol) <QSetWorkingDir>: New item, explaining the
packet.
This commit adds new "set/show cwd" commands, which are used to
set/show the current working directory of the inferior that will be
started.
The idea here is that "set cwd" will become the de facto way of
setting the inferior's cwd. Currently, the user can use "cd" for
that, but there are side effects: with "cd", GDB also switches to
another directory, and that can impact the loading of scripts and
other files. With "set cwd", we separate the logic into a new
command.
To maintain backward compatibility, if the user issues a "cd" command
but doesn't use "set cwd", then the inferior's cwd will still be
changed according to what the user specified. However, "set cwd" has
precedence over "cd", so it can always be used to override it.
"set cwd" works in the following way:
- If the user sets the inferior's cwd by using "set cwd", then this
directory is saved into current_inferior ()->cwd and is used when
the inferior is started (see below).
- If the user doesn't set the inferior's cwd by using "set cwd", but
rather use the "cd" command as before, then this directory is
inherited by the inferior because GDB will have chdir'd into it.
On Unix-like hosts, the way the directory is changed before the
inferior execution is by expanding the user set directory before the
fork, and then "chdir" after the call to fork/vfork on
"fork_inferior", but before the actual execution. On Windows, the
inferior cwd set by the user is passed directly to the CreateProcess
call, which takes care of the actual chdir for us.
This way, we'll make sure that GDB's cwd is not affected by the user
set cwd.
gdb/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS (New commands): Mention "set/show cwd".
* cli/cli-cmds.c (_initialize_cli_cmds): Mention "set cwd" on
"cd" command's help text.
* common/common-inferior.h (get_inferior_cwd): New prototype.
* infcmd.c (inferior_cwd_scratch): New global variable.
(set_inferior_cwd): New function.
(get_inferior_cwd): Likewise.
(set_cwd_command): Likewise.
(show_cwd_command): Likewise.
(_initialize_infcmd): Add "set/show cwd" commands.
* inferior.h (class inferior) <cwd>: New field.
* nat/fork-inferior.c: Include "gdb_tilde_expand.h".
(fork_inferior): Change inferior's cwd before its execution.
* windows-nat.c (windows_create_inferior): Pass inferior's cwd
to CreateProcess.
gdb/gdbserver/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* inferiors.c (current_inferior_cwd): New global variable.
(get_inferior_cwd): New function.
* inferiors.h (struct process_info) <cwd>: New field.
gdb/doc/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Starting your Program) <The working directory.>:
Mention new "set cwd" command.
(Working Directory) <Your Program's Working Directory>:
Rephrase to explain that "set cwd" exists and is the default
way to change the inferior's cwd.
gdb/testsuite/ChangeLog:
2017-10-04 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/set-cwd.c: New file.
* gdb.base/set-cwd.exp: Likewise.
Printing a string slice ("&str") in Rust would print until the
terminating \0; but that is incorrect because a slice has a length.
This fixes &str printing, and arranges to preserve the type name when
slicing a slice, so that printing a slice of an "&str" works as well.
This is PR rust/22236.
2017-10-02 Tom Tromey <tom@tromey.com>
PR rust/22236:
* rust-lang.c (rust_val_print_str): New function.
(val_print_struct): Call it.
(rust_subscript): Preserve name of slice type.
2017-10-02 Tom Tromey <tom@tromey.com>
PR rust/22236:
* gdb.rust/simple.rs (main): New variable "fslice".
* gdb.rust/simple.exp: Add slice tests. Update string tests.
Something like "ptype &x[..]" (where "x" was a slice) would crash gdb.
rust_subscript wasn't handling slicing in the EVAL_AVOID_SIDE_EFFECTS
case.
2017-10-02 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_subscript): Handle slices in
EVAL_AVOID_SIDE_EFFECTS case.
2017-10-02 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Test ptype of a slice.
rust_slice_type_p was not recognizing &str as a slice type, so indexing
into (or making a slice of) a slice was not working.
2017-10-02 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_slice_type_p): Recognize &str as a slice type.
2017-10-02 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Test index of slice.
C++2a adds a "__VA_OPT__" feature that can be used to control the
pesky "," emission when the final (variable) argument of a variadic
macro is empty. This patch implements this feature for gdb. (A patch
to implement it for gcc is pending.)
gdb/ChangeLog
2017-09-27 Tom Tromey <tom@tromey.com>
* macroexp.c (get_next_token_for_substitution): New function.
(substitute_args): Call it. Check for __VA_OPT__.
gdb/testsuite/ChangeLog
2017-09-27 Tom Tromey <tom@tromey.com>
* gdb.base/macscp.exp: Add __VA_OPT__ tests.
compare-sections.exp has two cases that are not handled appropriately:
1) value read with msb set
2) error while patching that section
This patch adapts the "get value of read-only section" test to print
the value as an unsigned integer to fix 1) and test for the error
message to not set the written variable if read-only section cannot
be written to so as to solve 2).
2017-09-26 Thomas Preud'homme <thomas.preudhomme@arm.com>
Pedro Alves <palves@redhat.com>
gdb/testsuite/
* gdb.base/compare-sections.exp (get value of read-only section): Read
as unsigned value.
(corrupt read-only section): Likewise and don't set written if patching
failed.
As the title says, this is a test case for
Inferior.thread_from_thread_handle, a python method which will,
given a thread library dependent thread handle, find the GDB thread
which corresponds to that thread handle (in the inferior under
consideration).
The C file for this test case causes the thread handles for the
main thread and two child threads to be placed into an array. The
test case runs to one of the functions (do_something()) at which point,
it retrieves the thread handles from the array and attempts to find the
corresponding thread in GDB's internal thread list.
I use barriers to make sure that both threads have actually started;
execution will stop when one of the threads breaks at do_something.
Thanks to Simon Marchi for suggestions for forcing the thread
numbering to be stable.
gdb/testsuite/ChangeLog:
* gdb.python/py-thrhandle.c, gdb.python/py-thrhandle.exp: New
files.
Currently, with an ambiguous "list first,last", we get:
(gdb) list bar,main
Specified first line 'bar' is ambiguous:
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98
This commit makes gdb's output above a bit clearer by printing the
symbol name as well:
(gdb) list bar,main
Specified first line 'bar' is ambiguous:
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97, symbol: "bar(A)"
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98, symbol: "bar(B)"
And while at it, makes gdb print the symbol name when actually listing
multiple locations too. I.e., before (with "set listsize 2"):
(gdb) list bar
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97
96
97 int bar (A) { return 11; }
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98
97 int bar (A) { return 11; }
98 int bar (B) { return 22; }
After:
(gdb) list bar
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 97, symbol: "bar(A)"
96
97 int bar (A) { return 11; }
file: "src/gdb/testsuite/gdb.cp/overload.cc", line number: 98, symbol: "bar(B)"
97 int bar (A) { return 11; }
98 int bar (B) { return 22; }
Currently, the result of decoding a linespec loses information about
the original symbol that was found. All we end up with is an address.
This makes it difficult to find the original symbol again to get at
its print name. Fix that by storing a pointer to the symbol in the
sal. We already store the symtab and obj_section, so it feels like a
natural progression to me. This avoids having to do any extra symbol
lookup too.
gdb/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (list_command): Use print_sal_location.
(print_sal_location): New function.
(ambiguous_line_spec): Use print_sal_location.
* linespec.c (symbol_to_sal): Record the symbol in the sal.
* symtab.c (find_function_start_sal): Likewise.
* symtab.h (symtab_and_line::symbol): New field.
gdb/testsuite/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp (test_list_ambiguous_symbol): Expect
symbol names in gdb's output.
* gdb.cp/overload.exp ("list all overloads"): Likewise.
The "list" command allows specifying the name of variables as
argument, not just functions, so that users can type "list
a_global_variable".
That support is a broken when it comes to ambiguous locations though.
If there's more than one such global variable in the program, e.g.,
static globals in different compilation units, GDB ends up listing the
source of the first variable it finds, only.
linespec.c does find both symbol and minsym locations for all the
globals. The problem is that it ends up merging all the resulting
sals into one, because they all have address, zero. I.e., all sals
end up with sal.pc == 0, so maybe_add_address returns false for all
but the first.
The zero addresses appear because:
- in the minsyms case, linespec.c:minsym_found incorrectly treats all
minsyms as if they were function/text symbols. In list mode we can
end up with data symbols there, and we shouldn't be using
find_pc_sect_line on data symbols.
- in the debug symbols case, symbol_to_sal misses recording an address
(sal.pc) for non-block, non-label symbols.
gdb/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* linespec.c (minsym_found): Handle non-text minsyms.
(symbol_to_sal): Record a sal.pc for non-block, non-label symbols.
gdb/testsuite/ChangeLog:
2017-09-20 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp (test_list_ambiguous_function):
Rename to ...
(test_list_ambiguous_symbol): ... this and add a symbol name
parameter. Adjust.
(test_list_ambiguous_function): Reimplement on top of
test_list_ambiguous_symbol and also test listing ambiguous
variables.
* gdb.base/list-ambiguous0.c (ambiguous): Rename to ...
(ambiguous_fun): ... this.
(ambiguous_var): New.
* gdb.base/list-ambiguous1.c (ambiguous): Rename to ...
(ambiguous_fun): ... this.
(ambiguous_var): New.
Test was running on a fault during code execution. Analysis have shown
that the wrong instruction had been used. An instruction that takes
not alligned memory is more appropriated for the task.
ChangeLog:
2017-09-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/testesuite/ChangeLog:
* gdb.arch/i386-avx512.c (move_zmm_data_to_reg): Use
vmovups instead vmovaps.
(move_zmm_data_to_memory): Use vmovups instead vmovaps.
Change-Id: I4a95560861ef1792ed6ce86578fdd726162863f1
This works like 'start' but it stops at the first instruction rather
than the first line in main(). This is useful if one wants to single
step through runtime linker startup.
While here, introduce a RUN_ARGS_HELP macro for shared help text
between run, start, and starti. This includes expanding the help for
start and starti to include details from run's help text.
gdb/ChangeLog:
* NEWS (Changes since GDB 8.0): Add starti.
* infcmd.c (enum run_break): New.
(run_command_1): Queue pending event for RUN_STOP_AT_FIRST_INSN
case.
(run_command): Use enum run_how.
(start_command): Likewise.
(starti_command): New function.
(RUN_ARGS_HELP): New macro.
(_initialize_infcmd): Use RUN_ARGS_HELP for run and start
commands. Add starti command.
gdb/doc/ChangeLog:
* gdb.texinfo (Starting your Program): Add description of
starti command. Mention starti command as an alternative for
debugging the elaboration phase.
gdb/testsuite/ChangeLog:
* gdb.base/starti.c: New file.
* gdb.base/starti.exp: New file.
* lib/gdb.exp (gdb_starti_cmd): New procedure.
I'm seeing these failures on my system:
FAIL: gdb.base/nodebug.exp: p (double) mult (2.0, 3.0)
FAIL: gdb.base/nodebug.exp: p ((double (*) (double, double)) mult)(2.0f, 3.0f)
FAIL: gdb.base/nodebug.exp: p ((double (*) (double, double)) mult)(2, 3)
The problem is simply that GDB is finding a symbol named "mult" from
glibc's debug info:
(gdb) ptype mult
type = enum expression_operator {var, num, lnot, mult, divide, module, plus, minus, less_than, greater_than, less_or_equal, greater_or_equal, equal, not_equal, land, lor, qmop}
(gdb) info types expression_operator
All types matching regular expression "expression_operator":
File plural-exp.h:
enum expression_operator;
Fix this by unloading symbols from shared libraries.
gdb/testsuite/ChangeLog:
2017-09-14 Pedro Alves <palves@redhat.com>
* gdb.base/nodebug.exp (nodebug_runto): New procedure.
(top level): Use it instead of runto.
Change extract_arg to return a std::string and fix up all the users.
I think string is mildly better than unique_xmalloc_ptr<char>, when
possible, because it provides a more robust API.
I changed the error messages emitted from find_location_by_number to
avoid either writing to a string or an extra allocation; this can be
changed but I thought that the new message was not any less clear.
You can see an example in the testsuite patch.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* demangle.c (demangle_command): Update.
* breakpoint.c (disable_command): Update.
(enable_command): Update.
(find_location_by_number): Make "number" const. Use
get_number_trailer.
* cli/cli-utils.c (extract_arg): Return std::string.
* probe.c (parse_probe_linespec): Update. Change types.
(collect_probes): Take string arguments.
(parse_probe_linespec): Likewise.
(info_probes_for_ops): Update.
(enable_probes_command): Update.
(disable_probes_command): Update.
* break-catch-sig.c (catch_signal_split_args): Update.
* mi/mi-parse.c (mi_parse): Update.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.base/ena-dis-br.exp (test_ena_dis_br): Update test.
This adds a few new events to gdb's Python layer: new_inferior,
inferior_deleted, and new_thread. I wanted to be able to add a
combined inferior/thread display window to my GUI, and I needed a few
events to make this work. This is PR python/15622.
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
PR python/15622:
* NEWS: Add entry.
* python/python.c (do_start_initialization): Initialize new event
types.
* python/python-internal.h (gdbpy_initialize_new_inferior_event)
(gdbpy_initialize_inferior_deleted_event)
(gdbpy_initialize_new_thread_event): Declare.
* python/py-threadevent.c (create_thread_event_object): Add option
"thread" parameter.
* python/py-inferior.c (new_thread_event_object_type)
(new_inferior_event_object_type)
(inferior_deleted_event_object_type): Declare.
(python_new_inferior, python_inferior_deleted): New functions.
(add_thread_object): Emit new_thread event.
(gdbpy_initialize_inferior): Attach new functions to corresponding
observers.
(new_thread, new_inferior, inferior_deleted): Define new event
types.
* python/py-evts.c (gdbpy_initialize_py_events): Add new
registries.
* python/py-events.h (events_object) <new_inferior,
inferior_deleted, new_thread>: New fields.
* python/py-event.h (create_thread_event_breakpoint): Add optional
"thread" parameter.
doc/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* python.texi (Events In Python): Document new events.
testsuite/ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* gdb.python/py-infthread.exp: Add tests for new_thread event.
* gdb.python/py-inferior.exp: Add tests for new inferior events.
Remove code relevant for printing C/C++ Integer values in a
Fortran specific file to unify printing of Fortran values.
This does not change the output.
Printing the prefix "PTR TO -> (" resp. "REF TO ->(" ignored the active
indentation level. This caused inconsistent appearance of user-defined
Fortran types containing pointers. Fix by using "fprintfi_filtered" with the
current indentation level for outputting the prefix string. Add test case
ptr-indentation.
Example using 'ptype' on object of type:
type TypeWithPointer
integer i
integer, pointer:: p
end type TypeWithPointer
Before:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
After:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
PR gdb/22010 concerns a regression I introduced with the scalar
printing changes. The bug is that this code in sizeof.exp:
set signof_byte [get_integer_valueof "'\\377'" -1]
can incorrectly compute sizeof_byte. One underlying problem here is
that gdb's C parser doesn't treat a char constant as an int (this is
PR 19973).
However, it seems good to have an immediate fix for the regression.
The simplest is to cast to an int here.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
PR gdb/22010:
* gdb.base/sizeof.exp (check_valueof): Cast char constant to int.
Tests in gdb.arch/thumb2-it.exp call functions defined in assembly
without type debugging information. Since
7022349d5c ("Stop assuming no-debug-info
functions return int") this triggers an error which leads to many tests
to FAIL. This patch cast the call to indicate the return type of the
functions when calling them.
2017-09-06 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/testsuite/
* gdb.arch/thumb2-it.exp: Cast call to assembly defined function.
Since 2273f0ac95 ("change minsyms not to be relocated at
read-time"), printing TLS symbols of objfiles with a non-zero base
address, without debug info, fails.
E.g., with:
$ mv /usr/lib/debug /usr/lib/debug-x
to get debug info out of the way, we get:
$ echo 'int main(){}' | gcc -pthread -x c -
$ ./gdb -q -ex start -ex 'p (int) errno' ./a.out
Cannot access memory at address 0xffffef7c0698
instead of the expected:
$1 = 0
The regression is not visible with glibc debuginfo installed.
The problem is that we compute the address of TLS minsyms incorrectly.
To trigger the problem, it is important that the variable is in an
objfile with a non-zero base address. While glibc is a shared library
for 'errno', it's easier for the testcase to use PIE instead of a
shlib. For TLS variables in PT_EXEC the regression obviously does not
happen.
gdb/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* parse.c (find_minsym_type_and_address): Don't relocate addresses
of TLS symbols.
gdb/testsuite/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/tls-nodebug-pie.c: New file.
* gdb.threads/tls-nodebug-pie.exp: New file.
I noticed that the gdb.rust tests fail because the test suite passes
-fdiagnostics-color=never to rustc. This is not a recognized rustc
option, and the test suite already handles passing the appropriate
option to the Rust compiler.
This patch fixes the problem.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (gdb_compile): Don't use universal_compile_options
for rust.
Using follow-exec-mode "new" takes a different code path than "same", so
it's interesting to test this path in combination with a change in
architecture of the inferior. This test fails if you remove the
previous patch.
gdb/testsuite/ChangeLog:
* gdb.multi/multi-arch-exec.exp: Test with different
"follow-exec-mode" settings.
(do_test): New procedure.
Trying to print a function local static variable of a const-qualified
method still doesn't work after the previous fixes:
(gdb) p 'S::method() const'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) p S::method() const::static_var
No symbol "static_var" in specified context.
The reason is that the expression parser/evaluator loses the "const",
and the above unquoted case is just like trying to print a variable of
the non-const overload, if it exists, even. As if the above unquoted
case had been written as:
(gdb) p S::method()::static_var
No symbol "static_var" in specified context.
We can see the problem without static vars in the picture. With:
struct S
{
void method ();
void method () const;
};
Compare:
(gdb) print 'S::method(void) const'
$1 = {void (const S * const)} 0x400606 <S::method() const>
(gdb) print S::method(void) const
$2 = {void (S * const)} 0x4005d8 <S::method()> # wrong method!
That's what we need to fix. If we fix that, the function local static
case starts working.
The grammar production for function/method types is this one:
exp: exp '(' parameter_typelist ')' const_or_volatile
This results in a TYPE_INSTANCE expression evaluator operator. For
the example above, we get something like this ("set debug expression 1"):
...
0 TYPE_INSTANCE 1 TypeInstance: Type @0x560fda958be0 (void)
5 OP_SCOPE Type @0x560fdaa544d8 (S) Field name: `method'
...
While evaluating TYPE_INSTANCE, we end up in
value_struct_elt_for_reference, trying to find the method named
"method" that has the prototype recorded in TYPE_INSTANCE. In this
case, TYPE_INSTANCE says that we're looking for a method that has
"(void)" as parameters (that's what "1 TypeInstance: Type
@0x560fda958be0 (void)" above means. The trouble is that nowhere in
this mechanism do we communicate to value_struct_elt_for_reference
that we're looking for the _const_ overload.
value_struct_elt_for_reference only compared parameters, and the
non-const "method()" overload has matching parameters, so it's
considered the right match...
Conveniently, the "const_or_volatile" production in the grammar
already records "const" and "volatile" info in the type stack. The
type stack is not used in this code path, but we can borrow the
information. The patch converts the info in the type stack to an
"instance flags" enum, and adds that as another element in
TYPE_INSTANCE operators. This type instance flags is then applied to
the temporary type that is passed to value_struct_elt_for_reference
for matching.
The other side of the problem is that methods in the debug info aren't
marked const/volatile, so with that in place, the matching never finds
const/volatile-qualified methods.
The problem is that in the DWARF, there's no indication at all whether
a method is const/volatile qualified... For example (c++filt applied
to the linkage name for convenience):
<2><d3>: Abbrev Number: 6 (DW_TAG_subprogram)
<d4> DW_AT_external : 1
<d4> DW_AT_name : (indirect string, offset: 0x3df): method
<d8> DW_AT_decl_file : 1
<d9> DW_AT_decl_line : 58
<da> DW_AT_linkage_name: (indirect string, offset: 0x5b2): S::method() const
<de> DW_AT_declaration : 1
<de> DW_AT_object_pointer: <0xe6>
<e2> DW_AT_sibling : <0xec>
I see the same with both GCC and Clang. The patch works around this
by extracting the cv qualification from the "const" and "volatile" in
the demangled name. This will need further tweaking for "&" and
"const &" overloads, but we don't support them in the parser yet,
anyway.
The TYPE_CONST changes were necessary otherwise the comparisons in valops.c:
if (TYPE_CONST (intype) != TYPE_FN_FIELD_CONST (f, j))
continue;
would fail, because when both TYPE_CONST() TYPE_FN_FIELD_CONST() were
true, their values were different.
BTW, I'm recording the const/volatile-ness of methods in the
TYPE_FN_FIELD info because #1 - I'm not sure it's kosher to change the
method's type directly (vs having to call make_cv_type to create a new
type), and #2 it's what stabsread.c does:
...
case 'A': /* Normal functions. */
new_sublist->fn_field.is_const = 0;
new_sublist->fn_field.is_volatile = 0;
(*pp)++;
break;
case 'B': /* `const' member functions. */
new_sublist->fn_field.is_const = 1;
new_sublist->fn_field.is_volatile = 0;
...
After all this, this finally all works:
print S::method(void) const
$1 = {void (const S * const)} 0x400606 <S::method() const>
(gdb) p S::method() const::static_var
$2 = {i1 = 1, i2 = 2, i3 = 3}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* c-exp.y (function_method, function_method_void): Add current
instance flags to TYPE_INSTANCE.
* dwarf2read.c (check_modifier): New.
(compute_delayed_physnames): Assert that only C++ adds delayed
physnames. Mark fn_fields as const/volatile depending on
physname.
* eval.c (make_params): New type_instance_flags parameter. Use
it as the new type's instance flags.
(evaluate_subexp_standard) <TYPE_INSTANCE>: Extract the instance
flags element and pass it to make_params.
* expprint.c (print_subexp_standard) <TYPE_INSTANCE>: Handle
instance flags element.
(dump_subexp_body_standard) <TYPE_INSTANCE>: Likewise.
* gdbtypes.h: Include "enum-flags.h".
(type_instance_flags): New enum-flags type.
(TYPE_CONST, TYPE_VOLATILE, TYPE_RESTRICT, TYPE_ATOMIC)
(TYPE_CODE_SPACE, TYPE_DATA_SPACE): Return boolean.
* parse.c (operator_length_standard) <TYPE_INSTANCE>: Adjust.
(follow_type_instance_flags): New function.
(operator_check_standard) <TYPE_INSTANCE>: Adjust.
* parser-defs.h (follow_type_instance_flags): Declare.
* valops.c (value_struct_elt_for_reference): const/volatile must
match too.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/func-static.c (S::method const, S::method volatile)
(S::method volatile const): New methods.
(c_s, v_s, cv_s): New instances.
(main): Call method() on them.
* gdb.base/func-static.exp (syntax_re, cannot_resolve_re): New variables.
(cannot_resolve): New procedure.
(cxx_scopes_list): Test cv methods. Add print-scope-quote and
print-quote-unquoted columns.
(do_test): Test printing each scope too.
While the previous commit made "p method()::static_var" (no
single-quotes) Just Work, if users (or frontends) try wrapping the
expression with quotes, they'll get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
even if we _do_ have debug info for that variable. That's better than
the bogus/confusing value what GDB would print before the
stop-assuming-int patch:
(gdb) p 'S::method()::static_var'
$1 = 1
but I think it'd still be nice to make this case Just Work too.
In this case, due to the quoting, the C/C++ parser (c-exp.y)
interprets the whole expression/string as a single symbol name, and we
end up calling lookup_symbol on that name. There's no debug symbol
with that fully-qualified name, but since the compiler gives the
static variable a mangled linkage name exactly like the above, it
appears in the mininal symbols:
$ nm -A local-static | c++filt | grep static_var
local-static:0000000000601040 d S::method()::static_var
... and that's what GDB happens to find/print. This only happens in
C++, note, since for C the compiler uses different linkage names:
local-static-c:0000000000601040 d static_var.1848
So while (in C++, not C) function local static variables are given a
mangled name that demangles to the same syntax that GDB
documents/expects as the way to access function local statics, there's
no global symbol in the debug info with that name at all. The debug
info for a static local variable for a non-inline function looks like
this:
<1><2a1>: Abbrev Number: 19 (DW_TAG_subprogram)
...
<2><2f7>: Abbrev Number: 20 (DW_TAG_variable)
<2f8> DW_AT_name : (indirect string, offset: 0x4e9): static_var
<2fc> DW_AT_decl_file : 1
<2fd> DW_AT_decl_line : 64
<2fe> DW_AT_type : <0x25>
<302> DW_AT_location : 9 byte block: 3 40 10 60 0 0 0 0 0 (DW_OP_addr: 601040)
and for an inline function, it looks like this (linkage name run
through c++filt for convenience):
<2><21b>: Abbrev Number: 16 (DW_TAG_variable)
<21c> DW_AT_name : (indirect string, offset: 0x21a): static_var
<220> DW_AT_decl_file : 1
<221> DW_AT_decl_line : 48
<222> DW_AT_linkage_name: (indirect string, offset: 0x200): S::inline_method()::static_var
<226> DW_AT_type : <0x25>
<22a> DW_AT_external : 1
<22a> DW_AT_location : 9 byte block: 3 a0 10 60 0 0 0 0 0 (DW_OP_addr: 6010a0)
(The inline case makes the variable external so that the linker can
merge the different inlined copies. It seems like GCC never outputs
the linkage name for non-extern globals.)
When we read the DWARF, we record the static_var variable as a regular
variable of the containing function's block. This makes stopping in
the function and printing the variable as usual. The variable just so
happens to have a memory address as location.
So one way to make "p 'S::method()::static_var'" work would be to
record _two_ copies of the symbols for these variables. One in the
function's scope/block, with "static_var" as name, as we currently do,
and another in the static or global blocks (depending on whether the
symbol is external), with a fully-qualified name. I wrote a prototype
patch for that, and it works. For the non-inline case above, since
the debug info doesn't point to the linkage same, that patch built the
physname of the static local variable as the concat of the physname of
the containing function, plus "::", plus the variable's name. We
could make that approach work for C too, though it kind of feels
awkward to record fake symbol names like that in C.
The other approach I tried is to change the C++ symbol lookup routines
instead. This is the approach this commit takes. We can already
lookup up symbol in namespaces and classes, so this feels like a good
fit, and was easy enough. The advantage is that this doesn't require
recording extra symbols.
The test in gdb.cp/m-static.exp that exposed the need for this is
removed, since the same functionality is now covered by
gdb.cp/local-static.exp.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* cp-namespace.c (cp_search_static_and_baseclasses): Handle
function/method scopes; lookup the nested name as a function local
static variable.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.exp: Also test with
class::method::variable wholly quoted.
* gdb.cp/m-static.exp (class::method::variable): Remove test.
This commit makes "print S::method()::static_var" actually find the
debug symbol for static_var. Currently, you get:
(gdb) print S::method()::static_var
A syntax error in expression, near `'.
Quoting the whole string would seemingly work before the previous
patch that made GDB stop assuming int for no-debug-info variables:
(gdb) p 'S::method()::static_var'
$1 = 1
... except that's incorrect output, because:
(gdb) ptype 'S::method()::static_var'
type = <data variable, no debug info>
The way to make it work correctly currently is by quoting the
function/method part, like this:
(gdb) print 'S::method()'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype 'S::method()'::static_var
type = struct aggregate {
int i1;
int i2;
int i3;
}
At least after the "stop assuming int" patch, this is what we
now get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
(gdb) p (struct aggregate) 'S::method()::static_var'
$1 = {i1 = 1, i2 = 2, i3 = 3}
However, IMO, users shouldn't really have to care about any of this.
GDB should Just Work, without quoting, IMO.
So here's a patch that implements support for that in the C++ parser.
With this patch, you now get:
(gdb) p S::method()::S_M_s_var_aggregate
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype S::method()::S_M_s_var_aggregate
type = struct aggregate {
int i1;
int i2;
int i3;
}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
(%type <voidval>): Add function_method.
* c-exp.y (exp): New production for calls with no arguments.
(function_method, function_method_void_or_typelist): New
productions.
(exp): New production for "method()::static_var".
* eval.c (evaluate_subexp_standard): Handle OP_FUNC_STATIC_VAR.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Handle OP_FUNC_STATIC_VAR.
* parse.c (operator_length_standard):
Handle OP_FUNC_STATIC_VAR.
* std-operator.def (OP_FUNC_STATIC_VAR): New.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.c: New.
* gdb.base/local-static.cc: New.
* gdb.base/local-static.exp: New.
An earlier commit made GDB no longer assume no-debug-info functions
return int. This commit gives the same treatment to variables.
Currently, you can end misled by GDB over output like this:
(gdb) p var
$1 = -1
(gdb) p /x var
$2 = 0xffffffff
until you realize that GDB is assuming that the variable is an "int",
because:
(gdb) ptype var
type = <data variable, no debug info>
You may try to fix it by casting, but that doesn't really help:
(gdb) p /x (unsigned long long) var
$3 = 0xffffffffffffffff # incorrect
^^
That's incorrect output, because the variable was defined like this:
uint64_t var = 0x7fffffffffffffff;
^^
What happened is that with the cast, GDB did an int -> 'unsigned long
long' conversion instead of reinterpreting the variable as the cast-to
type. To get at the variable properly you have to reinterpret the
variable's address manually instead, with either:
(gdb) p /x *(unsigned long long *) &var
$4 = 0x7fffffffffffffff
(gdb) p /x {unsigned long long} &var
$5 = 0x7fffffffffffffff
After this commit GDB does it for you. This is what you'll get
instead:
(gdb) p var
'var' has unknown type; cast it to its declared type
(gdb) p /x (unsigned long long) var
$1 = 0x7fffffffffffffff
As in the functions patch, the "compile" machinery doesn't currently
have the cast-to type handy, so it continues assuming no-debug
variables have int type, though now at least it warns.
The change to gdb.cp/m-static.exp deserves an explanation:
- gdb_test "print 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
+ gdb_test "print (int) 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
That's printing the "sintvar" function local static of the
"gnu_obj_1::method()" method.
The problem with that test is that that "'S::method()::static_var'"
syntax doesn't really work in C++ as you'd expect. The way to make it
work correctly currently is to quote the method part, not the whole
expression, like:
(gdb) print 'gnu_obj_1::method()'::sintvar
If you wrap the whole expression in quotes, like in m-static.exp, what
really happens is that the parser considers the whole string as a
symbol name, but there's no debug symbol with that name. However,
local statics have linkage and are given a mangled name that demangles
to the same string as the full expression, so that's what GDB prints.
After this commit, and without the cast, the print in m-static.exp
would error out saying that the variable has unknown type:
(gdb) p 'gnu_obj_1::method()::sintvar'
'gnu_obj_1::method()::sintvar' has unknown type; cast it to its declared type
TBC, if currently (even before this series) you try to print any
function local static variable of type other than int, you'll get
bogus results. You can see that with m-static.cc as is, even.
Printing the "svar" local, which is a boolean (1 byte) still prints as
"int" (4 bytes):
(gdb) p 'gnu_obj_1::method()::svar'
$1 = 1
(gdb) ptype 'gnu_obj_1::method()::svar'
type = <data variable, no debug info>
This probably prints some random bogus value on big endian machines.
If 'svar' was of some aggregate type (etc.) we'd still print it as
int, so the problem would have been more obvious... After this
commit, you'll get instead:
(gdb) p 'gnu_obj_1::method()::svar'
'gnu_obj_1::method()::svar' has unknown type; cast it to its declared type
... so at least GDB is no longer misleading. Making GDB find the real
local static debug symbol is the subject of the following patches. In
the end, it'll all "Just Work".
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ax-gdb.c: Include "typeprint.h".
(gen_expr_for_cast): New function.
(gen_expr) <OP_CAST, OP_CAST_TYPE>: Use it.
<OP_VAR_VALUE, OP_MSYM_VAR_VALUE>: Error out if the variable's
type is unknown.
* dwarf2read.c (new_symbol_full): Fallback to int instead of
nodebug_data_symbol.
* eval.c: Include "typeprint.h".
(evaluate_subexp_standard) <OP_VAR_VALUE, OP_VAR_MSYM_VALUE>:
Error out if symbol has unknown type.
<UNOP_CAST, UNOP_CAST_TYPE>: Common bits factored out to
evaluate_subexp_for_cast.
(evaluate_subexp_for_address, evaluate_subexp_for_sizeof): Handle
OP_VAR_MSYM_VALUE.
(evaluate_subexp_for_cast): New function.
* gdbtypes.c (init_nodebug_var_type): New function.
(objfile_type): Use it to initialize types of variables with no
debug info.
* typeprint.c (error_unknown_type): New.
* typeprint.h (error_unknown_type): New declaration.
* compile/compile-c-types.c (convert_type_basic): Handle
TYPE_CODE_ERROR; warn and fallback to int for variables with
unknown type.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.asm/asm-source.exp: Add casts to int.
* gdb.base/nodebug.c (dataglobal8, dataglobal32_1, dataglobal32_2)
(dataglobal64_1, dataglobal64_2): New globals.
* gdb.base/nodebug.exp: Test different expressions involving the
new globals, with print, whatis and ptype. Add casts to int.
* gdb.base/solib-display.exp: Add casts to int.
* gdb.compile/compile-ifunc.exp: Expect warning. Add cast to int.
* gdb.cp/m-static.exp: Add cast to int.
* gdb.dwarf2/dw2-skip-prologue.exp: Add cast to int.
* gdb.threads/tls-nodebug.exp: Check that gdb errors out printing
tls variable with no debug info without a cast. Test with a cast
to int too.
* gdb.trace/entry-values.exp: Add casts.
The patch to make GDB stop assuming functions return int left GDB with
an inconsistency. While with normal expression evaluation the
"unknown return type" error shows the name of the function that misses
debug info:
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
^^^^^^
which is handy in more complicated expressions, "ptype" does not:
(gdb) ptype getenv ("PATH")
function has unknown return type; cast the call to its declared return type
^^^^^^^^
This commit builds on the new OP_VAR_MSYM_VALUE to fix it, by making
OP_FUNCALL extract the function name from the symbol stored in
OP_VAR_VALUE/OP_VAR_MSYM_VALUE. We now get the same error in "print"
vs "ptype":
(gdb) ptype getenv()
'getenv' has unknown return type; cast the call to its declared return type
(gdb) p getenv()
'getenv' has unknown return type; cast the call to its declared return type
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_subexp_standard): <OP_FUNCALL>: Extract
function name from symbol/minsym and pass it to
error_call_unknown_return_type.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/nodebug.exp: Test that ptype's error about functions
with unknown return type includes the function name too.
The fact that GDB defaults to assuming that functions return int, when
it has no debug info for the function has been a recurring source of
user confusion. Recently this came up on the errno pretty printer
discussions. Shortly after, it came up again on IRC, with someone
wondering why does getenv() in GDB return a negative int:
(gdb) p getenv("PATH")
$1 = -6185
This question (with s/getenv/random-other-C-runtime-function) is a FAQ
on IRC.
The reason for the above is:
(gdb) p getenv
$2 = {<text variable, no debug info>} 0x7ffff7751d80 <getenv>
(gdb) ptype getenv
type = int ()
... which means that GDB truncated the 64-bit pointer that is actually
returned from getent to 32-bit, and then sign-extended it:
(gdb) p /x -6185
$6 = 0xffffe7d7
The workaround is to cast the function to the right type, like:
(gdb) p ((char *(*) (const char *)) getenv) ("PATH")
$3 = 0x7fffffffe7d7 "/usr/local/bin:/"...
IMO, we should do better than this.
I see the "assume-int" issue the same way I see printing bogus values
for optimized-out variables instead of "<optimized out>" -- I'd much
rather that the debugger tells me "I don't know" and tells me how to
fix it than showing me bogus misleading results, making me go around
tilting at windmills.
If GDB prints a signed integer when you're expecting a pointer or
aggregate, you at least have some sense that something is off, but
consider the case of the function actually returning a 64-bit integer.
For example, compile this without debug info:
unsigned long long
function ()
{
return 0x7fffffffffffffff;
}
Currently, with pristine GDB, you get:
(gdb) p function ()
$1 = -1 # incorrect
(gdb) p /x function ()
$2 = 0xffffffff # incorrect
maybe after spending a few hours debugging you suspect something is
wrong with that -1, and do:
(gdb) ptype function
type = int ()
and maybe, just maybe, you realize that the function actually returns
unsigned long long. And you try to fix it with:
(gdb) p /x (unsigned long long) function ()
$3 = 0xffffffffffffffff # incorrect
... which still produces the wrong result, because GDB simply applied
int to unsigned long long conversion. Meaning, it sign-extended the
integer that it extracted from the return of the function, to 64-bits.
and then maybe, after asking around on IRC, you realize you have to
cast the function to a pointer of the right type, and call that. It
won't be easy, but after a few missteps, you'll get to it:
..... (gdb) p /x ((unsigned long long(*) ()) function) ()
$666 = 0x7fffffffffffffff # finally! :-)
So to improve on the user experience, this patch does the following
(interrelated) things:
- makes no-debug-info functions no longer default to "int" as return
type. Instead, they're left with NULL/"<unknown return type>"
return type.
(gdb) ptype getenv
type = <unknown return type> ()
- makes calling a function with unknown return type an error.
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
- and then to make it easier to call the function, makes it possible
to _only_ cast the return of the function to the right type,
instead of having to cast the function to a function pointer:
(gdb) p (char *) getenv ("PATH") # now Just Works
$3 = 0x7fffffffe7d7 "/usr/local/bin:/"...
(gdb) p ((char *(*) (const char *)) getenv) ("PATH") # continues working
$4 = 0x7fffffffe7d7 "/usr/local/bin:/"...
I.e., it makes GDB default the function's return type to the type
of the cast, and the function's parameters to the type of the
arguments passed down.
After this patch, here's what you'll get for the "unsigned long long"
example above:
(gdb) p function ()
'function' has unknown return type; cast the call to its declared return type
(gdb) p /x (unsigned long long) function ()
$4 = 0x7fffffffffffffff # correct!
Note that while with "print" GDB shows the name of the function that
has the problem:
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
which can by handy in more complicated expressions, "ptype" does not:
(gdb) ptype getenv ("PATH")
function has unknown return type; cast the call to its declared return type
This will be fixed in the next patch.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_evaluate_subexp) <TYPE_CODE_FUNC>: Don't handle
TYPE_GNU_IFUNC specially here. Throw error if return type is
unknown.
* ada-typeprint.c (print_func_type): Handle functions with unknown
return type.
* c-typeprint.c (c_type_print_base): Handle functions and methods
with unknown return type.
* compile/compile-c-symbols.c (convert_symbol_bmsym)
<mst_text_gnu_ifunc>: Use nodebug_text_gnu_ifunc_symbol.
* compile/compile-c-types.c: Include "objfiles.h".
(convert_func): For functions with unknown return type, warn and
default to int.
* compile/compile-object-run.c (compile_object_run): Adjust call
to call_function_by_hand_dummy.
* elfread.c (elf_gnu_ifunc_resolve_addr): Adjust call to
call_function_by_hand.
* eval.c (evaluate_subexp_standard): Adjust calls to
call_function_by_hand. Handle functions and methods with unknown
return type. Pass expect_type to call_function_by_hand.
* f-typeprint.c (f_type_print_base): Handle functions with unknown
return type.
* gcore.c (call_target_sbrk): Adjust call to
call_function_by_hand.
* gdbtypes.c (objfile_type): Leave nodebug text symbol with NULL
return type instead of int. Make nodebug_text_gnu_ifunc_symbol be
an integer address type instead of nodebug.
* guile/scm-value.c (gdbscm_value_call): Adjust call to
call_function_by_hand.
* infcall.c (error_call_unknown_return_type): New function.
(call_function_by_hand): New "default_return_type" parameter.
Pass it down.
(call_function_by_hand_dummy): New "default_return_type"
parameter. Use it instead of defaulting to int. If there's no
default and the return type is unknown, throw an error. If
there's a default return type, and the called function has no
debug info, then assume the function is prototyped.
* infcall.h (call_function_by_hand, call_function_by_hand_dummy):
New "default_return_type" parameter.
(error_call_unknown_return_type): New declaration.
* linux-fork.c (call_lseek): Cast return type of lseek.
(inferior_call_waitpid, checkpoint_command): Adjust calls to
call_function_by_hand.
* linux-tdep.c (linux_infcall_mmap, linux_infcall_munmap): Adjust
calls to call_function_by_hand.
* m2-typeprint.c (m2_procedure): Handle functions with unknown
return type.
* objc-lang.c (lookup_objc_class, lookup_child_selector)
(value_nsstring, print_object_command): Adjust calls to
call_function_by_hand.
* p-typeprint.c (pascal_type_print_varspec_prefix): Handle
functions with unknown return type.
(pascal_type_print_func_varspec_suffix): New function.
(pascal_type_print_varspec_suffix) <TYPE_CODE_FUNC,
TYPE_CODE_METHOD>: Use it.
* python/py-value.c (valpy_call): Adjust call to
call_function_by_hand.
* rust-lang.c (rust_evaluate_funcall): Adjust call to
call_function_by_hand.
* valarith.c (value_x_binop, value_x_unop): Adjust calls to
call_function_by_hand.
* valops.c (value_allocate_space_in_inferior): Adjust call to
call_function_by_hand.
* typeprint.c (type_print_unknown_return_type): New function.
* typeprint.h (type_print_unknown_return_type): New declaration.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/break-main-file-remove-fail.exp (test_remove_bp): Cast
return type of munmap in infcall.
* gdb.base/break-probes.exp: Cast return type of foo in infcall.
* gdb.base/checkpoint.exp: Simplify using for loop. Cast return
type of ftell in infcall.
* gdb.base/dprintf-detach.exp (dprintf_detach_test): Cast return
type of getpid in infcall.
* gdb.base/infcall-exec.exp: Cast return type of execlp in
infcall.
* gdb.base/info-os.exp: Cast return type of getpid in infcall.
Bail on failure to extract the pid.
* gdb.base/nodebug.c: #include <stdint.h>.
(multf, multf_noproto, mult, mult_noproto, add8, add8_noproto):
New functions.
* gdb.base/nodebug.exp (test_call_promotion): New procedure.
Change expected output of print/whatis/ptype with functions with
no debug info. Test all supported languages. Call
test_call_promotion.
* gdb.compile/compile.exp: Adjust expected output to expect
warning.
* gdb.threads/siginfo-threads.exp: Likewise.
Calling a prototyped function via a function pointer with the right
prototype doesn't work correctly, if the called function requires
argument coercion... Like, e.g., with:
float mult (float f1, float f2) { return f1 * f2; }
(gdb) p mult (2, 3.5)
$1 = 7
(gdb) p ((float (*) (float, float)) mult) (2, 3.5)
$2 = 0
both calls should have returned the same, of course. The problem is
that GDB misses marking the type of the function pointer target as
prototyped...
Without the fix, the new test fails like this:
(gdb) p ((int (*) (float, float)) t_float_values2)(3.14159,float_val2)
$30 = 0
(gdb) FAIL: gdb.base/callfuncs.exp: p ((int (*) (float, float)) t_float_values2)(3.14159,float_val2)
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdbtypes.c (lookup_function_type_with_arguments): Mark function
types with more than one parameter as prototyped.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/callfuncs.exp (do_function_calls): New parameter
"prototypes". Test calling float functions via prototyped and
unprototyped function pointers.
(perform_all_tests): New parameter "prototypes". Pass it down.
(top level): Pass down "prototypes" parameter to
perform_all_tests.
This patch improves the loop_break and loop_continue tests to verify
that they work as expected when multiple loops are nested (they affect
the inner loop).
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (loop_break_test, loop_continue_test):
Test with nested loops.
I grepped the testsuite for loop_break and loop_continue and didn't find
anything, so I wrote some simple tests for those.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Call the new procedures.
(loop_break_test, loop_continue_test): New procedures.
When using "if" (or while) without args directly on gdb's command line,
you get this:
(gdb) if
if/while commands require arguments
When doing the same when entering a command list, you only get an error
when the command is executed, when parse_exp_in_context_1 fails to
evaluate the expression.
(gdb) define foo
Type commands for definition of "foo".
End with a line saying just "end".
>if
>end
>end
(gdb) foo
Argument required (expression to compute).
I think it would make more sense to error out when inputting the command
list directly:
(gdb) define foo
Type commands for definition of "foo".
End with a line saying just "end".
>if
if/while commands require arguments.
The only required change is to check whether args is an empty string in
build_command_line.
gdb/ChangeLog:
* cli/cli-script.c (build_command_line): For if/while commands,
check whether args is empty.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Call new procedure.
(define_if_without_arg_test): New procedure.
Currently, with "list LINESPEC1,LINESPEC2", if one of the linespecs is
ambiguous, i.e., if it expands to multiple locations, you get this
seemingly odd output:
(gdb) list foo,bar
file: "file0.c", line number: 26
file: "file1.c", line number: 29
Since "foo" above expands to multiple locations, the specified range
is indeterminate, and GDB is trying to be helpful by showing you what
was ambiguous. It looks confusing to me, though. I think it'd be
much more user friendly if GDB actually told you that, like this:
(gdb) list foo,bar
Specified first line 'foo' is ambiguous:
file: "file0.c", line number: 26
file: "file1.c", line number: 29
(gdb) list bar,foo
Specified last line 'foo' is ambiguous:
file: "file0.c", line number: 26
file: "file1.c", line number: 29
Note, I'm using "first" and "last" in the output because that's what
the manual uses:
~~~
list first,last
Print lines from first to last. [...]
~~~
Tested on x86-64 GNU/Linux.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (edit_command): Pass message to
ambiguous_line_spec.
(list_command): Pass message to ambiguous_line_spec. Say
"first"/"last" instead of "start" and "end" to be consistent with
the manual.
(ambiguous_line_spec): Add 'format' and vararg parameters. Use
them to print formatted message.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/list-ambiguous.exp: New file.
* gdb.base/list-ambiguous0.c: New file.
* gdb.base/list-ambiguous1.c: New file.
* gdb.base/list.exp (test_list_range): Adjust expected output.
This patch implements the ability to set/unset environment variables
on the remote target, mimicking what GDB already offers to the user.
There are two features present here: user-set and user-unset
environment variables.
User-set environment variables are only the variables that are
explicitly set by the user, using the 'set environment' command. This
means that variables that were already present in the environment when
starting GDB/GDBserver are not transmitted/considered by this feature.
User-unset environment variables are variables that are explicitly
unset by the user, using the 'unset environment' command.
The idea behind this patch is to store user-set and user-unset
environment variables in two separate sets, both part of gdb_environ.
Then, when extended_remote_create_inferior is preparing to start the
inferior, it will iterate over the two sets and set/unset variables
accordingly. Three new packets are introduced:
- QEnvironmentHexEncoded, which is used to set environment variables,
and contains an hex-encoded string in the format "VAR=VALUE" (VALUE
can be empty if the user set a variable with a null value, by doing
'set environment VAR=').
- QEnvironmentUnset, which is used to unset environment variables, and
contains an hex-encoded string in the format "VAR".
- QEnvironmentReset, which is always the first packet to be
transmitted, and is used to reset the environment, i.e., discard any
changes made by the user on previous runs.
The QEnvironmentHexEncoded packet is inspired on LLDB's extensions to
the RSP. Details about it can be seen here:
<https://raw.githubusercontent.com/llvm-mirror/lldb/master/docs/lldb-gdb-remote.txt>
I decided not to implement the QEnvironment packet because it is
considered deprecated by LLDB. This packet, on LLDB, serves the same
purpose of QEnvironmentHexEncoded, but sends the information using a
plain text, non-hex-encoded string.
The other two packets are new.
This patch also includes updates to the documentation, testsuite, and
unit tests, without introducing regressions.
gdb/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS (Changes since GDB 8.0): Add entry mentioning new support
for setting/unsetting environment variables on the remote target.
(New remote packets): Add entries for QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset.
* common/environ.c (gdb_environ::operator=): Extend method to
handle m_user_set_env_list and m_user_unset_env_list.
(gdb_environ::clear): Likewise.
(match_var_in_string): Change type of first parameter from 'char
*' to 'const char *'.
(gdb_environ::set): Extend method to handle
m_user_set_env_list and m_user_unset_env_list.
(gdb_environ::unset): Likewise.
(gdb_environ::clear_user_set_env): New method.
(gdb_environ::user_set_envp): Likewise.
(gdb_environ::user_unset_envp): Likewise.
* common/environ.h (gdb_environ): Handle m_user_set_env_list and
m_user_unset_env_list on move constructor/assignment.
(unset): Add new default parameter 'update_unset_list = true'.
(clear_user_set_env): New method.
(user_set_envp): Likewise.
(user_unset_envp): Likewise.
(m_user_set_env_list): New std::set.
(m_user_unset_env_list): Likewise.
* common/rsp-low.c (hex2str): New function.
(bin2hex): New overload for bin2hex function.
* common/rsp-low.c (hex2str): New prototype.
(str2hex): New overload prototype.
* remote.c: Include "environ.h". Add QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset.
(remote_protocol_features): Add QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset packets.
(send_environment_packet): New function.
(extended_remote_environment_support): Likewise.
(extended_remote_create_inferior): Call
extended_remote_environment_support.
(_initialize_remote): Add QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset packet configs.
* unittests/environ-selftests.c (gdb_selftest_env_var):
New variable.
(test_vector_initialization): New function.
(test_init_from_host_environ): Likewise.
(test_reinit_from_host_environ): Likewise.
(test_set_A_unset_B_unset_A_cannot_find_A_can_find_B):
Likewise.
(test_unset_set_empty_vector): Likewise.
(test_vector_clear): Likewise.
(test_std_move): Likewise.
(test_move_constructor):
(test_self_move): Likewise.
(test_set_unset_reset): Likewise.
(run_tests): Rewrite in terms of the functions above.
gdb/gdbserver/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c (handle_general_set): Handle QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset packets.
(handle_query): Inform remote that QEnvironmentHexEncoded,
QEnvironmentUnset and QEnvironmentReset are supported.
gdb/doc/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (set environment): Add @anchor. Explain that
environment variables set by the user are sent to GDBserver.
(unset environment): Likewise, but for unsetting variables.
(Connecting) <Remote Packet>: Add "environment-hex-encoded",
"QEnvironmentHexEncoded", "environment-unset", "QEnvironmentUnset",
"environment-reset" and "QEnvironmentReset" to the table.
(Remote Protocol) <QEnvironmentHexEncoded, QEnvironmentUnset,
QEnvironmentReset>: New item, explaining the packet.
gdb/testsuite/ChangeLog:
2017-08-31 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/share-env-with-gdbserver.c: New file.
* gdb.base/share-env-with-gdbserver.exp: Likewise.
Commit
Command names: make them case sensitive
3d7b173c29
made command name lookup case sensitive. However, define_command, used
when creating a user-defined command, converts the command name to
lowercase, assuming that the command name lookup works in a case
insensitive way. This causes user-defined commands with capital letters
in their name to only be callable with a lowercase version:
(gdb) define Foo
Type commands for definition of "Foo".
End with a line saying just "end".
>print 1
>end
(gdb) Foo
Undefined command: "Foo". Try "help".
(gdb) foo
$1 = 1
This patch removes that conversion to lowercase, so that the user can
call the command with the same name they provided.
gdb/ChangeLog:
* cli/cli-script.c (define_command): Don't convert command name
to lower case.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (user_defined_command_case_sensitivity):
New proc, call it from toplevel.
There is an assertion that is triggering when we start GDB and
instruct it to debug a remote inferior, but don't provide a local
binary, like:
./gdb -nx -q --data-directory=data-directory -ex "tar ext :1234" \
-ex "set remote exec-file /bin/ls" -ex r
In this case, when calling exec_file_locate_attach to locate the
inferior, GDB is incorrectly resetting the breakpoints without a
thread/inferior even running, which causes an assertion to be
triggered:
binutils-gdb/gdb/thread.c:1609: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This happens because add_current_inferior_and_thread (on remote.c) is
breaking an invariant: making inferior_ptid point to a non-existing
thread and then calling common code, which in this case is
breakpoint_re_set. The fix is to make sure that inferior_ptid points
to null_ptid if there is no thread present.
A testcase is provided. Regtested on buildbot.
gdb/ChangeLog:
2017-08-23 Pedro Alves <palves@redhat.com>
PR remote/21852
* remote.c (add_current_inferior_and_thread): Set inferior_ptid
to null_ptid and switch to thread without reading the registers
after adding the inferior.
gdb/testsuite/ChangeLog:
2017-08-23 Sergio Durigan Junior <sergiodj@redhat.com>
PR remote/21852
* gdb.server/normal.c: New file, copied from gdb.base.
* gdb.server/run-without-local-binary.exp: New file.
The M7 processor supports an Application Data Integrity (ADI) feature
that detects invalid data accesses. When software allocates data, it
chooses a 4-bit version number, sets the version in the upper 4 bits
of the 64-bit pointer to that data, and stores the 4-bit version in
every cacheline of the object. Hardware saves the latter in spare
bits in the cache and memory hierarchy. On each load and store, the
processor compares the upper 4 VA (virtual address) bits to the
cacheline's version. If there is a mismatch, the processor generates a
version mismatch trap which can be either precise or disrupting. The
trap is an error condition which the kernel delivers to the process as
a SIGSEGV signal.
The upper 4 bits of the VA represent a version and are not part of the
true address. The processor clears these bits and sign extends bit 59
to generate the true address.
Note that 32-bit applications cannot use ADI.
This patch adds ADI support in gdb which allows the user to examine
current version tags and assign new version tags in the program. It
also catches and reports precise or disrupting memory corruption
traps.
gdb/ChangeLog:
2017-08-07 Weimin Pan <weimin.pan@oracle.com>
* sparc64-tdep.h: (adi_normalize_address): New export.
* sparc-nat.h: (open_adi_tag_fd): New export.
* sparc64-linux-nat.c: (open_adi_tag_fd): New function.
* sparc64-linux-tdep.c:
(SEGV_ACCADI, SEGV_ADIDERR, SEGV_ADIPERR) New defines.
(sparc64_linux_handle_segmentation_fault): New function.
(sparc64_linux_init_abi): Register
sparc64_linux_handle_segmentation_fault
* sparc64-tdep.c: Include cli-utils.h,gdbcmd.h,auxv.h.
(sparc64_addr_bits_remove): New function.
(sparc64_init_abi): Register sparc64_addr_bits_remove.
(MAX_PROC_NAME_SIZE): New macro.
(AT_ADI_BLKSZ, AT_ADI_NBITS, AT_ADI_UEONADI) New defines.
(sparc64adilist): New variable.
(adi_proc_list): New variable.
(find_adi_info): New function.
(add_adi_info): New function.
(get_adi_info_proc): New function.
(get_adi_info): New function.
(info_adi_command): New function.
(read_maps_entry): New function.
(adi_available): New function.
(adi_normalize_address): New function.
(adi_align_address): New function.
(adi_convert_byte_count): New function.
(adi_tag_fd): New function.
(adi_is_addr_mapped): New function.
(adi_read_versions): New function.
(adi_write_versions): New function.
(adi_print_versions): New function.
(do_examine): New function.
(do_assign): New function.
(adi_examine_command): New function.
(adi_assign_command): New function.
(_initialize_sparc64_adi_tdep): New function.
gdb/doc/ChangeLog:
2017-08-07 Weimin Pan <weimin.pan@oracle.com>
* gdb.texinfo (Architectures): Add new Sparc64 section to document
ADI support.
* NEWS: Add "adi examine" and "adi assign" commands.
gdb/testsuite/ChangeLog:
2017-08-07 Weimin Pan <weimin.pan@oracle.com>
* gdb.arch/sparc64-adi.exp: New file.
* gdb.arch/sparc64-adi.c: New file.
This adds a test for the "list" command change done in 0d999a6ef0
("List actual code around more than one location").
gdb/ChangeLog:
2017-08-22 Pedro Alves <palves@redhat.com>
* gdb.cp/overload.exp (line_range_pattern): New procedure.
(top level): Add "list all overloads" tests.
This changes gdb_realpath to return a unique_xmalloc_ptr and fixes up
the callers. This allows removing some cleanups. This change by
itself caused xfullpath.exp to fail; and attempting to fix that ran
into various problems (like .get() being optimized out); so this patch
also rewrites xfullpath.exp to be a C++ selftest instead.
ChangeLog
2017-08-22 Tom Tromey <tom@tromey.com>
* exec.c (exec_file_attach): Update.
* linux-thread-db.c (try_thread_db_load): Update.
* guile/scm-safe-call.c (gdbscm_safe_source_script): Update.
* utils.c (gdb_realpath): Change return type.
(gdb_realpath_keepfile): Update.
(gdb_realpath_check_trailer, gdb_realpath_tests): New functions.
(_initialize_utils): Register the new self test.
* source.c (openp): Update.
(find_and_open_source): Update.
* nto-tdep.c (nto_find_and_open_solib): Update.
* main.c (set_gdb_data_directory): Update.
(captured_main_1): Update.
* dwarf2read.c (dwarf2_get_dwz_file): Update
(dw2_map_symbol_filenames): Update.
* auto-load.c (auto_load_safe_path_vec_update): Update.
(filename_is_in_auto_load_safe_path_vec): Change type of
"filename_realp".
(auto_load_objfile_script): Update.
(file_is_auto_load_safe): Update. Use std::string.
* utils.h (gdb_realpath): Return a gdb::unique_xmalloc_ptr.
testsuite/ChangeLog
2017-08-22 Tom Tromey <tom@tromey.com>
* gdb.gdb/xfullpath.exp: Remove.
(Ref: https://sourceware.org/ml/gdb/2017-06/msg00048.html)
This patch improves GDB support for function aliases defined with
__attribute__ alias. For example, in the test added by this commit,
there is no reference to "func_alias" in the debug info at all, only
to "func"'s definition:
$ nm ./testsuite/outputs/gdb.base/symbol-alias/symbol-alias | grep " func"
00000000004005ae t func
00000000004005ae T func_alias
$ readelf -w ./testsuite/outputs/gdb.base/symbol-alias/symbol-alias | grep func -B 1 -A 8
<1><db>: Abbrev Number: 5 (DW_TAG_subprogram)
<dc> DW_AT_name : (indirect string, offset: 0x111): func
<e0> DW_AT_decl_file : 1
<e1> DW_AT_decl_line : 27
<e2> DW_AT_prototyped : 1
<e2> DW_AT_type : <0xf8>
<e6> DW_AT_low_pc : 0x4005ae
<ee> DW_AT_high_pc : 0xb
<f6> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<f8> DW_AT_GNU_all_call_sites: 1
So all GDB knows about "func_alias" is from the minsym (elf symbol):
(gdb) p func_alias
$1 = {<text variable, no debug info>} 0x4005ae <func>
(gdb) ptype func_alias
type = int ()
(gdb) p func
$2 = {struct S *(void)} 0x4005ae <func>
(gdb) ptype func
type = struct S {
int field1;
int field2;
} *(void)
The result is that calling func_alias from the command line produces
incorrect results.
This is similar (though not exactly the same) to the glibc
errno/__errno_location/__GI___errno_location situation. On glibc,
errno is defined like this:
extern int *__errno_location (void);
#define errno (*__errno_location ())
with __GI___errno_location being an internal alias for
__errno_location. On my system's libc (F23), I do see debug info for
__errno_location, in the form of name vs linkage name:
<1><95a5>: Abbrev Number: 18 (DW_TAG_subprogram)
<95a6> DW_AT_external : 1
<95a6> DW_AT_name : (indirect string, offset: 0x2c26): __errno_location
<95aa> DW_AT_decl_file : 1
<95ab> DW_AT_decl_line : 24
<95ac> DW_AT_linkage_name: (indirect string, offset: 0x2c21): __GI___errno_location
<95b0> DW_AT_prototyped : 1
<95b0> DW_AT_type : <0x9206>
<95b4> DW_AT_low_pc : 0x20f40
<95bc> DW_AT_high_pc : 0x11
<95c4> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<95c6> DW_AT_GNU_all_call_sites: 1
however that doesn't matter in practice, because GDB doesn't record
demangled names anyway, and so we end up with the exact same situation
covered by the testcase.
So the fix is to make the expression parser find a debug symbol for
the same address as the just-found minsym, when a lookup by name
didn't find a debug symbol by name. We now get:
(gdb) p func_alias
$1 = {struct S *(void)} 0x4005ae <func>
(gdb) p __errno_location
$2 = {int *(void)} 0x7ffff6e92830 <__errno_location>
I've made the test exercise variable aliases too, for completeness.
Those already work correctly, because unlike for function aliases, GCC
emits debug information for variable aliases.
Tested on GNU/Linux.
gdb/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
PR gdb/19487
* c-exp.y (variable production): Handle function aliases.
* minsyms.c (msymbol_is_text): New function.
* minsyms.h (msymbol_is_text): Declare.
* symtab.c (find_function_alias_target): New function.
* symtab.h (find_function_alias_target): Declare.
gdb/testsuite/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
PR gdb/19487
* gdb.base/symbol-alias.c: New.
* gdb.base/symbol-alias2.c: New.
* gdb.base/symbol-alias.exp: New.
(Ref: https://sourceware.org/ml/gdb/2017-06/msg00020.html)
Assuming int_t is a typedef to int:
typedef int int_t;
gdb currently loses this expression's typedef:
(gdb) p (int_t) 0
$1 = 0
(gdb) whatis $1
type = int
or:
(gdb) whatis (int_t) 0
type = int
or, to get "whatis" out of the way:
(gdb) maint print type (int_t) 0
...
name 'int'
code 0x8 (TYPE_CODE_INT)
...
This prevents a type printer for "int_t" kicking in, with e.g.:
(gdb) p (int_t) 0
From the manual, we can see that that "whatis (int_t) 0" command
invocation should have printed "type = int_t":
If @var{arg} is a variable or an expression, @code{whatis} prints its
literal type as it is used in the source code. If the type was
defined using a @code{typedef}, @code{whatis} will @emph{not} print
the data type underlying the @code{typedef}.
(...)
If @var{arg} is a type name that was defined using @code{typedef},
@code{whatis} @dfn{unrolls} only one level of that @code{typedef}.
That one-level stripping is currently done here, in
gdb/eval.c:evaluate_subexp_standard, handling OP_TYPE:
...
else if (noside == EVAL_AVOID_SIDE_EFFECTS)
{
struct type *type = exp->elts[pc + 1].type;
/* If this is a typedef, then find its immediate target. We
use check_typedef to resolve stubs, but we ignore its
result because we do not want to dig past all
typedefs. */
check_typedef (type);
if (TYPE_CODE (type) == TYPE_CODE_TYPEDEF)
type = TYPE_TARGET_TYPE (type);
return allocate_value (type);
}
However, this stripping is reachable in both:
#1 - (gdb) whatis (int_t)0 # ARG is an expression with a cast to
# typedef type.
#2 - (gdb) whatis int_t # ARG is a type name.
while only case #2 should strip the typedef. Removing that code from
evaluate_subexp_standard is part of the fix. Instead, we make the
"whatis" command implementation itself strip one level of typedefs
when the command argument is a type name.
We then run into another problem, also fixed by this commit:
value_cast always drops any typedefs of the destination type.
With all that fixed, "whatis (int_t) 0" now works as expected:
(gdb) whatis int_t
type = int
(gdb) whatis (int_t)0
type = int_t
value_cast has many different exit/convertion paths, for handling many
different kinds of casts/conversions, and most of them had to be
tweaked to construct the value of the right "to" type. The new tests
try to exercise most of it, by trying castin of many different
combinations of types. With:
$ make check TESTS="*/whatis-ptype*.exp */gnu_vector.exp */dfp-test.exp"
... due to combinatorial explosion, the testsuite results for the
tests above alone grow like:
- # of expected passes 246
+ # of expected passes 3811
You'll note that the tests exposed one GCC buglet, filed here:
Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81267
gdb/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
* eval.c (evaluate_subexp_standard) <OP_TYPE>: Don't dig past
typedefs.
* typeprint.c (whatis_exp): If handling "whatis", and expression
is OP_TYPE, strip one typedef level. Otherwise don't strip
typedefs here.
* valops.c (value_cast): Save "to" type before resolving
stubs/typedefs. Use that type as resulting value's type.
gdb/testsuite/ChangeLog:
2017-08-21 Pedro Alves <palves@redhat.com>
* gdb.base/dfp-test.c
(d32_t, d64_t, d128_t, d32_t2, d64_t2, d128_t2, v_d32_t, v_d64_t)
(v_d128_t, v_d32_t2, v_d64_t2, v_d128_t2): New.
* gdb.base/dfp-test.exp: Add whatis/ptype/cast tests.
* gdb.base/gnu_vector.exp: Add whatis/ptype/cast tests.
* gdb.base/whatis-ptype-typedefs.c: New.
* gdb.base/whatis-ptype-typedefs.exp: New.
* gdb.python/py-prettyprint.c (int_type, int_type2): New typedefs.
(an_int, an_int_type, an_int_type2): New globals.
* gdb.python/py-prettyprint.exp (run_lang_tests): Add tests
involving typedefs and cast expressions.
* gdb.python/py-prettyprint.py (class pp_int_typedef): New.
(lookup_typedefs_function): New.
(typedefs_pretty_printers_dict): New.
(top level): Register lookup_typedefs_function in
gdb.pretty_printers.
This patch uses GDB self test in GDBserver. The self tests are run if
GDBserver is started with option --selftest.
gdb:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* NEWS: Mention GDBserver's new option "--selftest".
* Makefile.in (SFILES): Remove selftest.c, add common/selftest.c.
* selftest.c: Move it to common/selftest.c.
* selftest.h: Move it to common/selftest.h.
* selftest-arch.c (reset): New function.
(tests_with_arch): Call reset.
gdb/gdbserver:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* Makefile.in (OBS): Add selftest.o.
* configure.ac: AC_DEFINE GDB_SELF_TEST if $development.
* configure, config.in: Re-generated.
* server.c: Include common/sefltest.h.
(captured_main): Handle option --selftest.
gdb/testsuite:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* gdb.server/unittest.exp: New.
gdb/doc:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (Server): Document "--selftest".
When I made commit 9a6c7d9c02, which
C++-fied gdb/common/environ.[ch], I mistakenly altered the behaviour
of the 'unset environment' command. This command, which should delete
all environment variables, is now resetting the list of variables to
the state they were when GDB was started.
This commit fixes this regression, and also adds a test on
gdb.base/environ.exp which really checks if 'unset environment'
worked.
gdb/ChangeLog:
2017-08-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21954
* infcmd.c (unset_environment_command): Use the 'clear' method on
the environment instead of resetting it.
gdb/testsuite/ChangeLog:
2017-08-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21954
* gdb.base/environ.exp: Add test to check if 'unset environment'
works.
Newer GCC versions yield colored diagnostic messages by default, which may
be useful when executing GDB interactively from a terminal. But when run
from a GDB test case, the compiler output is written into gdb.log, where
such escape sequences are usually more inhibiting than helpful to the
evaluation of test results. So this patch suppresses that.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (universal_compile_options): New caching proc.
(gdb_compile): Suppress GCC's coloring of messages.
PR gdb/21675 points out a few regressions in scalar printing.
One type of regression is due to not carrying over the old handling of
floating point printing -- where a format like "/d" causes a floating
point number to first be cast to a signed integer. This patch restores
this behavior.
The other regression is a longstanding bug in print_octal_chars: one of
the constants was wrong. This patch fixes the constant and adds static
asserts to help catch this sort of error.
ChangeLog
2017-08-14 Tom Tromey <tom@tromey.com>
PR gdb/21675
* valprint.c (LOW_ZERO): Change value to 034.
(print_octal_chars): Add static_asserts for octal constants.
* printcmd.c (print_scalar_formatted): Add 'd' case.
testsuite/ChangeLog
2017-08-14 Tom Tromey <tom@tromey.com>
PR gdb/21675:
* gdb.base/printcmds.exp (test_radices): New function.
* gdb.dwarf2/var-access.exp: Use p/u, not p/d.
* gdb.base/sizeof.exp (check_valueof): Use p/d.
* lib/gdb.exp (get_integer_valueof): Use p/d.
The get_valueof procedure allows tests to conveniently make gdb evaluate
an expression an return the value as a string. However, it includes an
end-of-line character in its result. I stumbled on this when trying to
use that result as part of a regex further in a test.
You can see this for example by adding a puts in
gdb.dwarf2/implref-struct.exp:get_members:
set members [get_valueof "" ${var} ""]
puts "<$members>"
The output is
<{a = 0, b = 1, c = 2}
>
This is because the regex in get_valueof is too greedy, the captured
portion matches anything up to the gdb_prompt, including the end of line
characters. This patch changes it to capture everything but end of line
characters.
The output of the puts becomes:
<{a = 0, b = 1, c = 2}>
I tested this by running gdb.dwarf2/implref-array.exp and
gdb.dwarf2/implref-struct.exp, the two only current users of that
procedure.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (get_valueof): Don't capture end-of-line
characters.
I ran the gdb.rust tests against Rust 1.20 (beta) and saw a few
failures. The failures all came because a particular item moved to a
different module. Since the particular choice of module name isn't
important here, I simply widened the allowable results.
Tested locally against rustc 1.19, 1.20, and 1.21.
testsuite/ChangeLog
2017-08-05 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Allow String to appear in a different
namespace.
Now, GDB is able to dynamically create i386-linux target descriptions
from features, instead of using pre-generated target descriptions. These
pre-generated target descriptions are no longer used by GDB (note that
they are still used by GDBserver).
This patch add a new maint command "maint check xml-descriptions" to test
dynamically generated tdesc are identical to these generated from xml files.
gdb:
2017-07-26 Yao Qi <yao.qi@linaro.org>
* cli/cli-cmds.c (maintenancechecklist): New variable.
* gdbcmd.h (maintenancechecklist): Declare it.
* i386-linux-tdep.c (_initialize_i386_linux_tdep) [GDB_SELF_TEST]:
Call i386_linux_read_description with different masks.
* maint.c (maintenance_check_command): New function.
(_initialize_maint_cmds): Call add_prefix_cmd.
* target-descriptions.c (tdesc_reg): override operator != and ==.
(tdesc_type): Likewise.
(tdesc_feature): Likewise.
(target_desc): Likewise.
[GDB_SELF_TEST] (selftests::record_xml_tdesc): New function.
(maintenance_check_xml_descriptions): New function.
(_initialize_target_descriptions) Add command "xml-descriptions".
* target-descriptions.h (selftests::record_xml_tdesc): Declare.
gdb/testsuite:
2017-07-26 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/unittest.exp: Invoke command
"maintenance check xml-descriptions".
gdb/doc:
2017-07-26 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (Maintenance Commands): Document command
"maint check xml-descriptions".
PR 21555 is caused by the exception during the prologue analysis when re-set
a breakpoint.
(gdb) bt
#0 memory_error_message (err=TARGET_XFER_E_IO, gdbarch=0x153db50, memaddr=93824992233232) at ../../binutils-gdb/gdb/corefile.c:192
#1 0x00000000005718ed in memory_error (err=TARGET_XFER_E_IO, memaddr=memaddr@entry=93824992233232) at ../../binutils-gdb/gdb/corefile.c:220
#2 0x00000000005719d6 in read_memory_object (object=object@entry=TARGET_OBJECT_CODE_MEMORY, memaddr=93824992233232, memaddr@entry=1, myaddr=myaddr@entry=0x7fffffffd0a0 "P\333S\001", len=len@entry=1) at ../../binutils-gdb/gdb/corefile.c:259
#3 0x0000000000571c6e in read_code (len=1, myaddr=0x7fffffffd0a0 "P\333S\001", memaddr=<optimized out>) at ../../binutils-gdb/gdb/corefile.c:287
#4 read_code_unsigned_integer (memaddr=memaddr@entry=93824992233232, len=len@entry=1, byte_order=byte_order@entry=BFD_ENDIAN_LITTLE) at ../../binutils-gdb/gdb/corefile.c:362
#5 0x000000000041d4a0 in amd64_analyze_prologue (gdbarch=gdbarch@entry=0x153db50, pc=pc@entry=93824992233232, current_pc=current_pc@entry=18446744073709551615, cache=cache@entry=0x7fffffffd1e0) at ../../binutils-gdb/gdb/amd64-tdep.c:2310
#6 0x000000000041e404 in amd64_skip_prologue (gdbarch=0x153db50, start_pc=93824992233232) at ../../binutils-gdb/gdb/amd64-tdep.c:2459
#7 0x000000000067bfb0 in skip_prologue_sal (sal=sal@entry=0x7fffffffd4e0) at ../../binutils-gdb/gdb/symtab.c:3628
#8 0x000000000067c4d8 in find_function_start_sal (sym=sym@entry=0x1549960, funfirstline=1) at ../../binutils-gdb/gdb/symtab.c:3501
#9 0x000000000060999d in symbol_to_sal (result=result@entry=0x7fffffffd5f0, funfirstline=<optimized out>, sym=sym@entry=0x1549960) at ../../binutils-gdb/gdb/linespec.c:3860
....
#16 0x000000000054b733 in location_to_sals (b=b@entry=0x15792d0, location=0x157c230, search_pspace=search_pspace@entry=0x1148120, found=found@entry=0x7fffffffdc64) at ../../binutils-gdb/gdb/breakpoint.c:14211
#17 0x000000000054c1f5 in breakpoint_re_set_default (b=0x15792d0) at ../../binutils-gdb/gdb/breakpoint.c:14301
#18 0x00000000005412a9 in breakpoint_re_set_one (bint=bint@entry=0x15792d0) at ../../binutils-gdb/gdb/breakpoint.c:14412
This problem can be fixed by
- either each prologue analyzer doesn't throw exception,
- or catch the exception thrown from gdbarch_skip_prologue,
I choose the latter because the former needs to fix *every* prologue
analyzer to not throw exception.
This error can be reproduced by changing reread.exp. The test reread.exp
has already test that breakpoint can be reset correctly after the
executable is re-read. This patch extends this test by compiling test c
file with and without -fPIE.
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
x86_64/gdb/testsuite/outputs/gdb.base/reread/reread' has changed; re-reading symbols.
Error in re-setting breakpoint 1: Cannot access memory at address 0x555555554790^M
Error in re-setting breakpoint 2: Cannot access memory at address 0x555555554790^M
Starting program: /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.base/reread/reread ^M
This is foo^M
[Inferior 1 (process 27720) exited normally]^M
(gdb) FAIL: gdb.base/reread.exp: opts= "-fPIE" "ldflags=-pie" : run to foo() second time (the program exited)
This patch doesn't re-indent the code, to keep the patch simple.
gdb:
2017-07-25 Yao Qi <yao.qi@linaro.org>
PR gdb/21555
* arch-utils.c (gdbarch_skip_prologue_noexcept): New function.
* arch-utils.h (gdbarch_skip_prologue_noexcept): Declare.
* infrun.c: Include arch-utils.h
(handle_step_into_function): Call gdbarch_skip_prologue_noexcept.
(handle_step_into_function_backward): Likewise.
* symtab.c (skip_prologue_sal): Likewise.
gdb/testsuite:
2017-07-25 Yao Qi <yao.qi@linaro.org>
PR gdb/21555
* gdb.base/reread.exp: Wrap the whole test with two kinds of
compilation flags, with -fPIE and without -fPIE.
s390-vregs.exp yields a Tcl error:
ERROR: can't read "i": no such variable
while executing
"expr $a_high * ($i + 1) * $a_high "
(procedure "hex128" line 2)
invoked from within
"hex128 $a_high $a_low $b_high $b_low"
...
This is a regression, caused by commit 30a254669b -- "Don't always
zero pad in print_*_chars". That patch introduced a new procedure
"hex128" for formatting a 128-bit value as hex, but it accidentally moved
the calculation of the 128-bit value into that new procedure as well
instead of leaving it in the original context. This is fixed.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.exp: Calculate parameters to hex128 in the
calling context.
(hex128): Drop erroneous calculation of parameters.
[I made some typo fixes but forgot to amend my commit before sending the patch,
hence this v2.]
I see the following failure on Ubuntu 16.04's gcc 5.4.0:
Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.python/py-unwind.exp ...
FAIL: gdb.python/py-unwind.exp: continue to breakpoint: break backtrace-broken
FAIL: gdb.python/py-unwind.exp: Backtrace restored by unwinder (pattern 1)
The problem is that the test expects a very particular stack layout.
When stack protection is enabled, it adds a canary value which looks
like an additional local variable. This makes the test complain about
a bad stack layout and fail.
The simple solution is to disable stack protection for that test using
-fno-stack-protector. I checked older compilers (gcc 4.4, clang 3.5)
and they support that flag, so I don't think it's necessary to probe for
whether the compiler supports it.
Maybe a better solution would be to change the test to make it cope with
different stack layouts (perhaps it could save addresses of stuff in
some global variables which GDB/the unwinder would read). I'll go with
the simple solution for now though.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.exp: Disable stack protection when
building test file.
Profiling GDB with the rest of series applied, I saw calls to
language_def showing up high in some runs. The problem is that
language_def is O(N) currently, since walk the languages vector each
time to find the matching language_defn.
IMO, the add_language mechanism is pointless, because "enum language"
implies the core of GDB needs to know about all languages anyway. So
simply make the languages vector array be an array where each
element's index is the corresponding enum language enumerator. Note
that "local_language_defn" is gone along the way. It's just a copy of
"auto", so the new code simply maps one to the other. One fewer place
to update when we need to change the language vector...
Also, a while ago the output of "set language" was made out of order
as side effect of some other change. While I was at it, I made them
sorted again.
gdb/ChangeLog:
2017-07-20 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_language_defn): Make extern.
(_initialize_ada_language): Remove add_language call.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Make extern.
(_initialize_c_language): Delete.
* completer.c (compare_cstrings): Delete, moved to utils.h.
* d-lang.c (d_language_defn): Make extern.
(_initialize_d_language): Remove add_language calls.
* defs.h (enum language): Add comment.
* f-lang.c (f_language_defn): Make extern.
(_initialize_f_language): Remove add_language call.
* go-lang.c (go_language_defn): Make extern.
(_initialize_go_language): Remove add_language call.
* language.c: Include <algorithm>.
(languages): Redefine as const array.
(languages_size, languages_allocsize, DEFAULT_ALLOCSIZE): Delete.
(set_language_command): Handle "local". Use for-range loop.
(set_language): Remove loop.
(language_enum): Rewrite.
(language_def, language_str): Remove loops.
(add_language): Delete.
(add_set_language_command): New, based on add_languages.
(skip_language_trampoline): Adjust.
(local_language_defn): Delete.
(language_gdbarch_post_init): Adjust.
(_initialize_language): Remove add_language calls. Call
add_set_language_command.
* language.h (add_language): Delete.
(auto_language_defn)
(unknown_language_defn, minimal_language_defn, ada_language_defn)
(asm_language_defn, c_language_defn, cplus_language_defn)
(d_language_defn, f_language_defn, go_language_defn)
(m2_language_defn, objc_language_defn, opencl_language_defn)
(pascal_language_defn, rust_language_defn): Declare.
* m2-lang.c (m2_language_defn): Make extern.
(_initialize_m2_language): Remove add_language call.
* objc-lang.c (objc_language_defn): Make extern.
(_initialize_objc_language): Remove add_language call.
* opencl-lang.c (opencl_language_defn): Make extern.
(_initialize_opencl_language): Remove add_language call.
* p-lang.c (pascal_language_defn): Make extern.
(_initialize_pascal_language): Delete.
* rust-lang.c (rust_language_defn): Make extern.
(_initialize_rust_language): Delete.
* utils.h (compare_cstrings): New static inline function.
gdb/testsuite/ChangeLog:
2017-07-20 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp (set language): Adjust expected output.
This test is using "set language ada" expecting that to cause GDB to
do Ada symbol name matching. That won't work when GDB uses the
symbol's language to decide which symbol matching algorithm to use,
because the test's symbols are C symbols.
So generalize the test a bit to not rely on Ada name matching rules.
Confirmed that by undoing the original fix the test was written for,
the test still fails.
gdb/testsuite/ChangeLog:
2017-07-20 Pedro Alves <palves@redhat.com>
* gdb.base/dmsym.c (pck__foo__bar__minsym): Rename to ...
(test_minsym): ... this, and make static.
(get_pck__foo__bar__minsym): Rename to ...
(get_test_minsym): ... this.
* gdb.base/dmsym.exp (): Remove "set language ada" call. Adjust
symbol names and comments.
* gdb.base/dmsym_main.c (get_pck__foo__bar__minsym): Rename to ...
(get_test_minsym): ... this.
(pck__foo__bar__minsym__2): Rename to ...
(test_minsym): ... this.
(main): Adjust.
Continuing the theme of the explicit locations patch, this patch gets
rid of the need for quoting function names in linespec TAB completion.
To recap, when you have overloads in your program, and you want to set
a breakpoint in one of them:
void function(int); // set breakpoint here.
void function(long);
(gdb) b function(i[TAB]
<all the symbols in the program that start with "i" are uselessly shown...>
This patch gets rid of the need for quoting by switching the linespec
completer to use the custom completion word point mechanism added in
the previous explicit location patch (extending it as needed), to
correctly determine the right completion word point. In the case
above, we want the completer to figure out that it's completing a
function name that starts with "function(i", and it now does.
We also want the completer to know when it's potentially completing a
source file name, for:
(gdb) break source.[TAB] -> source.c:
(gdb) break source.c: # Type line number or function name now
And we want it to know to complete label names, which it doesn't today:
(gdb) break function:lab[TAB]
etc., etc.
So what we want is for completion to grok the input string as closely
to how the linespec parser groks it.
With that in mind, the solution suggests itself - make the linespec
completer use the same parsing code as normal linespec parsing.
That's what the patch does. The old completer is replaced by one that
reuses the actual linespec parser as much as possible. This (ideally)
eliminate differences between what completion understands and actually
setting breakpoints understands by design.
The completer now offers sensible completion candidates depending on
which component of the linespec is being completed, source filename,
function, line number, expression, and (a new addition), labels. For
example, when completing the function part, we now show the full name
of the method as completion candidates, instead of showing whatever
comes after what readline considered the word break character:
(gdb) break klass::method[TAB]
klass:method1(int)
klass:method2()
If input is past the function, then we now offer keyword condidates:
(gdb) b function(int) [TAB]
if task thread
If input is past a keyword, we offer expression completion, which is
different from linespec completion:
(gdb) b main if 1 + glo[TAB]
global
(e.g., completes on types, struct data fields, etc.)
As mentioned, this teaches the linespec completer about completing
label symbols too:
(gdb) b source.c:function:lab[TAB]
A nice convenience is that when completion uniquely matches a source
name, gdb adds the ":" automatically for you:
(gdb) b filenam[TAB]
(gdb) b filename.c: # ':' auto-added, cursor right after it.
It's the little details. :-)
I worked on this patch in parallel with writing the (big) testcase
added closer to the end of the series, which exercises many many
tricky cases around quoting and whitespace insertion placement. In
general, I think it now all Just Works.
gdb/ChangeLog:
2017-07-17 Pedro Alves <palves@redhat.com>
* completer.c (complete_source_filenames): New function.
(complete_address_and_linespec_locations): New function.
(location_completer): Use complete_address_and_linespec_locations.
(completion_tracker::build_completion_result): Honor the tracker's
request to suppress append.
* completer.h (completion_tracker::suppress_append_ws)
(completion_tracker::set_suppress_append_ws): New methods.
(completion_tracker::m_suppress_append_ws): New field.
(complete_source_filenames): New declaration.
* linespec.c (linespec_complete_what): New.
(struct ls_parser) <complete_what, completion_word,
completion_quote_char, completion_quote_end, completion_tracker>:
New fields.
(string_find_incomplete_keyword_at_end): New.
(linespec_lexer_lex_string): Record quote char. If in completion
mode, don't throw.
(linespec_lexer_consume_token): Advance the completion word point.
(linespec_lexer_peek_token): Save/restore completion info.
(save_stream_and_consume_token): New.
(set_completion_after_number): New.
(linespec_parse_basic): Set what to complete next depending on
token. Handle function and label completions specially.
(parse_linespec): Disable objc shortcut in completion mode. Set
what to complete next depending on token type. Skip keyword if in
completion mode.
(complete_linespec_component, linespec_complete): New.
* linespec.h (linespec_complete): Declare.
gdb/testsuite/ChangeLog:
2017-07-17 Pedro Alves <palves@redhat.com>
* gdb.base/completion.exp: Adjust expected output.
* gdb.linespec/ls-errs.exp: Don't send tab characters, now that
the completer works.
One of the most annoying (to me) things about GDB's completion is when
you have overloads in your program, and you want to set a breakpoint
in one of them:
void function(int); // set breakpoint here.
void function(long);
(gdb) b -f func[TAB]
(gdb) b -f function( # ok, gdb completed as much as possible.
(gdb) b -f function([TAB] # show me the overloads, please.
<_all_ symbols in the program are shown...>
E.g., when debugging GDB, that'd be:
(gdb) b -f function([TAB]
(anonymous namespace)::get_global()::global pt_insn_get_offset@plt scm_new_port_table_entry
asprintf pt_pkt_alloc_decoder scm_new_port_table_entry@plt
asprintf@plt pt_pkt_alloc_decoder@plt scm_out_of_range
bt_ctf_get_char_array pt_pkt_sync_forward scm_out_of_range@plt
bt_ctf_get_char_array@plt pt_pkt_sync_forward@plt scm_putc
bt_ctf_get_uint64 pwrite scm_putc@plt
bt_ctf_get_uint64@plt pwrite@plt scm_reverse_x
bt_ctf_iter_read_event PyErr_Restore scm_reverse_x@plt
bt_ctf_iter_read_event@plt PyErr_Restore@plt scm_set_port_filename_x
<snip...>
Now that's a load of completely useless completions.
The reason GDB offers those is that the completer relies on readline
figuring out the completion word point in the input line based on the
language's word break characters, which include "(". So readline
tells the completer to complete on "", the string that is after '('.
Likewise, if you type "function(i[TAB]" to try to complete to "int",
you're out of luck. GDB shows you all the symbols in the program that
start with "i"... This makes sense for the expression completer, as
what you'd want to type is e.g., a global variable, say:
(gdb) print function(i[TAB]
but, it makes no sense when specifying a function name for a
breakpoint location.
To get around that limitation, users need to quote the function name,
like:
(gdb) b -f 'function([TAB]
function(int) function(long)
(gdb) b 'function(i[TAB]
(gdb) b 'function(int)' # now completes correctly!
Note that the quoting is only necessary for completion. Creating the
breakpoint does not require the quoting:
(gdb) b -f function(int) [RET]
Breakpoint 1 at ....
This patch removes this limitation.
(
Actually, it's a necessary patch, though not sufficient. That'll
start working correctly by the end of the series. With this patch, if try it,
you'll see:
(gdb) b -f function(i[TAB]
(gdb) b -f function
i.e., gdb strips everything after the "(". That's caused by some code
in symtab.c that'll be eliminated further down the series. These
patches are all unfortunately interrelated, which is also the reason
new tests only appear much later in the series.
But let's ignore that reality for the remainder of the description.
)
So... this patch gets rid of the need for quoting.
It does that by adding a way for a completer to control the exact
completion word point that readline should start the completion
request for, instead of letting readline try to figure it out using
the current language's word break chars array, and often failing.
In the case above, we want the completer to figure out that it's
completing a function name that starts with "function(i". It now
does.
It took me a while to figure out a way to ask readline to "use this
exact word point", and for a while I feared that it'd be impossible
with current readline (and having to rely on master readline for core
functionality is something I'd like to avoid very much). Eventually,
after several different attempts, I came up with what is described in
the comment above gdb_custom_word_point_brkchars in the patch.
With this patch, the handle_brkchars phase of the explicit location
completer advances the expected word point as it parses the input line
left to right, until it figures out exactly what we're completing,
instead of expecting readline to break the string using the word break
characters, and then having the completer heuristically fix up a bad
decision by parsing the input string backwards. This allows correctly
knowning that we're completing a symbol name after -function, complete
functions without quoting, etc.
Later, we'll make use of this same mechanims to implement a proper
linespec completer that avoids need for quoting too.
gdb/ChangeLog:
2017-07-17 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_collect_symbol_completion_matches): Add
complete_symbol_mode parameter.
* cli/cli-cmds.c (complete_command): Get the completion result out
of the handle_brkchars tracker if used a custom word point.
* completer.c: Include "linespec.h".
(enum explicit_location_match_type) <MATCH_LINE>: New enumerator.
(advance_to_expression_complete_word_point): New.
(completion_tracker::completes_to_completion_word): New.
(complete_files_symbols): Pass down
complete_symbol_mode::EXPRESSION.
(explicit_options, probe_options): New.
(collect_explicit_location_matches): Complete on the
explictit_loc->foo instead of word. Use
linespec_complete_function. Handle MATCH_LINE. Handle offering
keyword and options completions.
(backup_text_ptr): Delete.
(skip_keyword): New.
(complete_explicit_location): Remove 'word' parameter. Add
language, quoted_arg_start and quoted_arg_end parameters.
Rewrite, parsing left to right.
(location_completer): Rewrite.
(location_completer_handle_brkchars): New function.
(symbol_completer): Pass down complete_symbol_mode::EXPRESSION.
(enum complete_line_internal_reason): Adjust comments.
(completion_tracker::discard_completions): New.
(completer_handle_brkchars_func_for_completer): Handle
location_completer.
(gdb_custom_word_point_brkchars)
(gdb_org_rl_basic_quote_characters): New.
(gdb_completion_word_break_characters_throw)
(completion_find_completion_word): Handle trackers that use a
custom word point.
(completion_tracker::advance_custom_word_point_by): New.
(completion_tracker::build_completion_result): Don't rely on
readline appending the quote char.
(gdb_rl_attempted_completion_function_throw): Handle trackers that
use a custom word point.
(gdb_rl_attempted_completion_function): Restore
rl_basic_quote_characters.
* completer.h (class completion_tracker): Extend intro comment.
(completion_tracker::set_quote_char)
(completion_tracker::quote_char)
(completion_tracker::set_use_custom_word_point)
(completion_tracker::use_custom_word_point)
(completion_tracker::custom_word_point)
(completion_tracker::set_custom_word_point)
(completion_tracker::advance_custom_word_point_by)
(completion_tracker::completes_to_completion_word)
(completion_tracker::discard_completions): New methods.
(completion_tracker::m_quote_char)
(completion_tracker::m_use_custom_word_point)
(completion_tracker::m_custom_word_point): New fields.
(advance_to_expression_complete_word_point): Declare.
* f-lang.c (f_collect_symbol_completion_matches): Add
complete_symbol_mode parameter.
* language.h (struct language_defn)
<la_collect_symbol_completion_matches>: Add complete_symbol_mode
parameter.
* linespec.c (linespec_keywords): Add NULL terminator. Make extern.
(linespec_complete_function): New function.
(linespec_lexer_lex_keyword): Adjust.
* linespec.h (linespec_keywords, linespec_complete_function): New
declarations.
* location.c (find_end_quote): New function.
(explicit_location_lex_one): Add explicit_completion_info
parameter. Save quoting info. Don't throw if being called for
completion. Don't handle Ada operators here.
(is_cp_operator, skip_op_false_positives, first_of)
(explicit_location_lex_one_function): New function.
(string_to_explicit_location): Replace 'dont_throw' parameter with
an explicit_completion_info pointer parameter. Handle it. Don't
use explicit_location_lex_one to lex function names. Use
explicit_location_lex_one_function instead.
* location.h (struct explicit_completion_info): New.
(string_to_explicit_location): Replace 'dont_throw' parameter with
an explicit_completion_info pointer parameter.
* symtab.c (default_collect_symbol_completion_matches_break_on):
Add complete_symbol_mode parameter. Handle LINESPEC mode.
(default_collect_symbol_completion_matches)
(collect_symbol_completion_matches): Add complete_symbol_mode
parameter.
(collect_symbol_completion_matches_type): Pass down
complete_symbol_mode::EXPRESSION.
(collect_file_symbol_completion_matches): Add complete_symbol_mode
parameter. Handle LINESPEC mode.
* symtab.h (complete_symbol_mode): New.
(default_collect_symbol_completion_matches_break_on)
(default_collect_symbol_completion_matches)
(collect_symbol_completion_matches)
(collect_file_symbol_completion_matches): Add complete_symbol_mode
parameter.
gdb/testsuite/ChangeLog:
2017-07-17 Pedro Alves <palves@redhat.com>
* gdb.linespec/ls-errs.exp (do_test): Adjust expected output.
Make sure all of the tests have unique names in
gdb.mi/mi-vla-fortran.exp.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Make test names unique.
PR rust/21764 notes that "sizeof" does not work correctly for all types
in Rust. The bug turns out to be an error in the conversion of the AST
to gdb expressions. This patch fixes the bug and also avoids generating
incorrect expressions in another case.
Tested on the buildbot. I'm checking this in.
2017-07-14 Tom Tromey <tom@tromey.com>
PR rust/21764:
* rust-exp.y (convert_ast_to_expression): Add "want_type"
parameter.
<UNOP_SIZEOF>: Split into separate case.
<UNOP_VAR_VALUE>: Handle want_type. Add error case.
2017-07-14 Tom Tromey <tom@tromey.com>
PR rust/21764:
* gdb.rust/simple.exp: Add tests.
PR rust/21763 points out that gdb.lookup_typename does not work properly
for (some) Rust types. I tracked this down to a missing case in
symbol_matches_domain.
Tested by the buildbot.
2017-07-14 Tom Tromey <tom@tromey.com>
PR rust/21763:
* symtab.c (symbol_matches_domain): Add language_rust to special
case.
* rust-exp.y (convert_ast_to_expression) <OP_VAR_VALUE>: Don't
treat LOC_TYPEDEF symbols as variables.
2017-07-14 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Add regression test for PR rust/21763.
This is the same patch as posted at
<https://sourceware.org/ml/gdb-patches/2017-02/msg00644.html>, with
the test at
<https://sourceware.org/ml/gdb-patches/2017-02/msg00687.html> squashed
in.
This patch fixes:
-FAIL: gdb.base/completion.exp: tab complete break break.c:ma (timeout)
-FAIL: gdb.base/completion.exp: complete break break.c:ma
+PASS: gdb.base/completion.exp: tab complete break break.c:ma
+PASS: gdb.base/completion.exp: delete breakpoint for tab complete break break.c:ma
+PASS: gdb.base/completion.exp: complete break break.c:ma
When run with --target_board=dwarf4-gdb-index.
The issue here is that make_file_symbol_completion_list_1, used when
completing a symbol restricted to a given source file, uses
lookup_symtab to look up the symtab with the given name, and search
for matching symbols inside. This assumes that there's only one
symtab for the given source file. This is an incorrect assumption
with (for example) -fdebug-types-section, where we'll have an extra
extra symtab containing the types. lookup_symtab finds that symtab,
and inside that symtab there are no functions...
gdb/ChangeLog:
2017-07-14 Pedro Alves <palves@redhat.com>
* symtab.c (make_file_symbol_completion_list_1): Iterate over
symtabs matching all symtabs with SRCFILE as file name instead of
only considering the first hit, with lookup_symtab.
gdb/testsuite/ChangeLog:
2017-07-14 Pedro Alves <palves@redhat.com>
* gdb.linespec/base/one/thefile.cc (z1): New function.
* gdb.linespec/base/two/thefile.cc (z2): New function.
* gdb.linespec/linespec.exp: Add tests.
In the test gdb.mi/mi-vla-fortran.exp the parameters passed to
mi_create_breakpoint are passed in the wrong order. By good luck the
tests still passes, however the wrong test name is used. All fixed in
this commit.
A previous commit fixed most of these, but I missed this last one.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Correct even more parameter passing
to mi_create_breakpoint.
In the test gdb.mi/mi-vla-fortran.exp the parameters passed to
mi_create_breakpoint are passed in the wrong order. By good luck the
tests still passes, however the wrong test name is used. All fixed in
this commit.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Correct parameter passing to
mi_create_breakpoint.
Rationale behind the change instead of adding a `.init$' postfix being
that "initializer for symbol" is much more informative when inspecting D
runtime type information in gdb, which is the only place where you would
encounter references to this compiler-generated symbol.
gdb/testsuite/ChangeLog:
* gdb.dlang/demangle.exp: Update for demangling changes.
This Rust bug report:
https://github.com/rust-lang/rust/issues/41970
noted an error from gdb. What is happening here (for me, the original
report had a different error) is that a pieced DWARF expression is not
writing to every byte in the resulting value. GDB errors in this
case. However, it seems to me that it is always valid to write fewer
bytes; the issue comes from writing too many -- that is, the test is
reversed. The test was also checking the sub-object, but this also
seems incorrect, as it's expected for the expression to write the
entirety of the enclosing object. So, this patch reverses the test
and applies it to the outer type, not the subobject type.
Regtested on the buildbot.
gdb/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Reverse size
check and apply to outer type.
gdb/testsuite/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/shortpiece.exp: New file.
In some cases a compiler may produce a single object file (& thus single
DWO file) representing multiple source files. The most common example of
this is in whole program optimization (such as LLVM's LTO). Fission may
still be a beneficial feature to use here - to avoid the need to
read/link the debug info with system libraries and the like.
This change adds basic support for multiple CUs in a single DWO file to
support LLVM's output in this situation.
There is still outstanding work to design and implement a solution for
cross-CU references (usually using DW_FORM_ref_addr) in this scenario.
For now LLVM works around this by duplicating DIEs rather than making
cross-CU references in DWO files. This degrades debugger
behavior/quality especially for file-local entities.
2017-07-06 David Blaikie <dblaikie@gmail.com>
* dwarf2read.c (struct dwo_file): Use a htab of dwo_unit* (rather than
a singular dwo_unit*) to support multiple CUs in the same way that
multiple TUs are supported.
(create_cus_hash_table): Replace create_dwo_cu with a function for
parsing multiple CUs from a DWO file.
(open_and_init_dwo_file): Use create_cus_hash_table rather than
create_dwo_cu.
(lookup_dwo_cutu): Lookup CU in the hash table in the dwo_file with
htab_find, rather than comparing the signature to a singleton CU in
the dwo_file.
2017-07-06 David Blaikie <dblaikie@gmail.com>
* gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs in a DWO,
built from fissiont-multi-cu{1,2}.c.
* gdb.dwarf2/fission-multi-cu.exp: Test similar to fission-base.exp,
except putting 'main' and 'func' in separate CUs in the same DWO file.
* gdb.dwarf2/fission-multi-cu1.c: First CU for the multi-CU-single-DWO
test.
* gdb.dwarf2/fission-multi-cu2.c: Second CU in the multi-CU-single-DWO
test.
The gdb.python/py-unwind.exp test is crashing GDB / leaving core dumps
in the test dir, even though it all passes cleanly. The crash is not
visible in gdb.sum/gdb.log because it happens as side effect of the
"quit" command, while flushing the frame cache.
The problem is simply a typo in a 'for' loop's condition, introduced
by a recent change [4fa847d78e ("Remove MAX_REGISTER_SIZE from
py-unwind.c")], resulting in infinite loop / double-free.
The new test exposes the crash, like:
Running src/gdb/testsuite/gdb.python/py-unwind.exp ...
ERROR: Process no longer exists
gdb/ChangeLog:
2017-07-06 Pedro Alves <palves@redhat.com>
* python/py-unwind.c (pyuw_dealloc_cache): Fix for loop condition.
gdb/testsuite/ChangeLog:
2017-07-06 Pedro Alves <palves@redhat.com>
* gdb.python/py-unwind.exp: Test flushregs.
My last commit fixed a regression that happened when using
inline/multi-line commands for Python/Compile/Guile, but introduced
another regression: it is now not possible to use aliases for the
commands mentioned above. The fix is to almost revert the change I've
made and go back to using the 'struct cmd_list_element *', but at the
same time make sure that we advance the 'cmd_name' variable past all
the whitespace characters after the command name. If, after skipping
the whitespace, we encounter a '\0', it means that the command is not
inline. Otherwise, it is.
This patch also expands the testcase in order to check for aliases and
for trailing whitespace after the command name.
gdb/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/21688
* cli/cli-script.c (command_name_equals_not_inline): Remove function.
(process_next_line): New variable 'inline_cmd'.
Adjust 'if' clauses for "python", "compile" and "guile" to use
'command_name_equals' and check for '!inline_cmd'.
gdb/testsuite/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/21688
* gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add new
tests for alias commands and trailing whitespace.
This bug is a regression caused by the following commit:
604c4576fd is the first bad commit
commit 604c4576fd
Author: Jerome Guitton <guitton@adacore.com>
Date: Tue Jan 10 15:15:53 2017 +0100
The problem happens because, on cli/cli-script.c:process_next_line,
GDB is not using the command line string to identify which command to
run, but it instead using the 'struct cmd_list_element *' that is
obtained by using the mentioned string. The problem with that is that
the 'struct cmd_list_element *' doesn't have any information on
whether the command issued by the user is a multi-line or inline one.
A multi-line command is a command that will necessarily be composed of
more than 1 line. For example:
(gdb) if 1
>python
>print ('hello')
>end
>end
As can be seen in the example above, the 'python' command actually
"opens" a new command line (represented by the change in the
indentation) that will then be used to enter Python code. OTOH, an
inline command is a command that is "self-contained" in a single line,
for example:
(gdb) if 1
>python print ('hello')
>end
This Python command is a one-liner, and therefore there is no other
Python code that can be entered for this same block. There is also no
change in the indentation.
So, the fix is somewhat simple: we have to revert the change and use
the full command line string passed to process_next_line in order to
identify whether we're dealing with a multi-line or an inline command.
This commit does just that. As can be seen, this regression also
affects other languages, like guile or the compile framework. To make
things clearer, I decided to create a new helper function responsible
for identifying a non-inline command.
Testcase is attached.
gdb/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/21688
* cli/cli-script.c (command_name_equals_not_inline): New function.
(process_next_line): Adjust 'if' clauses for "python", "compile"
and "guile" to use command_name_equals_not_inline.
gdb/testsuite/ChangeLog:
2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/21688
* gdb.python/py-cmd.exp (test_python_inline_or_multiline): New
procedure. Call it.
This commit fixes a mismatch between what "print" command completer
thinks the command understands, and what the command actually
understands.
The explicit location options are understood by commands that take
(linespecs and) explicit locations as argument. I.e, breakpoint
commands, and "list". For example:
(gdb) b -source file.c -function my_func
So for those commands, it makes sense that the completer
completes:
"b -sour[TAB]" -> "b -source "
"b -functi[TAB]" -> "b -function "
etc.
However, completion for commands that take expressions (not
linespecs/locations) as arguments, such as the "print" command, also
completes the explicit location options, even though those switches
aren't really understood by these commands. Instead, "-foo" is
understood as an expression applying unary minus on a symbol named
"foo" (think "print -1"):
(gdb) p -func[TAB]
(gdb) p -function [RET]
No symbol "function" in current context.
The patch fixes this by having the expression_completer function
bypass the function that completes explicit locations.
New regression tests included.
gdb/ChangeLog:
2017-06-29 Pedro Alves <palves@redhat.com>
* completer.c (expression_completer): Call
linespec_location_completer instead of location_completer.
gdb/testsuite/ChangeLog:
2017-06-29 Pedro Alves <palves@redhat.com>
* gdb.base/printcmds.exp: Add tests.
Fix issue exposed by commit 3e29f34.
The basic issue is that section data referenced through an objfile
pointer can also be referenced via the program-space data pointer,
although via a separate mapping mechanism, which is set up by
update_section_map. Thus once section data attached to an objfile
pointer is released, the section map associated with the program-space
data pointer must be marked dirty to ensure that update_section_map is
called to prevent stale data being referenced. For the matter at hand
this marking is being done via a call to objfiles_changed.
Before commit 3e29f34 objfiles_changed could be called after all of
the objfile pointers were processed in reread_symbols since section
data references via the program-space data pointer would not occur in
the calls of read_symbols performed by reread_symbols.
With commit 3e29f34 MIPS target specific calls to find_pc_section were
added to the code for DWARF information processing, which is called
via read_symbols. Thus in reread_symbols the call to objfiles_changed
needs to be called before calling read_symbols, otherwise stale
section data can be referenced.
Thanks to Luis Machado for providing text for the main comment
associated with the change.
gdb/
2017-06-28 Doug Gilmore <Doug.Gilmore@imgtec.com>
PR gdb/21337
* symfile.c (reread_symbols): Call objfiles_changed just before
read_symbols.
gdb/testsuite/
2017-06-28 Doug Gilmore <Doug.Gilmore@imgtec.com>
PR gdb/21337
* gdb.base/reread-readsym.exp: New file.
* gdb.base/reread-readsym.c: New file.
This is the portion of gdb_test which performs the match against
the RE (regular expression) passed to it:
return [gdb_test_multiple $command $message {
-re "\[\r\n\]*($pattern)\[\r\n\]+$gdb_prompt $" {
if ![string match "" $message] then {
pass "$message"
}
}
In a test that I've been working on recently, I wanted to use
a backreference - that's the \1 in the the RE below:
gdb_test "info threads" \
{.*[\r\n]+\* +([0-9]+) +Thread[^\r\n]* do_something \(n=\1\) at.*}
Put into English, I wanted to make sure that the value of n passed to
do_something() is the same as the thread number shown in the "info
threads" Id column. (I've structured the test case so that this
*should* be the case.)
It didn't work though. It turned out that ($pattern) in the RE
noted above is capturing the attempted backreference. So, in this
case, the backreference does not refer to ([0-9]+) as intended, but
instead refers to ($pattern). This is wrong because it's not what I
intended, but is also wrong because, if allowed, it could only match a
string of infinite length.
This problem can be fixed by using parens for a "noncapturing
subpattern". The way that this is done, syntactically, is to use
(?:$pattern) instead of ($pattern).
My research shows that this feature has been present since tcl8.1 which
was released in 1999.
The current tcl version is 8.6 - at least that's what I have on my
machine. It appears to me that mingw uses some subversion of tcl8.4
which will also have this feature (since 8.4 > 8.1).
So it seems to me that any platform upon which we might wish to test
GDB will have a version of tcl which has this feature. That being the
case, my hope is that there won't be any objections to its use.
When I looked at the implementation of gdb_test, I wondered whether
the parens were needed at all. I've concluded that they are. In the
event that $pattern is an RE which uses alternation at the top level,
e.g. a|b, we need to make $pattern a subpattern (via parens) to limit
the extend of the alternation. I.e, we don't want the alternation to
extend to the other portions of the RE which gdb_test uses to match
potential blank lines at the beginning of the pattern or the gdb
prompt at the end.
gdb/testsuite/ChangeLog:
* gdb.exp (gdb_test): Using noncapturing parens for the $pattern
subpattern.
When I added the new lnia extended mnemonic for addpcis, I updated the
assembler/disassembler test cases, but overlooked the GDB test cases.
This patch fixes that oversight and associated test case failure.
* gdb.arch/powerpc-power9.exp: Update test case for new lnia
extended mnemonic.
* gdb.arch/powerpc-power9.s: Likewise.
The new test var-access.exp causes FAILs on i686. This is because the
test chooses the wrong name for DWARF register number 1: It uses
"edx" (which corresponds to DWARF register number 2), but should have used
"ecx" instead.
Also, the current logic in var-access.exp does not correctly distinguish
between a 64-bit and a 32-bit program on an x86-64 target. It uses the
64-bit register names for both.
These problems are fixed. In order to address the latter, the convenience
macros is_*_target are exploited where appropriate.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.exp: Use register name ecx instead of edx
on 32-bit x86 targets. Exploit is_*_target macros where
appropriate.
So far GDB ignores the piece offset of all kinds of DWARF bit
pieces (DW_OP_bit_piece) and treats such pieces as if the offset was zero.
This is fixed, and an appropriate test is added.
gdb/ChangeLog:
* dwarf2loc.c (read_pieced_value): Respect the piece offset, as
given by DW_OP_bit_piece.
(write_pieced_value): Likewise.
Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.dwarf2/var-access.exp: Add test for composite location with
nonzero piece offsets.
For big-endian targets the logic in read/write_pieced_value tries to take
a register piece from the LSB end. This requires offsets and sizes to be
adjusted accordingly, and that's where the current implementation has some
issues:
* The formulas for recalculating the bit- and byte-offsets into the
register are wrong. They just happen to yield correct results if
everything is byte-aligned and the piece's last byte belongs to the
given value.
* After recalculating the bit offset into the register, the number of
bytes to be copied from the register is not recalculated. Of course
this does not matter if everything (particularly the piece size) is
byte-aligned.
These issues are fixed. The size calculation is performed with a new
helper function bits_to_bytes().
gdb/ChangeLog:
* dwarf2loc.c (bits_to_bytes): New function.
(read_pieced_value): Fix offset calculations for register pieces
on big-endian targets.
(write_pieced_value): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.exp: Add test for non-byte-aligned
register pieces.
This verifies some of the previous fixes to the logic in
write_pieced_value when accessing bit-fields.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.exp: Add tests for accessing bit-fields
located in one or more DWARF pieces.
The test suite contains multiple instances of determining the target's
endianness with GDB's "show endian" command. This patch replaces these by
an invocation of a new convenience proc 'get_endianness'.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (get_endianness): New proc.
* gdb.arch/aarch64-fp.exp: Use it.
* gdb.arch/altivec-regs.exp: Likewise.
* gdb.arch/e500-regs.exp: Likewise.
* gdb.arch/vsx-regs.exp: Likewise.
* gdb.base/dump.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/gnu_vector.exp: Likewise.
* gdb.dwarf2/formdata16.exp: Likewise.
* gdb.dwarf2/implptrpiece.exp: Likewise.
* gdb.dwarf2/nonvar-access.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.trace/unavailable-dwarf-piece.exp: Likewise.
When taking a DW_OP_piece or DW_OP_bit_piece from a DW_OP_stack_value, the
existing logic always takes the piece from the lowest-addressed end, which
is wrong on big-endian targets. The DWARF standard states that the
"DW_OP_bit_piece operation describes a sequence of bits using the least
significant bits of that value", and this also matches the current logic
in GCC. For instance, the GCC guality test case pr54970.c fails on s390x
because of this.
This fix adjusts the piece accordingly on big-endian targets. It is
assumed that:
* DW_OP_piece shall take the piece from the LSB end as well;
* pieces reaching outside the stack value bits are considered undefined,
and a zero value can be used instead.
gdb/ChangeLog:
PR gdb/21226
* dwarf2loc.c (read_pieced_value): Anchor stack value pieces at
the LSB end, independent of endianness.
gdb/testsuite/ChangeLog:
PR gdb/21226
* gdb.dwarf2/nonvar-access.exp: Add checks for verifying that
stack value pieces are taken from the LSB end.
A field f in a structure composed of DWARF pieces may be located in
multiple pieces, where the first and last of those may contain bits from
other fields as well. So when writing to f, the beginning of the first
and the end of the last of those pieces may have to be skipped. But the
logic in write_pieced_value for handling one of those pieces is flawed
when the first and last piece are the same, i.e., f is contained in a
single piece:
< - - - - - - - - - piece_size - - - - - - - - - ->
+-------------------------------------------------+
| skipped_bits | f_bits | / / / / / / / / / / |
+-------------------------------------------------+
The current logic determines the size of the sub-piece to operate on by
limiting the piece size to the bit size of f and then subtracting the
skipped bits:
min (piece_size, f_bits) - skipped_bits
Instead of:
min (piece_size - skipped_bits, f_bits)
So the resulting sub-piece size is corrupted, leading to wrong handling of
this piece in write_pieced_value.
Note that the same bug was already found in read_pieced_value and fixed
there (but not in write_pieced_value), see PR 15391.
This patch swaps the calculations, bringing them into the same (correct)
order as in read_pieced_value.
gdb/ChangeLog:
* dwarf2loc.c (write_pieced_value): Fix order of calculations for
size capping.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-pieces.exp: Add test case for modifying a
variable at nonzero offset.
This adds a test for read/write access to variables with various types of
DWARF locations. It uses register- and memory locations and composite
locations with register- and memory pieces.
Since the new test calls gdb_test_no_output with commands that contain
braces, it is necessary for string_to_regexp to quote braces as well.
This was not done before.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.c: New file.
* gdb.dwarf2/var-access.exp: New test.
* lib/gdb-utils.exp (string_to_regexp): Quote braces as well.
This unifies the two switches in print_scalar_formatted, removing some
now-redundant code. Now scalar types are never converted to LONGEST,
instead printing is done using print_*_chars, operating on the byte
representation.
ChangeLog
2017-06-12 Tom Tromey <tom@tromey.com>
* printcmd.c (print_scalar_formatted): Unify the two switches.
Don't convert scalars to LONGEST.
2017-06-12 Tom Tromey <tom@tromey.com>
* gdb.arch/altivec-regs.exp: Expect decimal results for uint128.
This patch implements the proper support for the "startup-with-shell"
feature on gdbserver. A new packet is added, QStartupWithShell, and
it is sent on initialization. If the host sends a
"QStartupWithShell:1", it means the inferior shall be started using a
shell. If the host sends a "QStartupWithShell:0", it means the
inferior shall be started without using a shell. Any other value is
considered an error.
There is no way to remotely set the shell that will be used by the
target to start the inferior. In order to do that, the user must
start gdbserver while providing a shell via the $SHELL environment
variable. The same is true for the host side.
The "set startup-with-shell" setting from the host side is used to
decide whether to start the remote inferior using a shell. This same
setting is also used to decide whether to use a shell to start the
host inferior; this means that it is not really possible to start the
inferior using different mechanisms on target and host.
A documentation patch is included, along with a new testcase for the
feature.
gdb/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS (Changes since GDB 8.0): Announce that GDBserver is now
able to start inferiors using a shell.
(New remote packets): Announce new packet "QStartupWithShell".
* remote.c: Add PACKET_QStartupWithShell.
(extended_remote_create_inferior): Handle new
PACKET_QStartupWithShell.
(remote_protocol_features) <QStartupWithShell>: New entry for
PACKET_QStartupWithShell.
(_initialize_remote): Call "add_packet_config_cmd" for
QStartupShell.
gdb/gdbserver/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c (handle_general_set): Handle new packet
"QStartupWithShell".
(handle_query): Add "QStartupWithShell" to the list of supported
packets.
(gdbserver_usage): Add help text explaining the
new "--startup-with-shell" and "--no-startup-with-shell" CLI
options.
(captured_main): Recognize and act upon the presence of the new
CLI options.
gdb/testsuite/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/startup-with-shell.c: New file.
* gdb.base/startup-with-shell.exp: Likewise.
gdb/doc/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Starting) <startup-with-shell>: Add @anchor.
(Connecting) <Remote Packet>: Add "startup-with-shell"
and "QStartupWithShell" to the table.
(Remote Protocol) <QStartupWithShell>: New item, explaining the
packet.
This is the most important (and the biggest, sorry) patch of the
series. It moves fork_inferior from gdb/fork-child.c to
nat/fork-inferior.c and makes all the necessary adjustments to both
GDB and gdbserver to make sure everything works OK.
There is no "most important change" with this patch; all changes are
made in a progressive way, making sure that gdbserver had the
necessary features while not breaking GDB at the same time.
I decided to go ahead and implement a partial support for starting the
inferior with a shell on gdbserver, although the full feature comes in
the next patch. The user won't have the option to disable the
startup-with-shell, and also won't be able to change which shell
gdbserver will use (other than setting the $SHELL environment
variable, that is).
Everything is working as expected, and no regressions were present
during the tests.
gdb/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add "common/common-inferior.h"
and "nat/fork-inferior.h".
* common/common-inferior.h: New file, with contents from
"gdb/inferior.h".
* commom/common-utils.c: Include "common-utils.h".
(stringify_argv): New function.
* common/common-utils.h (stringify_argv): New prototype.
* configure.nat: Add "fork-inferior.o" as a dependency for
"*linux*", "fbsd*" and "nbsd*" hosts.
* corefile.c (get_exec_file): Update comment.
* darwin-nat.c (darwin_ptrace_him): Call "gdb_startup_inferior"
instead of "startup_inferior".
(darwin_create_inferior): Call "add_thread_silent" after
"fork_inferior".
* fork-child.c: Cleanup unnecessary includes.
(SHELL_FILE): Move to "common/common-fork-child.c".
(environ): Likewise.
(exec_wrapper): Initialize.
(get_exec_wrapper): New function.
(breakup_args): Move to "common/common-fork-child.c"; rename to
"breakup_args_for_exec".
(escape_bang_in_quoted_argument): Move to
"common/common-fork-child.c".
(saved_ui): New variable.
(prefork_hook): New function.
(postfork_hook): Likewise.
(postfork_child_hook): Likewise.
(gdb_startup_inferior): Likewise.
(fork_inferior): Move to "common/common-fork-child.c". Update
function to support gdbserver.
(startup_inferior): Likewise.
* gdbcore.h (get_exec_file): Remove declaration.
* gnu-nat.c (gnu_create_inferior): Call "gdb_startup_inferior"
instead of "startup_inferior". Call "add_thread_silent" after
"fork_inferior".
* inf-ptrace.c: Include "nat/fork-inferior.h" and "utils.h".
(inf_ptrace_create_inferior): Call "gdb_startup_inferior"
instead of "startup_inferior". Call "add_thread_silent" after
"fork_inferior".
* inferior.h: Include "common-inferior.h".
(trace_start_error): Move to "common/common-utils.h".
(trace_start_error_with_name): Likewise.
(fork_inferior): Move prototype to "nat/fork-inferior.h".
(startup_inferior): Likewise.
(gdb_startup_inferior): New prototype.
* nat/fork-inferior.c: New file, with contents from "fork-child.c".
* nat/fork-inferior.h: New file.
* procfs.c (procfs_init_inferior): Call "gdb_startup_inferior"
instead of "startup_inferior". Call "add_thread_silent" after
"fork_inferior".
* target.h (target_terminal_init): Move prototype to
"target/target.h".
(target_terminal_inferior): Likewise.
(target_terminal_ours): Likewise.
* target/target.h (target_terminal_init): New prototype, moved
from "target.h".
(target_terminal_inferior): Likewise.
(target_terminal_ours): Likewise.
* utils.c (gdb_flush_out_err): New function.
gdb/gdbserver/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* Makefile.in (SFILES): Add "nat/fork-inferior.o".
* configure: Regenerate.
* configure.srv (srv_linux_obj): Add "fork-child.o" and
"fork-inferior.o".
(i[34567]86-*-lynxos*): Likewise.
(spu*-*-*): Likewise.
* fork-child.c: New file.
* linux-low.c: Include "common-inferior.h", "nat/fork-inferior.h"
and "environ.h".
(linux_ptrace_fun): New function.
(linux_create_inferior): Adjust function prototype to reflect
change on "target.h". Adjust function code to use
"fork_inferior".
(linux_request_interrupt): Delete "signal_pid".
* lynx-low.c: Include "common-inferior.h" and "nat/fork-inferior.h".
(lynx_ptrace_fun): New function.
(lynx_create_inferior): Adjust function prototype to reflect
change on "target.h". Adjust function code to use
"fork_inferior".
* nto-low.c (nto_create_inferior): Adjust function prototype and
code to reflect change on "target.h". Update comments.
* server.c: Include "common-inferior.h", "nat/fork-inferior.h",
"common-terminal.h" and "environ.h".
(terminal_fd): Moved to fork-child.c.
(old_foreground_pgrp): Likewise.
(restore_old_foreground_pgrp): Likewise.
(last_status): Make it global.
(last_ptid): Likewise.
(our_environ): New variable.
(startup_with_shell): Likewise.
(program_name): Likewise.
(program_argv): Rename to...
(program_args): ...this.
(wrapper_argv): New variable.
(start_inferior): Delete function.
(get_exec_wrapper): New function.
(get_exec_file): Likewise.
(get_environ): Likewise.
(prefork_hook): Likewise.
(post_fork_inferior): Likewise.
(postfork_hook): Likewise.
(postfork_child_hook): Likewise.
(handle_v_run): Update code to deal with arguments coming from the
remote host. Update calls from "start_inferior" to
"create_inferior".
(captured_main): Likewise. Initialize environment variable. Call
"have_job_control".
* server.h (post_fork_inferior): New prototype.
(get_environ): Likewise.
(last_status): Declare.
(last_ptid): Likewise.
(signal_pid): Likewise.
* spu-low.c: Include "common-inferior.h" and "nat/fork-inferior.h".
(spu_ptrace_fun): New function.
(spu_create_inferior): Adjust function prototype to reflect change
on "target.h". Adjust function code to use "fork_inferior".
* target.c (target_terminal_init): New function.
(target_terminal_inferior): Likewise.
(target_terminal_ours): Likewise.
* target.h: Include <vector>.
(struct target_ops) <create_inferior>: Update prototype.
(create_inferior): Update macro.
* utils.c (gdb_flush_out_err): New function.
* win32-low.c (win32_create_inferior): Adjust function prototype
and code to reflect change on "target.h".
gdb/testsuite/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.server/non-existing-program.exp: Update regex in order to
reflect the fact that gdbserver is now using fork_inferior (with a
shell) to startup the inferior.
This test requires calling a function in the inferior, and therefore it
doesn't make sense to run it if the target doesn't support calling
functions from GDB.
gdb/testsuite/ChangeLog:
* gdb.base/watch-cond-infcall.exp: Don't run if target doesn't
support function calls from GDB.
It's a bit difficult to create an unsized array type in Rust, but if
you do, right now ptype will show something like "[u8; ]". It really
should print "[u8]", though, which is what this patch implements.
This is part of PR 21466.
Built and regtested on x86-64 Fedora 25. I'm checking this in.
ChangeLog
2017-05-21 Tom Tromey <tom@tromey.com>
PR rust/21466:
* rust-lang.c (rust_print_type) <TYPE_CODE_ARRAY>: Print unsized
arrays as "[T]", not "[T; ]".
testsuite/ChangeLog
2017-05-21 Tom Tromey <tom@tromey.com>
PR rust/21466:
* gdb.rust/unsized.exp: New file.
* gdb.rust/unsized.rs: New file.
PR rust/21484 notes that watch -location does not work with Rust:
(gdb) watch -location a
syntax error in expression, near `) 0x00007fffffffe0f4'.
update_watchpoint tries to tell gdb that the new expression it creates
has C syntax:
/* The above expression is in C. */
b->language = language_c;
However, update_watchpoint doesn't actually use this language when
re-parsing the expression.
Originally I was going to fix this by saving and restoring the
language in update_watchpoint, but this regressed
gdb.dlang/watch-loc.exp, because the constructed expression actually
has D syntax (specifically the name is not parseable by C).
Next I looked at directly constructing an expression, and not relying
on the parser at all; but it seemed to me that upon a re-set, we'd
want to reparse the type, and there is no existing API to do this
correctly.
So, in the end I made a hook to let each language choose what
expression to use. I made all the languages other than Rust use the C
expression, because that is the status quo ante. However, this is
probably not truly correct. After this patch, at least, it is easy to
correct by someone who knows the language(s) in question.
Regtested by the buildbot.
ChangeLog
2017-05-19 Tom Tromey <tom@tromey.com>
PR rust/21484:
* rust-lang.c (exp_descriptor_rust): New function.
(rust_language_defn): Use it.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.h (struct language_defn)
<la_watch_location_expression>: New member.
* language.c (unknown_language_defn, auto_language_defn)
(local_language_defn): Update.
* go-lang.c (go_language_defn): Update.
* f-lang.c (f_language_defn): Update.
* d-lang.c (d_language_defn): Update.
* c-lang.h (c_watch_location_expression): Declare.
* c-lang.c (c_watch_location_expression): New function.
(c_language_defn, cplus_language_defn, asm_language_defn)
(minimal_language_defn): Use it.
* breakpoint.c (watch_command_1): Call
la_watch_location_expression.
* ada-lang.c (ada_language_defn): Update.
testsuite/ChangeLog
2017-05-19 Tom Tromey <tom@tromey.com>
PR rust/21484:
* gdb.rust/watch.exp: New file.
* gdb.rust/watch.rs: New file.
With Rust 1.18 and 1.19, I saw some test suite failures. They were
all of the same form -- Box seems to be qualified in the output now,
like:
print box_some
$64 = core::option::Option<alloc::boxed::Box<u8>>::Some(0x7ffff6c21018 "\001\000")
... where the test was expecting Option<Box<u8>>.
This patch fixes the problem in a way that should work with earlier
versions of Rust.
gdb/testsuite/ChangeLog
2017-05-18 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Allow Box to be qualified.
src/gdb/testsuite/gdb.base/fileio.c: In function ‘test_write’:
src/gdb/testsuite/gdb.base/fileio.c:158:5: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
printf ("write 1: ret = %d, errno = %d\n", ret, errno);
^
gdb/ChangeLog:
2017-05-18 Pedro Alves <palves@redhat.com>
* gdb.base/fileio.c (test_write, test_read, test_close)
(test_fstat): Don't print 'ret' in the fail path.
All the "test_" functions warn like:
src/gdb/testsuite/gdb.base/fileio.c: In function ‘test_close’:
src/gdb/testsuite/gdb.base/fileio.c:280:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
Nothing looks at the return of these functions, so just make them
return void. While at it, "()" is not the same as "(void)" in C - fix
that too.
gdb/ChangeLog:
2017-05-18 Pedro Alves <palves@redhat.com>
* gdb.base/fileio.c (stop, test_open, test_write, test_read)
(test_lseek, test_close, test_stat, test_fstat, test_isatty)
(test_system, test_rename, test_unlink, test_time): Change
prototypes.
* gdb.base/fileio.exp (stop_msg): Adjust.
... and quiet -Wnonnull in a different way.
gdb/testsuite/ChangeLog:
2017-05-18 Pedro Alves <palves@redhat.com>
* gdb.base/fileio.c (null_str): New global.
(test_stat): Use it.
* gdb.base/fileio.exp: Remove nowarnings.
I see the following warning in gdb.base/fileio.c,
testsuite/gdb.base/fileio.c:297:3: warning: null argument where non-null required (argument 1) [-Wnonnull]
ret = stat (NULL, &st);
^
This patch adds "nowarnings" to the list passed to gdb_compile.
gdb/testsuite:
2017-05-17 Yao Qi <yao.qi@linaro.org>
* gdb.base/fileio.exp: Pass nowarnings to gdb_compile.
When we add alias command, we call add_alias_cmd and pass the alias name
and command name. This implicitly requires the command and its prefix
commands are already added to cmdlist. This may not be true, for example,
add_com_alias ("tty", "set inferior-tty", class_alias, 0);
"inferior-tty" command is added to setlist, but setlist may not be added
to cmdlist (It depends on the order of related _initialize_XXX functions
called) so that we can't find "set inferior-tty" from cmdlist.
This patch fixes this problem by passing cmd_list_element of "inferior-tty"
to add_alias_cmd, so that cmd_list_element of "inferior-tty" doesn't have
to be reachable from cmdlist at that moment.
gdb:
2017-05-17 Yao Qi <yao.qi@linaro.org>
* cli/cli-decode.c (add_alias_cmd): New function.
* command.h (add_alias_cmd): Declare.
* infcmd.c (_initialize_infcmd): Don't call add_com_alias,
instead call add_alias_cmd.
gdb/testsuite:
2017-05-17 Simon Marchi <simon.marchi@ericsson.com>
* gdb.base/set-inferior-tty.exp (test_set_inferior_tty): Add
argument command.
(top-level): Invoke test_set_inferior_tty.
On some platforms, e.g., arm-eabi-none, we need to make certain that
malloc is linked into the program because the test suite uses function
calls requiring malloc:
(gdb) p foo101("abc")
evaluation of this expression requires the program to have a function "malloc".
gdb/testsuite/ChangeLog
* gdb.cp/oranking.cc (dummy): New function to grab malloc.
(main): Call it.
As discussed here: https://sourceware.org/ml/gdb-patches/2017-04/msg00157.html
A gap is not an instruction and it should not pretend to be one.
gdb.Record.instruction_history is now a list of gdb.RecordInstruction and
gdb.RecordGap objects. This allows the user to deal with Gaps in the record
in a more sane way.
The user would always get the instruction_history and function_call_history
objects of the current thread, not the thread for which the gdb.Record object
was created.
The attached testcase fails without this patch and passes with the patch.
This has been on my TODO list for a while. There's a really old bug
about this (PR testsuite/8595), and there was no reason for
environ.exp to be specific for hppa* targets. So this patch removes
this constraint, modernizes the testcase, and cleans up some things.
Most of the tests remained, and some were rewritten (especially the
one that checks if "show environment" works, which is something kind
of hard to do).
As a bonus, I'm adding a separated info-program.exp file containing
all the tests related to "info program" that were present on
environ.exp.
Tested locally, everything still passes.
gdb/testsuite/ChangeLog:
2017-04-28 Sergio Durigan Junior <sergiodj@redhat.com>
PR testsuite/8595
* gdb.base/environ.exp: Make test available in all architectures.
Move bits related to "info program" testing to
gdb.base/info-program.exp. Rewrite tests to use the two new
procedures mentione below.
(test_set_show_env_var) New procedure.
(test_set_show_env_var_equal): Likewise.
* gdb.base/info-program.exp: New file.
The following patch fixes several outstanding overload resolution problems
with rvalue references and cv qualifiers in the test suite. The tests for
these problems typically passed with one compiler version and failed with
another. This behavior occurs because of the ordering of the overloaded
functions in the debug info. So the first best match "won out" over the
a subsequent better match.
One of the bugs addressed by this patch is the failure of rank_one_type to
account for type equality of two overloads based on CV qualifiers. This was
leading directly to problems evaluating rvalue reference overload quality,
but it is also highlighted in gdb.cp/oranking.exp, where two test KFAIL as
a result of this shortcoming.
I found the overload resolution code committed with the rvalue reference
patch (f9aeb8d49) needlessly over-complicated, and I have greatly simplified
it. This fixes some KFAILing tests in gdb.exp/rvalue-ref-overload.exp.
gdb/ChangeLog
* gdbtypes.c (LVALUE_REFERENCE_TO_RVALUE_BINDING_BADNESS)
DIFFERENT_REFERENCE_TYPE_BADNESS): Remove.
(CV_CONVERSION_BADNESS): Define.
(rank_one_type): Remove overly restrictive rvalue reference
rank checks.
Add cv-qualifier checks and subranks for type equality.
* gdbtypes.h (REFERENCE_CONVERSION_RVALUE,
REFERENCE_CONVERSION_CONST_LVALUE, CV_CONVERSION_BADNESS,
CV_CONVERSION_CONST, CV_CONVERSION_VOLATILE): Declare.
gdb/testsuite/ChangeLog
* gdb.cp/oranking.cc (test15): New function.
(main): Call test15 and declare additional variables for testing.
* gdb.cp/oranking.exp: Remove kfail status for "p foo4(&a)" and
"p foo101('abc')" tests.
* gdb.cp/rvalue-ref-overloads.exp: Remove kfail status for
"lvalue reference overload" test.
* gdb.cp/rvalue-ref-params.exp: Remove kfail status for
"print value of f1 on Child&& in f2" test.
This patch fixes an internal error exposed by a test that does
something like:
define kill-and-remove
kill inferiors 2
remove-inferiors 2
end
# Start one inferior.
start
# Start another inferior.
add-inferior 2
inferior 2
start
# Kill and remove inferior 1 while inferior 2 is selected.
thread apply 1.1 kill-and-remove
The internal error looks like this:
Thread 1.1 (Thread 0x7ffff7fc2700 (LWP 20677)):
[Switching to inferior 1 [process 20677] (gdb/testsuite/outputs/gdb.threads/threadapply/threadapply)]
[Switching to thread 1.1 (Thread 0x7ffff7fc2700 (LWP 20677))]
#0 main () at src/gdb/testsuite/gdb.threads/threadapply.c:38
38 for (i = 0; i < NUM; i++)
src/gdb/inferior.c:66: internal-error: void set_current_inferior(inferior*): Assertion `inf != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/threadapply.exp: kill_and_remove_inferior: try kill-and-remove: thread apply 1.1 kill-and-remove (GDB internal error)
There are several problems around this area of the code. One is that
in do_restore_current_thread_cleanup, we do a look up of inferior by
ptid, which can find the wrong inferior if the previously selected
inferior exited and some other inferior was started with a reused pid
(rare, but still...).
The other problem is that the "remove-inferiors" command rejects
attempts to remove the current inferior, but when we get to
"remove-inferiors" in a "thread apply THR remove-inferiors 2" command,
the current inferior is the inferior of thread THR, not the previously
selected inferior, so if the previously selected inferior was inferior
2, that command still manages to wipe it, and then gdb restores the
old selected inferior, which is now a dangling pointer...
So the fix here is:
- Make make_cleanup_restore_current_thread store a pointer to the
previously selected inferior directly, and use it directly instead
of doing ptid look ups.
- Add a refcount to inferiors, very similar to thread_info's refcount,
that is incremented/decremented by
make_cleanup_restore_current_thread, and checked before deleting an
inferior. To avoid duplication, a new refcounted_object type is
added, that both thread_info and inferior inherit from.
gdb/ChangeLog:
2017-04-19 Pedro Alves <palves@redhat.com>
* common/refcounted-object.h: New file.
* gdbthread.h: Include "common/refcounted-object.h".
(thread_info): Inherit from refcounted_object and add comments.
(thread_info::incref, thread_info::decref)
(thread_info::m_refcount): Delete.
(thread_info::deletable): Use the refcounted_object::refcount()
method.
* inferior.c (current_inferior_): Add comment.
(set_current_inferior): Increment/decrement refcounts.
(prune_inferiors, remove_inferior_command): Skip inferiors marked
not-deletable instead of comparing with the current inferior.
(initialize_inferiors): Increment the initial inferior's refcount.
* inferior.h (struct inferior): Forward declare.
Include "common/refcounted-object.h".
(current_inferior, set_current_inferior): Move declaration to
before struct inferior's definition, and fix comment.
(inferior): Inherit from refcounted_object. Add comments.
* thread.c (switch_to_thread_no_regs): Reference the thread's
inferior pointer directly instead of doing a ptid lookup.
(switch_to_no_thread): New function.
(switch_to_thread(thread_info *)): New function, factored out
from ...
(switch_to_thread(ptid_t)): ... this.
(restore_current_thread): Delete.
(current_thread_cleanup): Remove 'inf_id' and 'was_removable'
fields, and add 'inf' field.
(do_restore_current_thread_cleanup): Check whether old->inf is
alive instead of looking up an inferior by ptid. Use
switch_to_thread and switch_to_no_thread.
(restore_current_thread_cleanup_dtor): Use old->inf directly
instead of lookup up an inferior by id. Decref the inferior.
Don't restore 'removable'.
(make_cleanup_restore_current_thread): Same the inferior pointer
in old, instead of the inferior number. Incref the inferior.
Don't save/clear 'removable'.
gdb/testsuite/ChangeLog:
2017-04-19 Pedro Alves <palves@redhat.com>
* gdb.threads/threadapply.exp (kill_and_remove_inferior): New
procedure.
(top level): Call it.
* lib/gdb.exp (gdb_define_cmd): New procedure.
- Make sure we end up with no thread selected after the detach.
- Test both "thread apply all" and "thread apply $some_threads", for
completeness.
gdb/ChangeLog:
2017-04-13 Pedro Alves <palves@redhat.com>
PR threads/13217
* gdb.threads/threadapply.exp (thr_apply_detach): New procedure.
(top level): Call it twice, with different thread sets.
GDB is currently not aware that wchar_t is a built-in type in C++
mode. This is usually not a problem because the debug info describes
the type, so when you have a program loaded, you don't notice this.
However, if you try expressions involving wchar_t before a program is
loaded, gdb errors out:
(gdb) p (wchar_t)-1
No symbol table is loaded. Use the "file" command.
(gdb) p L"hello"
No type named wchar_t.
(gdb) ptype L"hello"
No type named wchar_t.
This commit teaches gdb about the type. After:
(gdb) p (wchar_t)-1
$1 = -1 L'\xffffffff'
(gdb) p L"hello"
$2 = L"hello"
(gdb) ptype L"hello"
type = wchar_t [6]
Unlike char16_t/char32_t, unfortunately, the underlying type of
wchar_t is implementation dependent, both size and signness. So this
requires adding a couple new gdbarch hooks.
I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it
seems to me that the majority of the ABIs have a 4-byte signed
wchar_t, so that's what I made the default for GDB too. And then I
looked for which ports have a 16-bit and/or unsigned wchar_t, and made
GDB follow suit.
gdb/ChangeLog:
2017-04-12 Pedro Alves <palves@redhat.com>
PR gdb/21323
* c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>:
New enum value.
(cplus_language_arch_info): Register cplus_primitive_type_wchar_t.
* gdbtypes.h (struct builtin_type) <builtin_wchar>: New field.
* gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type.
* gdbarch.sh (wchar_bit, wchar_signed): New per-arch values.
* gdbarch.h, gdbarch.c: Regenerate.
* aarch64-tdep.c (aarch64_gdbarch_init): Override
gdbarch_wchar_bit and gdbarch_wchar_signed.
* alpha-tdep.c (alpha_gdbarch_init): Likewise.
* arm-tdep.c (arm_gdbarch_init): Likewise.
* avr-tdep.c (avr_gdbarch_init): Likewise.
* h8300-tdep.c (h8300_gdbarch_init): Likewise.
* i386-nto-tdep.c (i386nto_init_abi): Likewise.
* i386-tdep.c (i386_go32_init_abi): Likewise.
* m32r-tdep.c (m32r_gdbarch_init): Likewise.
* moxie-tdep.c (moxie_gdbarch_init): Likewise.
* nds32-tdep.c (nds32_gdbarch_init): Likewise.
* rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise.
* sh-tdep.c (sh_gdbarch_init): Likewise.
* sparc-tdep.c (sparc32_gdbarch_init): Likewise.
* sparc64-tdep.c (sparc64_init_abi): Likewise.
* windows-tdep.c (windows_init_abi): Likewise.
* xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise.
gdb/testsuite/ChangeLog:
2017-04-12 Pedro Alves <palves@redhat.com>
PR gdb/21323
* gdb.cp/wide_char_types.c: Include <wchar.h>.
(wchar): New global.
* gdb.cp/wide_char_types.exp (wide_char_types_program)
(do_test_wide_char, wide_char_types_no_program, top level): Add
wchar_t testing.
While the C++ standard says that char16_t and char32_t are unsigned types:
Types char16_t and char32_t denote distinct types with the same size,
signedness, and alignment as uint_least16_t and uint_least32_t,
respectively, in <cstdint>, called the underlying types.
... gdb treats them as signed currently:
(gdb) p (char16_t)-1
$1 = -1 u'\xffff'
There are actually two places in gdb that hardcode these types:
- gdbtypes.c:gdbtypes_post_init, when creating the built-in types,
seemingly used by the "x /s" command (judging from commit 9a22f0d0).
- dwarf2read.c, when reading base types with DW_ATE_UTF encoding
(which is what is used for these types, when compiling for C++11 and
up). Despite the comment, the type created does end up used.
Both places need fixing. But since I couldn't tell why dwarf2read.c
needs to create a new type, I've made it use the per-arch built-in
types instead, so that the types are only created once per arch
instead of once per objfile. That seems to work fine.
While writting the test, I noticed that the C++ language parser isn't
actually aware of these built-in types, so if you try to use them
without a program that uses them, you get:
(gdb) set language c++
(gdb) ptype char16_t
No symbol table is loaded. Use the "file" command.
(gdb) ptype u"hello"
No type named char16_t.
(gdb) p u"hello"
No type named char16_t.
That's fixed by simply adding a couple entries to C++'s built-in types
array in c-lang.c. With that, we get the expected:
(gdb) ptype char16_t
type = char16_t
(gdb) ptype u"hello"
type = char16_t [6]
(gdb) p u"hello"
$1 = u"hello"
gdb/ChangeLog:
2017-04-12 Pedro Alves <palves@redhat.com>
PR c++/21323
* c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t,
cplus_primitive_type_char32_t>: New enum values.
(cplus_language_arch_info): Register cplus_primitive_type_char16_t
and cplus_primitive_type_char32_t.
* dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or
32, use the archtecture's built-in type for char16_t and char32_t,
respectively. Otherwise, fallback to init_integer_type as before,
but make the type unsigned, and issue a complaint.
* gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned.
gdb/testsuite/ChangeLog:
2017-04-12 Pedro Alves <palves@redhat.com>
PR c++/21323
* gdb.cp/wide_char_types.c: New file.
* gdb.cp/wide_char_types.exp: New file.
This commit adds a test for the fix of PR 21352.
gdb/testsuite/ChangeLog:
2017-04-05 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21352
* gdb.trace/tsv.exp: Add test for "tsave -r".
I see the following test fail from time to time, due to the racy test
in gdb.threads/thread-specific-bp.exp.
continue -a^M
Continuing.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at binutils-gdb/gdb/testsuite/gdb.threads/thread-specific-bp.c:29^M
29 }^M
(gdb) [Thread 0x40322460 (LWP 12950) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
FAIL: gdb.threads/thread-specific-bp.exp: non-stop: continue to end (timeout)
This patch changes gdb_test to gdb_test_multiple to match prompt only
instead of both prompt and anchor.
gdb/testsuite:
2017-04-05 Yao Qi <yao.qi@linaro.org>
* gdb.threads/thread-specific-bp.exp (check_thread_specific_breakpoint):
Use gdb_test_multiple, and don't match anchor.
The two-tier lexer in gdb/d-exp.y, which resolves fully qualified names
missed a case where `module.type' was not being classified as one token.
And so when the grammar takes over, it matched the remaining tokens
against the rule `TypeExp . IdentifierExp', where we were expecting to
instead match cast expression `( TypeExp ) UnaryExpression'.
Adding a case for TYPE_CODE_MODULE in type_aggregate_p means that
classify_inner_name will get a chance to lookup the symbol.
This was noticed when using `watch -l', and got the rather confusing
response:
A syntax error in expression, near `) 0x0add4e55'.
So it's been included in the testsuite, along with another test that
does effectively the same expression, but explicitly.
gdb/ChangeLog:
* d-exp.y (type_aggregate_p): Treat TYPE_CODE_MODULE as being
aggregate-like.
gdb/testsuite/ChangeLog:
* gdb.dlang/watch-loc.c: New file.
* gdb.dlang/watch-loc.exp: New file.
$ gdb rustc
Reading symbols from rustc...Reading symbols from /usr/lib/debug/usr/bin/rustc.debug...done.
done.
warning: Invalid entry in .debug_gdb_scripts section
/usr/bin/rustc
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[15] .debug_gdb_scripts PROGBITS 00000000000008ed 0008ed 000022 00 AMS 0 0 1
/usr/lib/debug/usr/bin/rustc.debug
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[15] .debug_gdb_scripts NOBITS 00000000000008ed 000280 000022 00 AMS 0 0 1
There remains questionable whether bfd_get_section_by_name() should not return
an error for !SEC_LOAD but I haven't investigated that.
gdb/ChangeLog
2017-03-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* auto-load.c (auto_load_section_scripts): Check SEC_HAS_CONTENTS.
gdb/testsuite/ChangeLog
2017-03-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-section-script.exp (sepdebug): New testcases.
Add a prologue analysis that recognizes all instructions that may happen in
compiler-generated prologue, including various stores, core register moves,
subtraction and ENTER_S instruction that does a lot of prologue actions through
microcode.
Testcases cover various prologue scenarios, including instructions that are
spread across multiple 16-bit encodings (for example there are 7 encodings of
store instruction).
gdb/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* arc-tdep.c (arc_frame_cache): Add support for prologue analysis.
(arc_skip_prologue): Likewise.
(arc_make_frame_cache): Likewise.
(arc_pv_get_operand): New function.
(arc_is_in_prologue): Likewise.
(arc_analyze_prologue): Likewise.
(arc_print_frame_cache): Likewise.
(MAX_PROLOGUE_LENGTH): New constant.
gdb/doc/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* gdb.texinfo (Synopsys ARC): Document "set debug arc 2".
gdb/testsuite/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* gdb.arch/arc-analyze-prologue.S: New file.
* gdb.arch/arc-analyze-prologue.exp: Likewise.
Add disassembler helper for GDB, that uses opcodes structure arc_instruction
and adds convenience functions to handle instruction operands. This interface
solves at least those problems with arc_instruction:
* Some instructions, like "push_s", have implicit operands which are not
directly present in arc_instruction.
* Operands of particular meaning, like branch/jump targets, have various
locations and meaning depending on type of branch/target.
* Access to operand value is abstracted into a separate function, so callee
code shouldn't bother if operand value is an immediate value or in a
register.
Testcases included in this commit are fairly limited - they test exclusively
branch instructions, something that will be used in software single stepping.
Most of the other parts of this disassembler helper are tested during prologue
analysis testing.
gdb/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* configure.tgt: Add arc-insn.o.
* arc-tdep.c (arc_delayed_print_insn): Make non-static.
(dump_arc_instruction_command): New function.
(arc_fprintf_disasm): Likewise.
(arc_disassemble_info): Likewise.
(arc_insn_get_operand_value): Likewise.
(arc_insn_get_operand_value_signed): Likewise.
(arc_insn_get_memory_base_reg): Likewise.
(arc_insn_get_memory_offset): Likewise.
(arc_insn_get_branch_target): Likewise.
(arc_insn_dump): Likewise.
(arc_insn_get_linear_next_pc): Likewise.
* arc-tdep.h (arc_delayed_print_insn): Add function declaration.
(arc_disassemble_info): Likewise.
(arc_insn_get_branch_target): Likewise.
(arc_insn_get_linear_next_pc): Likewise.
* NEWS: Mention new "maint print arc arc-instruction".
gdb/doc/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* gdb.texinfo (Synopsys ARC): Add "maint print arc arc-instruction".
gdb/testsuite/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* gdb.arch/arc-decode-insn.S: New file.
* gdb.arch/arc-decode-insn.exp: Likewise.
While at it, decode also properly one-bit flags for %fsr (accrued and
current exception flags were mixed up).
ChangeLog entry:
2017-03-21 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20928
* gdb/sparc-tdep.h (gdbarch_tdep) <sparc64_ccr_type>: New field.
* gdb/sparc64-tdep.c (sparc64_ccr_type): New function.
(sparc64_fsr_type): Fix %fsr decoding.
ChangeLog entry for testsuite:
2017-03-21 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20928
* gdb.arch/sparc64-regs.exp: New file.
* gdb.arch/sparc64-regs.S: Likewise.
This changes the return type of "gdb.BtraceInstruction.data ()" from
"memoryview" to "buffer" on Python 2.7 and below, similar to what
"gdb.Inferior.read_memory ()" does.
This patch adds tests for the initial rvalue reference support patchset. All
of the new tests are practically mirrored regular references tests and, except
for the demangler ones, are introduced in new files, which are set to be
compiled with -std=gnu++11. Tested are printing of rvalue reference types and
values, rvalue reference parameters in function overloading, demangling of
function names containing rvalue reference parameters, casts to rvalue
reference types, application of the sizeof operator to rvalue reference types
and values, and support for rvalue references within the gdb python module.
gdb/ChnageLog
PR gdb/14441
* NEWS: Mention support for rvalue references in GDB and python.
* doc/gdb.texinfo (C Plus Plus Expressions): Mention that GDB
supports both lvalue and rvalue references.
gdb/testsuite/ChangeLog
PR gdb/14441
* gdb.cp/demangle.exp: Add rvalue reference tests.
* gdb.cp/rvalue-ref-casts.cc: New file.
* gdb.cp/rvalue-ref-casts.exp: New file.
* gdb.cp/rvalue-ref-overload.cc: New file.
* gdb.cp/rvalue-ref-overload.exp: New file.
* gdb.cp/rvalue-ref-params.cc: New file.
* gdb.cp/rvalue-ref-params.exp: New file.
* gdb.cp/rvalue-ref-sizeof.cc: New file.
* gdb.cp/rvalue-ref-sizeof.exp: New file.
* gdb.cp/rvalue-ref-types.cc: New file.
* gdb.cp/rvalue-ref-types.exp: New file.
* gdb.python/py-rvalue-ref-value-cc.cc: New file.
* gdb.python/py-rvalue-ref-value-cc.exp: New file.
This change adds the MI equivalent for the "info sharedlibrary"
command. The command was already partially documented but ignored as
it was not implemented. The new MI command works similarly to the CLI
command, taking an optional regular expression as an argument and
outputting the library information.
I included a test for the new command in mi-solib.exp.
gdb/doc/ChangeLog:
* gdb.texinfo (gdb/mi Symbol Query Commands): Document new MI
command file-list-shared-libraries
(GDB/MI Async Records): Update documentation of library-loaded with new
field.
gdb/ChangeLog:
* NEWS: Add an entry about new '-file-list-shared-libraries' command.
* mi/mi-cmd-file.c (mi_cmd_file_list_shared_libraries):
New function definition.
* mi/mi-cmds.c (mi_cmds): Add -file-list-shared-libraries command.
* mi/mi-cmds.h (mi_cmd_file_list_shared_libraries):
New function declaration.
* mi/mi-interp.c (mi_output_solib_attribs): New Function.
* mi/mi-interp.h: New file.
* solib.c (info_sharedlibrary_command): Replace for loop with
ALL_SO_LIBS macro
* solib.h (update_solib_list): New function declaration.
(so_list_head): Move macro.
* solist.h (ALL_SO_LIBS): New macro.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-solib.exp (test_file_list_shared_libraries):
New procedure.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
When using mi_gdb_test, if it fails because of the presence of
unexpected output, the error message is only the message passed as
the argument with no indication that there was an unexpected output.
This change adds an additional text to the failure message to
indicate that there was an unexpected output.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_gdb_test): Add additional message
for unexpected output.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
The test case examine-backward.exp issues the command "x/-s" after the end
of the first string in TestStrings, but without making sure that this
string is preceded by a string terminator. Thus GDB may spuriously print
some random characters from before that string, and then the test fails.
This patch assures that TestStrings is preceded by a string terminator.
gdb/testsuite/ChangeLog:
* gdb.base/examine-backward.c (Barrier): New character array
constant, to ensure that TestStrings is preceded by a string
terminator.
Recently I fixed a bug that caused a DW_OP_implicit_pointer with non-zero
offset into a DW_OP_implicit_value to be handled incorrectly on big-endian
targets. GDB ignored the offset and copied the wrong bytes:
https://sourceware.org/ml/gdb-patches/2017-01/msg00251.html
But there is still a similar issue when a DW_OP_implicit_pointer points
into a DW_OP_stack_value instead; and again, the offset is ignored. There
is an important difference, though: While implicit values are treated like
blocks of data and anchored at the lowest-addressed byte, stack values
traditionally contain integer numbers and are anchored at the *least
significant* byte. Also, stack values do not come in varying sizes, but
are cut down appropriately when used. Thus, on big-endian targets the
scenario looks like this (higher addresses shown right):
|<- - - - - Stack value - - - - - - ->|
| |
|<- original object ->|
|
| offset ->|####|
^^^^
de-referenced
implicit pointer
(Note how the original object's size influences the position of the
de-referenced implicit pointer within the stack value. This is not the
case for little-endian targets, where the original object starts at offset
zero within the stack value.)
This patch implements the logic indicated in the above diagram and adds an
appropriate test case. A new function dwarf2_fetch_die_type_sect_off is
added; it is used for retrieving the original object's type, so its size
can be determined. That type is passed to dwarf2_evaluate_loc_desc_full
via a new parameter.
gdb/ChangeLog:
* dwarf2loc.c (indirect_synthetic_pointer): Get data type of
pointed-to DIE and pass it to dwarf2_evaluate_loc_desc_full.
(dwarf2_evaluate_loc_desc_full): New parameter subobj_type; rename
byte_offset to subobj_byte_offset. Fix the handling of
DWARF_VALUE_STACK on big-endian targets when coming via an
implicit pointer.
(dwarf2_evaluate_loc_desc): Adjust call to
dwarf2_evaluate_loc_desc_full.
* dwarf2loc.h (dwarf2_fetch_die_type_sect_off): New declaration.
* dwarf2read.c (dwarf2_fetch_die_type_sect_off): New function.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp: Add support for DW_OP_implicit_pointer.
* gdb.dwarf2/nonvar-access.exp: Add test for stack value location
and implicit pointer into such a location.
This patch keeps the Scheme side of lazy string handling in sync
with the python size, bringing over fixes for
PRs python/17728, python/18439, python/18779.
gdb/ChangeLog:
* guile/scm-lazy-string.c (lazy_string_smob): Clarify use of LENGTH
member. Change type of TYPE member to SCM. All uses updated.
(lsscm_make_lazy_string_smob): Add assert.
(lsscm_make_lazy_string): Flag bad length values.
(lsscm_elt_type): New function.
(gdbscm_lazy_string_to_value): Rewrite to use
lsscm_safe_lazy_string_to_value.
(lsscm_safe_lazy_string_to_value): Fix handling of TYPE_CODE_PTR.
* guile/scm-value.c (gdbscm_value_to_lazy_string): Flag bad length
values. Fix TYPE_CODE_PTR. Handle TYPE_CODE_ARRAY. Handle typedefs
in incoming type.
* guile/guile-internal.h (tyscm_scm_to_type): Declare.
* guile/scm-type.c (tyscm_scm_to_type): New function.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-value.c (main) Delete locals sptr, sn.
* gdb.guile/scm-lazy-string.c: New file.
* gdb.guile/scm-value.exp: Move lazy string tests to ...
* gdb.guile/scm-lazy-string.exp: ... here, new file. Add more tests
for pointer, array, typedef lazy strings.
gdb/ChangeLog:
PR python/17728, python/18439, python/18779
* python/py-lazy-string.c (lazy_string_object): Clarify use of LENGTH
member. Change type of TYPE member to PyObject *. All uses updated.
(stpy_convert_to_value): Fix handling of TYPE_CODE_PTR.
(gdbpy_create_lazy_string_object): Flag bad length values.
Handle TYPE_CODE_ARRAY with possibly different user-provided length.
Handle typedefs in incoming type.
(stpy_lazy_string_elt_type): New function.
(gdbpy_extract_lazy_string): Call it.
* python/py-value.c (valpy_lazy_string): Flag bad length values.
Fix handling of TYPE_CODE_PTR. Handle TYPE_CODE_ARRAY. Handle
typedefs in incoming type.
gdb/testsuite/ChangeLog:
PR python/17728, python/18439, python/18779
* gdb.python/py-value.c (main) Delete locals sptr, sn.
* gdb.python/py-lazy-string.c (pointer): New typedef.
(main): New locals ptr, array, typedef_ptr.
* gdb.python/py-value.exp: Move lazy string tests to ...
* gdb.python/py-lazy-string.exp: ... here. Add more tests for pointer,
array, typedef lazy strings.
The expectation in gdb.cp/m-static.exp for the ptype of
single_constructor is to get in the result of destructor with the
following prototype: ~single_constructor(int).
Yet, m-static.cc declares the destructor as ~single_constructor(). This
commit fixes the expectation.
2017-03-16 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/testsuite/
* gdb.cp/m-static.exp: Fix expectation for prototype of
test5.single_constructor and single_constructor::single_constructor.
An optional parameter TEST has been added to get_hexadecimal_valueof in commit:
https://sourceware.org/ml/gdb-patches/2016-06/msg00469.html
This patch adds a similar optional parameter to other related methods that
retrieve expression values: get_valueof, get_integer_valueof and get_sizeof.
Thus tests that evaluate same expression multiple times can provide custom
test names, ensuring that test names will be unique.
gdb/testsuite/ChangeLog:
2017-03-14 Anton Kolesov <anton.kolesov@synopsys.com>
* lib/gdb.exp (get_valueof, get_integer_valueof, get_sizeof):
Add optional 'test' parameter.
I noticed that backslash_in_multi_line_command_test in
gdb.base/commands.exp failed on our RHEL6 servers. I traced it to the
old version of DejaGnu (1.4.4). I have found that instead of receiving
the expected:
"print \\\nargc\n"
gdb received:
"print argc\n"
thus breaking the test and its purpose. Versionof DejaGnu < 1.5 mess
up sending "\\\n", it somehow gets replaced with a space. I found that
the following commit in DejaGnu fixed the issue:
http://git.savannah.gnu.org/cgit/dejagnu.git/commit/lib/remote.exp?id=3f39294f5cd6802858838d3bcc0ccce847ae17f2
Even though the commit is almost 10 years old, the following release of
DejaGnu was only in 2013, which is why we still have systems with the
old code.
If the DejaGnu version is < 1.5, we just skip the test.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (backslash_in_multi_line_command_test):
Skip for versions of DejaGnu < 1.5.
The next patch will require checking the DejaGnu version. There is
already a test that does this,
gdb.threads/attach-many-short-lived-threads.exp. This patch introduces
a new procedure, dejagnu_version, and makes that test use it.
The version number is "right-padded" with zeroes, to make sure that we
always return a triplet (major, minor, patch).
The procedure does not consider the DejaGnu versions from git. For
example, if you used DejaGnu from its current master branch, the version
would be "1.6.1-git", meaning that 1.6.1 will be the next release. I
figured we'll cross that bridge when (and if) we get there.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (dejagnu_version): New proc.
* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
Use dejagnu_version.
For a long time now, c++/8218 has noted that GDB is printing argument types
for destructors:
(gdb) ptype A
type = class A {
public:
~A(int);
}
This happens because cp_type_print_method_args doesn't ignore artificial
arguments. [It ignores the first `this' pointer because it simply skips
the first argument for any non-static function.]
This patch fixes this:
(gdb) ptype A
type = class A {
public:
~A();
}
I've adjusted gdb.cp/templates.exp to account for this and added a new
passing regexp.
gdb/ChangeLog
PR c++/8218
* c-typeprint.c (cp_type_print_method_args): Skip artificial arguments.
gdb/testsuite/ChangeLog
PR c++/8128
* gdb.cp/templates.exp (test_ptype_of_templates): Remove argument
type from destructor regexps.
Add a branch which actually passes the test.
Adjust "ptype t5i" test names.
Currently diffing testrun results shows:
-PASS: gdb.base/step-over-exit.exp: break *0x7ffff77e18c6 if main == 0
+PASS: gdb.base/step-over-exit.exp: break *0x2aaaab0988c6 if main == 0
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/step-over-exit.exp: Add explicit test message.
If you do "interrupt -a" just while some thread is stepping over a
breakpoint, gdb trips on an internal error.
The test added by this patch manages to trigger this consistently by
spawning a few threads that are constantly tripping on a conditional
breakpoint whose condition always evaluates to false. With current
gdb, you get:
~~~
interrupt -a
.../src/gdb/inline-frame.c:343: internal-error: void skip_inline_frames(ptid_t): Assertion `find_inline_frame_state (ptid) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=on: iter=0: interrupt -a (GDB internal error)
[...]
.../src/gdb/inline-frame.c:343: internal-error: void skip_inline_frames(ptid_t): Assertion `find_inline_frame_state (ptid) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=off: iter=0: wait for stops (GDB internal error)
~~~
The assertion triggers because we're processing a stop for a thread
that had already stopped before and thus had already its inline-frame
state filled in.
Calling handle_inferior_event_1 directly within a
"thread_stop_requested" observer is something that I've wanted to get
rid of before, for being fragile. Nowadays, infrun is aware of
threads with pending events, so we can use that instead, and let the
normal fetch_inferior_event -> handle_inferior_event code path handle
the forced stop.
The change to finish_step_over is necessary because sometimes a thread
that was told to PTRACE_SINGLESTEP reports back a SIGSTOP instead of a
SIGTRAP (i.e., we tell it to single-step, and then interrupt it quick
enough that on the kernel side the thread dequeues the SIGTOP before
ever having had a chance of executing the instruction to be stepped).
SIGSTOP gets translated to a GDB_SIGNAL_0. And then finish_step_over
would miss calling clear_step_over_info, and thus miss restarting the
other threads (which in this case of threads with pending events,
means setting their "resumed" flag, so their pending events can be
consumed).
And now that we always restart threads in finish_step_over, we no
longer need to do that in handle_signal_stop.
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR gdb/18360
* infrun.c (start_step_over, do_target_resume, resume)
(restart_threads): Assert we're not resuming a thread that is
meant to be stopped.
(infrun_thread_stop_requested_callback): Delete.
(infrun_thread_stop_requested): If the thread is internally
stopped, queue a pending stop event and clear the thread's
inline-frame state.
(handle_stop_requested): New function.
(handle_syscall_event, handle_inferior_event_1): Use
handle_stop_requested.
(handle_stop_requested): New function.
(handle_signal_stop): Set the thread's stop_signal here instead of
at caller.
(finish_step_over): Clear step over info unconditionally.
(handle_signal_stop): If the user had interrupted the event
thread, consider the stop a random signal.
(handle_signal_stop) <signal arrived while stepping over
breakpoint>: Don't restart threads here.
(stop_waiting): Don't clear step-over info here.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR gdb/18360
* gdb.threads/interrupt-while-step-over.c: New file.
* gdb.threads/interrupt-while-step-over.exp: New file.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.arch/amd64-entry-value-param-dwarf5.exp: Use with_test_prefix.
* gdb.arch/amd64-entry-value-param.exp: Use with_test_prefix.
Currently I get:
(gdb) print have_pkru()
$1 = 0
(gdb) FAIL: gdb.arch/i386-pkru.exp: probe PKRU support
UNSUPPORTED: gdb.arch/i386-pkru.exp: processor does not support protection key feature.
Probing suceeded, so that should be a PASS -> UNSUPPORTED.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-pkru.exp (probe PKRU support): Handle detecting
PKRU as not supported as a PASS.
Avoid putting unstable path names in test messages, in order to avoid
spurious testrun result diffs like:
[....]
-PASS: gdb.base/break-fun-addr.exp: /home/pedro/gdb/test-build1/gdb/testsuite/outputs/gdb.base/break-fun-addr/break-fun-addr1: break *main
+PASS: gdb.base/break-fun-addr.exp: /home/pedro/gdb/test-build2/gdb/testsuite/outputs/gdb.base/break-fun-addr/break-fun-addr1: break *main
[....]
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/break-fun-addr.exp: Use $testfile1/$testfile2 for test
prefix instead of $binfile1/$binfile2.
* gdb.btrace/gcore.exp: Use "core" instead of unstable path name
in test message.
* gdb.python/py-completion.exp: Use "load python file" as test
messages instead of unstable path names.
With commit 3b12939dfc ("Replace the sync_execution global with a
new enum prompt_state tristate"), GDB started aborting if you try
splitting an input line with a continuation char (backslash) while in
a multi-line command:
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>print \
(gdb) 1 # note "(gdb)" incorrectly printed here.
>end
readline: readline_callback_read_char() called with no handler!
$
That abort is actually a symptom of an old problem introduced when
gdb_readline_wrapper was rewritten to use asynchronous readline, back
in 2007. Note how the "(gdb)" prompt is printed above in the "(gdb)
1" line. Clearly it shouldn't be there, but it already was before the
commit mentioned above. Fixing that also fixes the readline abort
shown above.
The problem starts when command_line_input passes a NULL prompt to
gdb_readline_wrapper when it finds previous incomplete input due to a
backslash, trying to fetch more input without printing another ">"
secondary prompt. That itself should not be a problem, because
passing NULL to gdb_readline_wrapper has the same meaning as passing a
pointer to empty string, since gdb_readline_wrapper exposes the same
interface as 'readline(char *)'. However, gdb_readline_wrapper passes
the prompt argument directly to display_gdb_prompt, and for the
latter, a NULL prompt argument has a different meaning - it requests
printing the primary prompt.
Before commit 782a7b8ef9c096 (which rewrote gdb_readline_wrapper to
use asynchronous readline), GDB behaved like this:
(gdb) commands
[....]
>print \
1
>end
(gdb)
The above is what this commit restores GDB back to.
New test included.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR cli/21218
* top.c (gdb_readline_wrapper): Avoid passing NULL to
display_gdb_prompt.
(command_line_input): Add comment.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR cli/21218
* gdb.base/commands.exp (backslash_in_multi_line_command_test):
New proc.
(top level): Call it.
Commit d7e747318f ("Eliminate make_cleanup_ui_file_delete / make
ui_file a class hierarchy") regressed the TUI's command window.
Newlines miss doing a "carriage return", resulting in output like:
~~~~~~~~~~~~~~~~~~
(gdb) helpList of classes of commands:
aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before the commit mentioned above, the default ui_file->to_write
implementation had a hack that would defer into the ui_file->to_fputs
method. The TUI's ui_file did not implement the to_write method, so
all writes would end up going to the ncurses window via tui_file_fputs
-> tui_puts.
After the commit above, the hack is gone, but the TUI's ui_file still
does not implement the ui_file::write method. Since tui_file inherits
from stdio_file, writing to a tui_file ends up doing fwrite on the
FILE stream the TUI is "associated" with, via stdio_file::write,
instead of writing to the ncurses window.
The fix is to have tui_file override the "write" method.
New test included.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR tui/21216
* tui/tui-file.c (tui_file::write): New.
* tui/tui-file.h (tui_file): Override "write".
* tui/tui-io.c (do_tui_putc, update_start_line): New functions,
factored out from ...
(tui_puts): ... here.
(tui_putc): Use them.
(tui_write): New function.
* tui/tui-io.h (tui_write): Declare.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR tui/21216
* gdb.tui/tui-nl-filtered-output.exp: New file.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/completion.exp: Move TUI completion tests to ...
* gdb.tui/completion.exp: ... this new file.
Let's start putting TUI tests in their own dir.
gdb/testsuite/
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/tui-disasm-long-lines.c,
gdb.base/tui-disasm-long-lines.exp, gdb.base/tui-layout.c,
gdb.base/tui-layout.exp: Move to ...
* gdb.tui/: ... this new directory.
Commit d7e747318f ("Eliminate make_cleanup_ui_file_delete / make
ui_file a class hierarchy") introduced a problem when using "layout
regs", that leads gdb to crash when issuing:
./gdb ./a.out -ex 'layout regs' -ex start
From the backtrace, it's caused by this 'delete' on tui_restore_gdbout():
(gdb) bt
#0 0x00007ffff6b962b2 in free () from /lib64/libc.so.6
#1 0x000000000059fa47 in tui_restore_gdbout (ui=0x22997b0) at ../../gdb/tui/tui-regs.c:714
#2 0x0000000000619996 in do_my_cleanups (pmy_chain=pmy_chain@entry=0x1e08320 <cleanup_chain>, old_chain=old_chain@entry=0x235b4b0) at ../../gdb/common/cleanups.c:154
#3 0x0000000000619b1d in do_cleanups (old_chain=old_chain@entry=0x235b4b0) at ../../gdb/common/cleanups.c:176
#4 0x000000000059fb0d in tui_register_format (frame=frame@entry=0x22564e0, regnum=regnum@entry=0) at ../../gdb/tui/tui-regs.c:747
#5 0x000000000059ffeb in tui_get_register (data=0x2434d18, changedp=0x0, regnum=0, frame=0x22564e0) at ../../gdb/tui/tui-regs.c:768
#6 tui_show_register_group (refresh_values_only=<optimized out>, frame=0x22564e0, group=0x1e09250 <general_group>) at ../../gdb/tui/tui-regs.c:287
#7 tui_show_registers (group=0x1e09250 <general_group>) at ../../gdb/tui/tui-regs.c:156
#8 0x00000000005a07cf in tui_check_register_values (frame=frame@entry=0x22564e0) at ../../gdb/tui/tui-regs.c:496
#9 0x00000000005a3e65 in tui_check_data_values (frame=frame@entry=0x22564e0) at ../../gdb/tui/tui-windata.c:232
#10 0x000000000059cf65 in tui_refresh_frame_and_register_information (registers_too_p=1) at ../../gdb/tui/tui-hooks.c:156
#11 0x00000000006d5c05 in generic_observer_notify (args=0x7fffffffdbe0, subject=<optimized out>) at ../../gdb/observer.c:167
#12 observer_notify_normal_stop (bs=<optimized out>, print_frame=print_frame@entry=1) at ./observer.inc:61
#13 0x00000000006a6409 in normal_stop () at ../../gdb/infrun.c:8364
#14 0x00000000006af8f5 in fetch_inferior_event (client_data=<optimized out>) at ../../gdb/infrun.c:3990
#15 0x000000000066f0fd in gdb_wait_for_event (block=block@entry=0) at ../../gdb/event-loop.c:859
#16 0x000000000066f237 in gdb_do_one_event () at ../../gdb/event-loop.c:322
#17 0x000000000066f386 in gdb_do_one_event () at ../../gdb/event-loop.c:353
#18 0x00000000007411bc in wait_sync_command_done () at ../../gdb/top.c:570
#19 0x0000000000741426 in maybe_wait_sync_command_done (was_sync=0) at ../../gdb/top.c:587
#20 execute_command (p=<optimized out>, p@entry=0x7fffffffe43a "start", from_tty=from_tty@entry=1) at ../../gdb/top.c:676
#21 0x00000000006c2048 in catch_command_errors (command=0x741200 <execute_command(char*, int)>, arg=0x7fffffffe43a "start", from_tty=1) at ../../gdb/main.c:376
#22 0x00000000006c2b60 in captured_main_1 (context=0x7fffffffde70) at ../../gdb/main.c:1119
#23 captured_main (data=0x7fffffffde70) at ../../gdb/main.c:1140
#24 gdb_main (args=args@entry=0x7fffffffdf90) at ../../gdb/main.c:1158
#25 0x0000000000408cf5 in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:32
(gdb) f 1
#1 0x000000000059fa47 in tui_restore_gdbout (ui=0x22997b0) at ../../gdb/tui/tui-regs.c:714
714 delete gdb_stdout;
The problem is simply that the commit mentioned above made the ui_file
that gdb_stdout is temporarily set to be a stack-allocated
string_file, while before it used to be a heap-allocated ui_file. The
fix is simply to remove the now-incorrect delete.
New test included, which exercises enabling all TUI layouts, with and
without execution. (This particular crash only triggers with
execution.)
gdb/ChangeLog:
2017-03-07 Pedro Alves <palves@redhat.com>
* tui/tui-regs.c (tui_restore_gdbout): Don't delete gdb_stdout.
gdb/testsuite/ChangeLog:
2017-03-07 Pedro Alves <palves@redhat.com>
* gdb.base/tui-layout.c: New file.
* gdb.base/tui-layout.exp: New file.
To better reflect what the testcase is about, and to make room for a
different testcase.
gdb/testsuite/ChangeLog:
2017-03-07 Pedro Alves <palves@redhat.com>
* gdb.base/tui-layout.c: Rename to ...
* gdb.base/tui-disasm-long-lines.c: ... this.
* gdb.base/tui-layout.exp: Rename to ...
* gdb.base/tui-disasm-long-lines.exp: ... this.
This patch initializes the BND registers before executing the inferior
call. BND registers can be in arbitrary values at the moment of the
inferior call. In case the function being called uses as part of the
parameters BND register, e.g. when passing a pointer as parameter, the
current value of the register will be used. This can cause boundary
violations that are not due to a real bug or even desired by the user.
In this sense the best to be done is set the BND registers to allow
access to the whole memory, i.e. initialized state, before pushing the
inferior call.
2017-03-07 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* i387-tdep.h (i387_reset_bnd_regs): Add function definition.
* i387-tdep.c (i387_reset_bnd_regs): Add function implementation.
* i386-tdep.c (i386_push_dummy_call): Call i387_reset_bnd_regs.
* amd64-tdep (amd64_push_dummy_call): Call i387_reset_bnd_regs.
gdb/testsuite/ChangeLog:
* i386-mpx-call.c: New file.
* i386-mpx-call.exp: New file.
gdb/doc/ChangeLog:
* Memory Protection Extensions: Add information about inferior
calls.
This commit adds support to GDB so that it can modify the disassembler-options
value that is passed to the disassembler, similar to objdump's -M option.
Currently, the only supported targets are ARM, PowerPC and S/390, but
adding support for a new target(s) is not difficult.
include/
* dis-asm.h (disasm_options_t): New typedef.
(parse_arm_disassembler_option): Remove prototype.
(set_arm_regname_option): Likewise.
(get_arm_regnames): Likewise.
(get_arm_regname_num_options): Likewise.
(disassemble_init_s390): New prototype.
(disassembler_options_powerpc): Likewise.
(disassembler_options_arm): Likewise.
(disassembler_options_s390): Likewise.
(remove_whitespace_and_extra_commas): Likewise.
(disassembler_options_cmp): Likewise.
(next_disassembler_option): New inline function.
(FOR_EACH_DISASSEMBLER_OPTION): New macro.
opcodes/
* disassemble.c Include "safe-ctype.h".
(disassemble_init_for_target): Handle s390 init.
(remove_whitespace_and_extra_commas): New function.
(disassembler_options_cmp): Likewise.
* arm-dis.c: Include "libiberty.h".
(NUM_ELEM): Delete.
(regnames): Use long disassembler style names.
Add force-thumb and no-force-thumb options.
(NUM_ARM_REGNAMES): Rename from this...
(NUM_ARM_OPTIONS): ...to this. Use ARRAY_SIZE.
(get_arm_regname_num_options): Delete.
(set_arm_regname_option): Likewise.
(get_arm_regnames): Likewise.
(parse_disassembler_options): Likewise.
(parse_arm_disassembler_option): Rename from this...
(parse_arm_disassembler_options): ...to this. Make static.
Use new FOR_EACH_DISASSEMBLER_OPTION macro to scan over options.
(print_insn): Use parse_arm_disassembler_options.
(disassembler_options_arm): New function.
(print_arm_disassembler_options): Handle updated regnames.
* ppc-dis.c: Include "libiberty.h".
(ppc_opts): Add "32" and "64" entries.
(ppc_parse_cpu): Use ARRAY_SIZE and disassembler_options_cmp.
(powerpc_init_dialect): Add break to switch statement.
Use new FOR_EACH_DISASSEMBLER_OPTION macro.
(disassembler_options_powerpc): New function.
(print_ppc_disassembler_options): Use ARRAY_SIZE.
Remove printing of "32" and "64".
* s390-dis.c: Include "libiberty.h".
(init_flag): Remove unneeded variable.
(struct s390_options_t): New structure type.
(options): New structure.
(init_disasm): Rename from this...
(disassemble_init_s390): ...to this. Add initializations for
current_arch_mask and option_use_insn_len_bits_p. Remove init_flag.
(print_insn_s390): Delete call to init_disasm.
(disassembler_options_s390): New function.
(print_s390_disassembler_options): Print using information from
struct 'options'.
* po/opcodes.pot: Regenerate.
binutils/
* objdump.c (main): Use remove_whitespace_and_extra_commas.
gdb/
* NEWS: Mention new set/show disassembler-options commands.
* doc/gdb.texinfo: Document new set/show disassembler-options commands.
* disasm.c: Include "arch-utils.h", "gdbcmd.h" and "safe-ctype.h".
(prospective_options): New static variable.
(gdb_disassembler::gdb_disassembler): Initialize
m_di.disassembler_options.
(gdb_buffered_insn_length_init_dis): Initilize di->disassembler_options.
(get_disassembler_options): New function.
(set_disassembler_options): Likewise.
(set_disassembler_options_sfunc): Likewise.
(show_disassembler_options_sfunc): Likewise.
(disassembler_options_completer): Likewise.
(_initialize_disasm): Likewise.
* disasm.h (get_disassembler_options): New prototype.
(set_disassembler_options): Likewise.
* gdbarch.sh (gdbarch_disassembler_options): New variable.
(gdbarch_verify_disassembler_options): Likewise.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* arm-tdep.c (num_disassembly_options): Delete.
(set_disassembly_style): Likewise.
(arm_disassembler_options): New static variable.
(set_disassembly_style_sfunc): Convert short style name into long
option name. Call set_disassembler_options.
(show_disassembly_style_sfunc): New function.
(arm_gdbarch_init): Call set_gdbarch_disassembler_options and
set_gdbarch_verify_disassembler_options.
(_initialize_arm_tdep): Delete regnames variable and update callers.
(arm_disassembler_options): Initialize.
(disasm_options): New variable.
(num_disassembly_options): Rename from this...
(num_disassembly_styles): ...to this. Compute by scanning through
disasm_options.
(valid_disassembly_styles): Initialize using disasm_options.
Remove calls to parse_arm_disassembler_option, get_arm_regnames and
set_arm_regname_option.
Pass show_disassembly_style_sfunc to the "disassembler" setshow command.
* rs6000-tdep.c (powerpc_disassembler_options): New static variable.
(rs6000_gdbarch_init): Call set_gdbarch_disassembler_options and
set_gdbarch_verify_disassembler_options.
* s390-tdep.c (s390_disassembler_options): New static variable.
(s390_gdbarch_init):all set_gdbarch_disassembler_options and
set_gdbarch_verify_disassembler_options.
gdb/testsuite/
* gdb.arch/powerpc-power.exp: Delete test.
* gdb.arch/powerpc-power.s: Likewise.
* gdb.disasm/disassembler-options.exp: New test.
* gdb.arch/powerpc-altivec.exp: Likewise.
* gdb.arch/powerpc-altivec.s: Likewise.
* gdb.arch/powerpc-altivec2.exp: Likewise.
* gdb.arch/powerpc-altivec2.s: Likewise.
* gdb.arch/powerpc-altivec3.exp: Likewise.
* gdb.arch/powerpc-altivec3.s: Likewise.
* gdb.arch/powerpc-power7.exp: Likewise.
* gdb.arch/powerpc-power7.s: Likewise.
* gdb.arch/powerpc-power8.exp: Likewise.
* gdb.arch/powerpc-power8.s: Likewise.
* gdb.arch/powerpc-power9.exp: Likewise.
* gdb.arch/powerpc-power9.s: Likewise.
* gdb.arch/powerpc-vsx.exp: Likewise.
* gdb.arch/powerpc-vsx.s: Likewise.
* gdb.arch/powerpc-vsx2.exp: Likewise.
* gdb.arch/powerpc-vsx2.s: Likewise.
* gdb.arch/powerpc-vsx3.exp: Likewise.
* gdb.arch/powerpc-vsx3.s: Likewise.
* gdb.arch/arm-disassembler-options.exp: Likewise.
* gdb.arch/powerpc-disassembler-options.exp: Likewise.
* gdb.arch/s390-disassembler-options.exp: Likewise.
As reported in PR21166, there are Intel processors out there that support
rdrand but not rdseed. The fix is to verify both features separately and only
run rdrand/rdseed tests if supported.
gdb/testsuite/ChangeLog:
2017-02-23 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/insn-reverse.x86.c (check_rdrand_support): Renamed to ...
(check_supported_features): ... this. Changed return type to void.
(supports_rdseed): New static global.
(rdseed): Check supports_rdseed.
(initialize): Call check_supported_features.
gdb/
2017-02-21 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* rs6000-tdep.c (LOAD_AND_RESERVE_MASK): Rename from LWARX_MASK.
(STORE_CONDITIONAL_MASK): Rename from STWCX_MASK.
(LBARX_INSTRUCTION, LHARX_INSTRUCTION, LQARX_INSTRUCTION,
STBCX_INSTRUCTION, STHCX_INSTRUCTION, STQCX_INSTRUCTION): New defines.
(IS_LOAD_AND_RESERVE_INSN, IS_STORE_CONDITIONAL_INSN): New macros.
(ppc_displaced_step_copy_insn): Use IS_LOAD_AND_RESERVE_INSN.
(ppc_deal_with_atomic_sequence): Use IS_LOAD_AND_RESERVE_INSN and
IS_STORE_CONDITIONAL_INSN.
gdb/testsuite/
2017-02-21 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* gdb.arch/ppc64-isa207-atomic-inst.exp: New testcase based on
gdb.arch/ppc64-atomic-inst.exp. Add tests for lbarx/stbcx, lharx/sthcx
and lqarx/stqcx.
* gdb.arch/ppc64-isa207-atomic-inst.S: New file.
* gdb.arch/ppc64-isa207-atomic-inst.c: Likewise.
DWARF-5 has new form DW_FORM_data16. The problem is that GDB cannot pass
16-byte constant as a constant value as that would require GDB to use GCC
extension __int128.
Formerly such data was coded as DW_FORM_block* so GDB still decodes
DW_FORM_data16 like DW_FORM_block*.
gdb/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (skip_one_die, read_attribute_value)
(dwarf2_const_value_attr, dump_die_shallow)
(dwarf2_get_attr_constant_value, dwarf2_fetch_constant_bytes)
(skip_form_bytes, attr_form_is_constant): Handle DW_FORM_data16.
gdb/testsuite/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/formdata16.c: New file.
* gdb.dwarf2/formdata16.exp: New file.
* lib/dwarf.exp (Dwarf): Add DW_FORM_data16.
This is a fix for PR gdb/21164. The problem started to happen after:
commit 34c41c681f
Author: Doug Evans <xdje42@gmail.com>
AuthorDate: Mon Dec 19 08:33:46 2016 -0800
New syntax for mt print symbols,msymbols,psymbols.
This change introduced new syntax for the mentioned commands, and
improved the parsing of arguments by using 'gdb_buildargv'. However,
it is necessary to check if the argv being built is not NULL, which
can happen if the user doesn't provide any arguments to these
commands.
gdb/ChangeLog:
2017-02-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21164
* psymtab.c (maintenance_print_psymbols): Verify if 'argv' is not
NULL before using it.
* symmisc.c (maintenance_print_symbols): Likewise.
(maintenance_print_msymbols): Likewise.
gdb/testsuite/ChangeLog:
gdb/ChangeLog:
2017-02-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21164
* gdb.base/maint.exp: Add testcases for when the commands do
not have arguments.
3d7b173c29 made upper case commands now
illegal. However gdb.cp/chained-calls.exp still contains one test using
P to print an expression. This patch fixes the testcase to use p
instead.
2017-02-13 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/
* gdb.cp/chained-calls.exp: Use p instead of P.
This adds an event that is emitted just before GDB presents a prompt
to the user. This provides Python code a way to react to whatever
changes might have been made by the previous command. For example, in
my GUI I use this to track changes to the selected frame and reflect
them in the UI.
Built and regtested on x86-64 Fedora 23.
gdb/ChangeLog
2017-02-14 Tom Tromey <tom@tromey.com>
PR python/13598:
* python/python.c (gdbpy_before_prompt_hook): Emit before_prompt
event.
* python/py-evts.c (gdbpy_initialize_py_events): Add
before_prompt registry.
* python/py-events.h (events_object) <before_prompt>: New field.
gdb/doc/ChangeLog
2017-02-14 Tom Tromey <tom@tromey.com>
PR python/13598:
* python.texi (Events In Python): Document events.before_prompt.
gdb/testsuite/ChangeLog
2017-02-14 Tom Tromey <tom@tromey.com>
PR python/13598:
* gdb.python/py-events.exp: Add before_prompt event tests.
The test case implptrpiece.exp accesses the second byte of the short
integer number 1 and expects it to be zero. This is valid for
little-endian targets, but fails on big-endian targets.
This is fixed by distinguishing the expected value by endianness.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/implptrpiece.exp: Fix check for big-endian targets.
This patch addresses timeout failures i noticed while testing aarch64-elf.
FAIL: gdb.linespec/explicit.exp: complete unique function name (timeout)
FAIL: gdb.linespec/explicit.exp: complete non-unique function name (timeout)
FAIL: gdb.linespec/explicit.exp: complete non-existant function name (timeout)
FAIL: gdb.linespec/explicit.exp: complete unique file name (timeout)
FAIL: gdb.linespec/explicit.exp: complete non-unique file name (timeout)
The timeouts were caused by an attempt to match a bell character (x07) that
doesn't show up on my particular test setup.
The bell character is output whenever one tries to complete a pattern and there
are multiple possible matches. When there is only one possible match, GDB will
complete the input pattern without outputting the bell character.
The reason for the discrepancy in this test's behavior is due to the use of
"main" for a unique name test.
On glibc-based systems, GDB may notice the "main_arena" symbol, which is
a data global part of glibc's malloc implementation. Therefore a bell character
will be output because we have a couple possible completion matches.
GDB should not be outputting such a data symbol as a possible match, but this
problem may/will be addressed in a future change and is besides the point of
this particular change.
On systems that are not based on glibc, GDB will not see any other possible
matches for completing "main", so there will be no bell characters.
The use of main is a bit fragile though, so the patch adds a new local function
with a name that has a greater chance of being unique and adjusts the test to
iuse it.
I've also added the regular expression switch (-re) to all the
gdb_test_multiple calls that were missing it. Hopefully this will reduce the
chances of someone wasting time trying to match a regular expression (a much
more common use case) when, in reality, the pattern is supposed to be matched
literally.
gdb/testsuite/ChangeLog
2017-02-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.linespec/explicit.c (my_unique_function_name): New function.
(main): Call my_unique_function_name.
* gdb.linespec/explicit.exp: Use my_unique_function_name to test
completion of patterns with a single match.
Add missing -re switches to gdb_test_multiple calls.
This test attempts to load a x86 core file no matter what target
architectures the tested GDB supports. If GDB doesn't know how to handle
a i386 target, it is very likely the core file will not be recognized.
In this case we should still attempt to load a core file to make sure GDB
doesn't crash or throws an internal error. But we should not proceed to
try to read memory unconditionally.
This patch makes the test check for proper i386 arch support in GDB and bails
out if i386 is not supported and the core file format is not recognized.
This addresses the spurious aarch64-elf failures i'm seeing for this test.
gdb/testsuite/ChangeLog:
2017-02-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.arch/i386-biarch-core.exp: Check for i386 arch support and
return if core file is not recognized.
This is a follow-up to
https://sourceware.org/ml/gdb-patches/2017-02/msg00261.html
This patch restricts queries to the main UI, which allows to avoid two
different problems.
The first one is that GDB is issuing queries on secondary MI channels
for which a TTY is allocated. The second one is that GDB is not able to
handle queries on two (CLI) UIs simultaneously. Restricting queries to
the main UI allows to bypass these two problems.
More details on how/why these two problems happen:
1. Queries on secondary MI UI
The current criterion to decide if we should query the user is whether
the input stream is a TTY. The original way to start GDB in MI mode
from a front-end was to create a subprocess with pipes to its
stdin/stdout. In this case, the input was considered non-interactive
and queries were auto-answered. Now that front-ends can create the MI
channel as a separate UI connected to a dedicated TTY, GDB now
considers this input stream as interactive and sends queries to it.
By restricting queries to the main UI, we make sure we never query on
the secondary MI UI.
2. Simultaneous queries
As Pedro stated it, when you have two queries on two different CLI UIs
at the same time, you end up with the following pseudo stack:
#0 gdb_readline_wrapper
#1 defaulted_query // for UI #2#2 handle_command
#3 execute_command ("handle SIGTRAP" ....
#4 stdin_event_handler // input on UI #2#5 gdb_do_one_event
#7 gdb_readline_wrapper
#8 defaulted_query // for UI #1#9 handle_command
#10 execute_command ("handle SIGINT" ....
#11 stdin_event_handler // input on UI #1#12 gdb_do_one_event
#13 gdb_readline_wrapper
trying to answer the query on UI #1 will therefore answer for UI #2.
By restricting the queries to the main UI, we ensure that there will
never be more than one pending query, since you can't have two queries
on a UI at the same time.
I added a snippet to gdb.base/new-ui.exp to verify that we get a query
on the main UI, but that we don't on the secondary one (or, more
precisely, that it gets auto-answered).
gdb/ChangeLog:
* utils.c (defaulted_query): Don't query on secondary UIs.
gdb/testsuite/ChangeLog:
* gdb.base/new-ui.exp (do_test): Test queries behavior on main
and extra UIs.
While testing this series I saw some errors from the Python test
suite. There were a couple of tests using "P" as a command; this
changes them to "p".
gdb/testsuite/ChangeLog
2017-02-10 Tom Tromey <tom@tromey.com>
* gdb.python/py-xmethods.exp: Use "p" command, not "P".
Currently, the breakpoint documentation refers to some commands taking breakpoint
"ranges" as arguments. We discussed this with Pedro and concluded that it would
be more accurate to speak in terms of breakpoint "lists", whose elements can optionally
be ranges. I also fixed a couple of minor mistakes in the docs.
gdb/ChangeLog:
* breakpoint.c (_initialize_breakpoint): Update the help description
of the 'commands' command to indicate that it takes a list argument.
gdb/doc/ChangeLog:
* gdb.texinfo (Breakpoints): Reword documentation to speak in terms of
space-separated breakpoint lists. Also add a missing @table command
and @cindex for breakpoint lists.
gdb/testsuite/ChangeLog:
* gdb.base/help.exp: Update match pattern for testing 'help commands'.
When defining a new macro, "command" is not recognized as an alias for
"commands":
(gdb) define breakmain
Type commands for definition of "breakmain".
End with a line saying just "end".
>break main
>command
>echo "IN MAIN\n"
>end
(gdb)
There is a special case for while-stepping, where 'ws' and 'stepping' are
recognized explicitely. Instead of adding more special cases, this change
uses cli-decode.
gdb/ChangeLog:
* cli/cli-decode.c (find_command_name_length): Make it extern.
* cli/cli-decode.h (find_command_name_length): Declare.
* cli/cli-script.c (command_name_equals, line_first_arg):
New functions.
(process_next_line): Use cli-decode to parse command names.
(build_command_line): Make args a constant pointer.
gdb/testsuite/ChangeLog:
* gdb.base/define.exp: Add test for command abbreviations
in define.
This patch addresses BZ 21005, which is gdb failing to recognize an rdrand
instruction.
It enables support for both rdrand and rdseed and handles extended register
addressing (R8~R15) for 16-bit, 32-bit and 64-bit.
gdb/ChangeLog
2017-02-06 Luis Machado <lgustavo@codesourcery.com>
* NEWS: Mention support for record/replay of Intel 64 rdrand and
rdseed instructions.
i386-tdep.c (i386_process_record): Handle Intel 64 rdrand and rseed.
gdb/testsuite/ChangeLog:
2017-02-06 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/insn-reverse.c: Include insn-reverse-x86.c.
* gdb.reverse/insn-reverse-x86.c: New file.
gdb/ChangeLog:
2017-02-06 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20936
Provide and use sparc32 and sparc64 target description XML files.
* features/sparc/sparc32-cp0.xml, features/sparc/sparc32-cpu.xml,
features/sparc/sparc32-fpu.xml: New files for sparc 32-bit.
* features/sparc/sparc64-cp0.xml, features/sparc/sparc64-cpu.xml,
features/sparc/sparc64-fpu.xml: New files for sparc 64-bit.
* features/sparc/sparc32-solaris.xml: New file.
* features/sparc/sparc64-solaris.xml: New file.
* features/sparc/sparc32-solaris.c: Generated.
* features/sparc/sparc64-solaris.c: Generated.
* sparc-tdep.h: Account for differences in target descriptions.
* sparc-tdep.c (sparc32_register_name): Use target provided registers.
(sparc32_register_type): Use target provided registers.
(validate_tdesc_registers): New function.
(sparc32_gdbarch_init): Use tdesc_has_registers.
Set pseudoregister functions.
* sparc64-tdep.c (sparc64_register_name): Use target provided registers.
(sparc64_register_type): Use target provided registers.
(sparc64_init_abi): Set pseudoregister functions.
gdb/doc/ChangeLog:
2017-02-06 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20936
* gdb.texinfo: (Standard Target Features): Document SPARC features.
(Sparc Features): New node.
gdb/testsuite/ChangeLog:
2017-02-06 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20936
* gdb.xml/tdesc-regs.exp: Provide sparc core registers for the tests.
While looking into PR rust/21097, I found that ptype of a
single-element enum in Rust did not always format the result properly.
In particular, it would leave out the members of a tuple struct.
Further testing showed that it also did the wrong thing for ordinary
struct members as well.
This patch fixes these problems. I'm marking it as being associated
with the PR, since that is where the discovery was made; but this
doesn't actually fix that PR (which I think ultimately is due to a
Rust compiler bug).
Built and regtested on x86-64 Fedora 25, using the system Rust
compiler. I'm checking this in.
2017-02-03 Tom Tromey <tom@tromey.com>
PR rust/21097:
* rust-lang.c (rust_print_type) <TYPE_CODE_UNION>: Handle enums
with a single member.
2017-02-03 Tom Tromey <tom@tromey.com>
PR rust/21097:
* gdb.rust/simple.exp: Add new tests.
This commit fixes a "-gdb-set logging redirect on" crash by not
handling "logging redirect on" on the fly.
Previous discussion here:
https://sourceware.org/ml/gdb-patches/2017-01/msg00467.html
Code for handling "logging redirect on" on the fly was added here:
https://sourceware.org/ml/gdb-patches/2010-08/msg00202.html
Meanwhile, MI gained support for logging, but flipping redirect "on"
on the fly was not considered. The result is that this sequence of
commands crashes GDB:
-gdb-set logging on
-gdb-set logging redirect on
Program received signal SIGSEGV, Segmentation fault.
0x00000000008dd7bc in gdb_flush (file=0x2a097f0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/ui-file.c:95
194 file->to_flush (file);
(top-gdb) bt
#0 0x00000000008dd7bc in gdb_flush(ui_file*) (file=0x2a097f0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/ui-file.c:95
#1 0x00000000007b5f34 in gdb_wait_for_event(int) (block=0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/event-loop.c:752
#2 0x00000000007b52b6 in gdb_do_one_event() () at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/event-loop.c:322
#3 0x00000000007b5362 in start_event_loop() () at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/event-loop.c:371
#4 0x000000000082704a in captured_command_loop(void*) (data=0x0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:325
#5 0x00000000007b8d7c in catch_errors(int (*)(void*), void*, char*, return_mask) (func=0x827008 <captured_command_loop(void*)>, func_args=0x0, errstring=0x11dee51 "", mask=RETURN_MASK_ALL) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/exceptions.c:236
#6 0x000000000082839b in captured_main(void*) (data=0x7fffffffd820) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:1148
During symbol reading, cannot get low and high bounds for subprogram DIE at 24065.
#7 0x00000000008283c4 in gdb_main(captured_main_args*) (args=0x7fffffffd820) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:1158
#8 0x0000000000412d4d in main(int, char**) (argc=4, argv=0x7fffffffd928) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/gdb.c:32
The handling of redirect on the fly is not really a use case we need
to handle, IMO. Its inconsistent (other "set logging foo" commands
aren't handled on the fly), and complicates the code significantly.
Instead of complicating it further for MI, go back to the original
idea of warning, only:
https://sourceware.org/ml/gdb-patches/2010-08/msg00083.html
New test included.
gdb/ChangeLog:
2017-02-02 Pedro Alves <palves@redhat.com>
* cli/cli-logging.c (maybe_warn_already_logging): New factored out
from ...
(set_logging_overwrite): ... here.
(logging_no_redirect_file): Delete.
(set_logging_redirect): Don't handle redirection on the fly.
Instead warn that "logging off" / "logging on" is necessary.
(pop_output_files): Delete references to logging_no_redirect_file.
(show_logging_command): Always speak in terms of what will happen
once logging is reenabled.
gdb/testsuite/ChangeLog:
2017-02-02 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-logging.exp: Add "redirect while already logging"
tests.
When a variable's location is expressed as DW_OP_implicit_value, but the
given value is longer than needed, which bytes should be used? GDB's
current logic was introduced with a patch from 2011 and uses the "least
significant" bytes:
https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html
Now consider a sub-value from such a location at a given offset, accessed
through DW_OP_implicit_pointer. Which bytes should be used for that? The
patch above *always* uses the last bytes on big-endian targets, ignoring
the offset.
E.g., given the code snippet
const char foo[] = "Hello, world!";
const char *a = &foo[0];
const char *b = &foo[7];
assume that `foo' is described as DW_OP_implicit_value and `a' and `b'
each as DW_OP_implicit_pointer into that value. Then with current GDB
`*a' and `*b' yield the same result -- the string's zero terminator.
This patch basically reverts the portion of the patch above that deals
with DW_OP_implicit_value. This fixes the offset handling and also goes
back to dropping the last instead of the first bytes on big-endian targets
if the implicit value is longer than needed. The latter aspect of the
change probably doesn't matter for actual programs, but simplifies the
logic.
The patch also cleans up the original code a bit and adds appropriate test
cases.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of
taking a 2-byte value out of a 4-byte DWARF implicit value on
big-endian targets.
* gdb.dwarf2/nonvar-access.exp: Add more comments to existing
logic. Add test cases for DW_OP_implicit.
gdb/ChangeLog:
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For
DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian
targets. And if the implicit value is longer than needed, extract
the first bytes instead of the "least significant" ones.
If GDB is running when gdb_skip_xml_tests is called with
--target_board=native-extended-gdbserer.exp, it fails with:
(gdb) FAIL: ....exp: set tdesc filename .../trivial.xml (got interactive prompt)
monitor exit
Diagnose this in gdb_skip_xml_tests to generate a more meaningful error message:
ERROR: tcl error sourcing ....exp.
ERROR: GDB must not be running in gdb_skip_xml_tests.
while executing
[...]
testsuite/
* lib/gdb.exp (gdb_skip_xml_tests): Error if GDB is running.
Parts of gdb.btrace/enable.exp are only valid for native debug. The check for
skip_gdbserver_tests is done while GDB is running, though, which causes it to
fail with --target_board=native-extended-gdbserver. Exit GDB before that check.
testsuite/
* gdb.btrace/enable.exp: Call gdb_exit before skip_gdbserver_tests.
With --target_board=native-extended-gdbserver non-stop tests are failing with
UNTESTED: gdb.btrace/non-stop.exp: failed to run to main
Fix that by adding '-ex "set non-stop on"' to GDBFLAGS before restarting.
testsuite/
* gdb.btrace/non-stop.exp: Add '-ex "set non-stop on"' to GDBFLAGS.
We may silently skip gdb.btrace tests if
- the target does not support record-btrace
- the target does not support TSX
- the target does not support gdbserver
- we fail to compile the test
- we fail to run to main
Add unsupported/untested messages for each of those.
testsuite/
* gdb.btrace/buffer-size.exp: Add unsupported/untested message if
the test is skipped.
* gdb.btrace/data.exp: Likewise.
* gdb.btrace/delta.exp: Likewise.
* gdb.btrace/dlopen.exp: Likewise.
* gdb.btrace/enable-running.exp: Likewise.
* gdb.btrace/enable.exp: Likewise.
* gdb.btrace/exception.exp: Likewise.
* gdb.btrace/function_call_history.exp: Likewise.
* gdb.btrace/gcore.exp: Likewise.
* gdb.btrace/instruction_history.exp: Likewise.
* gdb.btrace/multi-thread-step.exp: Likewise.
* gdb.btrace/nohist.exp: Likewise.
* gdb.btrace/non-stop.exp: Likewise.
* gdb.btrace/reconnect.exp: Likewise.
* gdb.btrace/record_goto-step.exp: Likewise.
* gdb.btrace/record_goto.exp: Likewise.
* gdb.btrace/rn-dl-bind.exp: Likewise.
* gdb.btrace/segv.exp: Likewise.
* gdb.btrace/step.exp: Likewise.
* gdb.btrace/stepi.exp: Likewise.
* gdb.btrace/tailcall-only.exp: Likewise.
* gdb.btrace/tailcall.exp: Likewise.
* gdb.btrace/tsx.exp: Likewise.
* gdb.btrace/unknown_functions.exp: Likewise.
* gdb.btrace/vdso.exp: Likewise.
When recording is started for a running thread, GDB was able to start tracing
but then failed to read registers to insert the initial entry for the current
PC. We don't really need that initial entry if we don't know where exactly we
started recording. Skip that step to allow recording to be started while
threads are running.
If we do run into errors, we need to undo the tracing enable to not leak this
thread. The operation did not complete so our caller won't clean up this
thread.
For the BTRACE_FORMAT_PT btrace format, we don't need that initial entry since
it will be recorded in the trace. We can omit the call to btrace_add_pc.
gdb/
* btrace.c (btrace_enable): Do not call btrace_add_pc for
BTRACE_FORMAT_PT or if can_access_registers_ptid returns false.
(btrace_fetch): Assert can_access_registers_ptid.
* record-btrace.c (require_btrace_thread, record_btrace_info): Call
validate_registers_access.
testsuite/
* gdb.btrace/enable-running.c: New.
* gdb.btrace/enable-running.exp: New.
Pedro Alves
Simon Marchi
Anton Kolesov
Simon Marchi
Sandra Loosemore
Ulrich Weigand
Sergio Durigan Junior
Tom Tromey
Thomas Preud'homme
Kevin Buettner
Walfred Tedeschi
John Baldwin
Christoph Weinmann
Bernhard Heckel
Frank Penczek
Jan Kratochvil
Weimin Pan
Yao Qi
Andreas Arnez
Andrew Burgess
Iain Buclaw
David Blaikie
Doug Gilmore
Peter Bergner
Keith Seitz
Tim Wiederhake
Ivo Raisr
Artemiy Volkov
Marc-Andre Laperle
Doug Evans
Luis Machado
Edjunior Barbosa Machado
Michael Sturm
Martin Galvan
Jerome Guitton
Markus Metzger