I noticed gdb.base/new-ui.exp failing once here with:
FAIL: gdb.base/new-ui.exp: do_test: delete all breakpoints on extra console (got interactive prompt)
FAIL: gdb.base/new-ui.exp: do_test: main console: next causes no spurious output on other console
FAIL: gdb.base/new-ui.exp: do_test: main console: breakpoint hit reported on other console
The problem is 100% reproducible with check-read1:
$ make check-read1 TESTS="gdb.*/new-ui.exp"
testsuite/gdb.log shows:
delete
Delete all breakpoints? (y or n) [answered Y; input not from terminal]
(gdb) FAIL: gdb.base/new-ui.exp: do_test: delete all breakpoints on extra console (got interactive prompt)
This commit fixes the problem.
gdb/testsuite/ChangeLog:
2017-10-24 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui.exp (do_test): Split "delete all breakpoints on
extra console" test in two stages.
Currently, if you diff testsuite/gdb.sum of two builds in different
directories you see these spurious hunks:
-PASS: gdb.base/startup-with-shell.exp: touch /home/pedro/gdb1/build/gdb/testsuite/outputs/gdb.base/startup-with-shell/unique-file.unique-extension
+PASS: gdb.base/startup-with-shell.exp: touch /home/pedro/gdb2/build/gdb/testsuite/outputs/gdb.base/startup-with-shell/unique-file.unique-extension
-PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: set args /home/pedro/gdb1/build/gdb/testsuite/outputs/gdb.base/startup-with-shell/*.unique-extension
+PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: set args /home/pedro/gdb2/build/gdb/testsuite/outputs/gdb.base/startup-with-shell/*.unique-extension
-PASS: gdb.base/startup-with-shell.exp: startup_with_shell = off; run_args = *.unique-extension: set args /home/pedro/gdb1/build/gdb/testsuite/outputs/gdb.base/startup-with-shell/*.unique-extension
+PASS: gdb.base/startup-with-shell.exp: startup_with_shell = off; run_args = *.unique-extension: set args /home/pedro/gdb2/build/gdb/testsuite/outputs/gdb.base/startup-with-shell/*.unique-extension
Since the run_args arguments are already shown in the test prefix, we
can change the "set args" test name to literally "set args $run_args".
I.e., after this commit we'll show:
PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: set args $run_args
PASS: gdb.base/startup-with-shell.exp: startup_with_shell = off; run_args = *.unique-extension: set args $run_args
PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = $TEST: set args $run_args
PASS: gdb.base/startup-with-shell.exp: startup_with_shell = off; run_args = $TEST: set args $run_args
gdb/testsuite/ChangeLog:
2017-10-24 Pedro Alves <palves@redhat.com>
* gdb.base/startup-with-shell.exp ('touch $unique_file'): Don't
include the unstable output directory name in the test's name.
(initial_setup_simple) <'set args'>: Use custom test name.
The [wait -i $gdb_spawn_id] in the test is dangerous in the sense that
it won't be subject to timeout logic. So if GDB fails quiting, this
testcase hangs forever, hanging the test run with it. See:
https://sourceware.org/ml/gdb-patches/2016-10/msg00728.html
Instead of 'wait'ing directly, use gdb_test_multiple and expect 'eof'.
Tested that the testcase no longer hangs by hacking the test to send
"info threads" instead of "quit".
Tested with
--target_board={unix, native-gdbserver,native-extended-gdbserver}
and tested with
--host_board=local-remote-host
as well.
gdb/testsuite/ChangeLog:
2017-10-20 Pedro Alves <palves@redhat.com>
* gdb.base/quit.exp: Use gdb_test_multiple and expect 'eof' before
'wait -i'. Use gdb_assert and remote_close.
Comparing test results between
--target_board=native-gdbserver
--target_board=native-stdio-gdbserver
I noticed that gdb.base/bigcore.exp is failing with native-stdio-gdbserver:
Running src/gdb/testsuite/gdb.base/bigcore.exp ...
FAIL: gdb.base/bigcore.exp: continue (timeout)
...
The problem is that:
1. When debugging with "target remote | CMD", the inferior's
stdout/stderr streams are connected to a pipe.
2. The bigcore.c program prints a lot to the screen before it
reaches the breakpoint location that the "continue" shown above
wants to reach.
3. GDB is not flushing the inferior's output pipe while the inferior
is running.
4. The pipe becomes full.
5. The inferior thus deadlocks.
The bug is #3 above, which is what this commit fixes. A new test is
added, that specifically exercises this scenario. The test fails
before the fix, and passes after, and gdb.base/bigcore.exp also starts
passing.
gdb/ChangeLog:
2017-10-19 Pedro Alves <palves@redhat.com>
* ser-base.c (ser_base_read_error_fd): Delete the file handler if
async.
(handle_error_fd): New function.
(ser_base_async): Add/delete an event loop file handler for
error_fd.
gdb/testsuite/ChangeLog:
2017-10-19 Pedro Alves <palves@redhat.com>
* gdb.base/long-inferior-output.c: New file.
* gdb.base/long-inferior-output.exp: New file.
In my multi-target branch, I had managed to break GDB exiting
successfuly in response to "quit" or SIGHUP/SIGTERM when:
- you're debugging with "target extended-remote",
- have more than one inferior loaded in gdb, some running, and at
least one not running, and,
- quit gdb with the inferior that is not running yet selected.
The testsuite still passed cleanly anyway. I only noticed because I
was left with a bunch of core dumps in the gdb/testsuite/ directory --
the testsuite infrastructure closes GDB's pty after running each
testcase, which results in GDB getting a SIGHUP and should make GDB
exit gracefully. If GDB crashes at that point though, there's no
indication about it in gdb.sum/gdb.log.
This commit adds a multitude of tests exercising quitting GDB with
live inferiors, some of which would have caught the problem.
gdb/testsuite/ChangeLog:
2017-10-17 Pedro Alves <palves@redhat.com>
* gdb.base/quit-live.c: New file.
* gdb.base/quit-live.exp: New file.
These tests want to use raw "run", so skip them on targets that can't
do that.
Also adds a small utility procedure that clearly conveys intent instead of
explicitly checking use_gdb_stub in the testcases.
This makes sure these testcases continue to be skipped with
--target_board=native-gdbserver once that board stops setting
is_remote.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (target_can_use_run_cmd): New procedure.
* gdb.base/annota1.exp: Use it instead of is_remote.
* gdb.base/annota3.exp: Use it instead of is_remote.
* gdb.cp/annota2.exp: Use it instead of is_remote.
* gdb.cp/annota3.exp: Use it instead of is_remote.
* gdb.multi/bkpt-multi-exec.exp: Use it instead of is_remote.
Currently we get:
Running ..../src/gdb/testsuite/gdb.base/testenv.exp ...
FAIL: gdb.base/testenv.exp: test no TEST_GDB var
FAIL: gdb.base/testenv.exp: test with one TEST_GDB var
FAIL: gdb.base/testenv.exp: test with two TEST_GDB var
FAIL: gdb.base/testenv.exp: test with one TEST_GDB var, after unset
FAIL: gdb.base/testenv.exp: test with TEST_GDB_GLOBAL
FAIL: gdb.base/testenv.exp: test with TEST_GDB_GLOBAL unset
The problem is that the testcase relies on stdio. While we could fix
this for gdbserver by read output from inferior_spawn_id, a better fix
it to not rely on stdio at all. That's what this commit does.
Instead, it reads variables off of the inferior to extract the
necessary information.
Along the way, most of the .exp file is reimplemented/cleaned up using
more modern mechanisms. E.g., with_test_prefix, proc_with_prefix,
save_vars, etc. Also, a missing check for "is_remote host" is added.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.base/testenv.exp: Check use_gdb_stub instead of is_remote.
(test_num_test_vars, run_and_count_vars, find_env)
(test_set_unset_env, test_inherit_env_var): New procedures.
(top level): Use them.
Currently, with --target_board=native-extended-gdbserver, we get:
Running .../src/gdb/testsuite/gdb.base/find-unmapped.exp ...
FAIL: gdb.base/find-unmapped.exp: find global_var_0, global_var_2, 0xff
FAIL: gdb.base/find-unmapped.exp: find global_var_1, global_var_2, 0xff
FAIL: gdb.base/find-unmapped.exp: find global_var_2, (global_var_2 + 16), 0xff
This commit makes the test pass there, and also enables in on
--target_board=native-gdbserver, and other remote targets.
I've filed PR gdb/22293 to track the missing-warning problem.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
PR gdb/22293
* gdb.base/find-unmapped.exp: Don't skip if is_remote target.
(top level): Move some tests to ...
(test_not_found): ... this new procedure.
(top level): Call it.
With --target_board=native-extended-gdbserver, we get:
Running .../src/gdb/testsuite/gdb.base/term.exp ...
FAIL: gdb.base/term.exp: info terminal at breakpoint
(gdb) info terminal
No saved terminal information.
Fix it by running the test everywhere, and expecting different output
on non-native targets.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.base/term.exp: Don't skip if is_remote target. Instead,
expect different "info terminal" output if testing with a
non-native target.
1. Otherwise, when we make native-gdbserver board no longer is_remote,
we get:
Running .../src/gdb/testsuite/gdb.base/corefile.exp ...
ERROR: tcl error sourcing .../src/gdb/testsuite/gdb.base/corefile.exp.
ERROR: gdbserver does not support attach 9327 without extended-remote
while executing
"error "gdbserver does not support $command without extended-remote""
That's fixed by using can_spawn_for_attach instead.
2. The gdb_protocol check fixes this current problem with
--target_board=extended-remote-gdbserver:
Running .../src/gdb/testsuite/gdb.base/corefile.exp ...
FAIL: gdb.base/corefile.exp: run: with core
FAIL: gdb.base/corefile.exp: run: core file is cleared
FAIL: gdb.base/corefile.exp: attach: with core
FAIL: gdb.base/corefile.exp: attach: core file is cleared
gdb.log:
(...)
attach 10859
Don't know how to attach. Try "help target".
(...)
The fix for #2 alone would fix#1 too, but can_spawn_for_attach
expresses the requirement directly, so I still left it there.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.base/corefile.exp (corefile_test_run): Skip if gdb_protocol
is set.
(corefile_test_attach): Likewise. Check can_spawn_for_attach
instead of is_remote.
1. Otherwise, when the native-gdbserver board stops setting is_remote,
this test would stop running there.
2. Makes the test run with --target_board=native-extended-gdbserver
too.
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.base/remote.exp: Check gdb_protocol instead of is_remote.
(top level): Add comment.
(Dropped 'u' while at it because we're supposed to prefer American
English spelling...)
gdb/testsuite/ChangeLog:
2017-10-13 Pedro Alves <palves@redhat.com>
* gdb.base/remote.exp (top level): Fix comment typo and add
missing return.
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
Pedro Alves
Simon Marchi
Ulrich Weigand
Sergio Durigan Junior
Tom Tromey
Thomas Preud'homme
John Baldwin
Simon Marchi