I see the following two fails on arm-none-eabi target, because argv[0]
isn't available.
print argv[0]^M
$1 = 0x1f78 "/dev/null"^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name
print argv[0]^M
$1 = 0x1f78 "/dev/null"^M
(gdb) FAIL: gdb.base/argv0-symlink.exp: kept directory symbolic link name
My first thought is to check [target_info exists noargs], and skip the
test if it returns true. However, noargs is set in gdbserver board
files, so argv0-symlink.exp will be skipped on gdbserver board file.
The change is too aggressive.
When the program is running with gdbserver, argv[1] to argv[N] aren't
available, but argv[0] is. Fortunately, argv0-symlink.exp only
requires argv[0]. argv0-symlink.exp can be run with gdbserver board
file, as what we do now.
What we need to check is whether argv[0] is available, so I add a new
proc gdb_has_argv0 to do so by starting a program, and check
argc/argv[0] to see whether argv[0] is available.
Dan fixed the similar problem by checking noargs, which is too strong.
https://sourceware.org/ml/gdb-patches/2010-02/msg00398.html as a
result, the test is skipped on gdbserver. This patch fixed it too.
gdb/testsuite:
2014-10-18 Yao Qi <yao@codesourcery.com>
* gdb.base/argv0-symlink.exp: Check argv[0] value if
gdb_has_argv0 return true.
* gdb.guile/scm-value.exp (test_value_in_inferior): Don't
check [target_info exists noargs], check [gdb_has_argv0]
instead.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* lib/gdb.exp (gdb_has_argv0, gdb_has_argv0_1): New
procedures.
If one is watching new_objfile events in python, it helps to know
when the list of objfiles is cleared. This patch adds a new
clear_objfiles event to support this.
This patch is all just cut-n-paste-n-tweak derived from
the new_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new event gdb.clear_objfiles.
* python/py-event.h (emit_clear_objfiles_event): Clear
* python/py-events.h (events_object): New member clear_objfiles.
* python/py-evts.c (gdbpy_initialize_py_events): Add clear_objfiles
event.
* python/py-inferior.c (python_new_objfile): If objfile is NULL,
emit clear_objfiles event.
* python/py-newobjfileevent.c (create_clear_objfiles_event_object): New
function.
(emit_clear_objfiles_event): New function.
(clear_objfiles): New event.
* python/python-internal.h (gdbpy_initialize_clear_objfiles_event):
Declare.
* python/python.c (_initialize_python): Call
gdbpy_initialize_clear_objfiles_event.
gdb/doc/ChangeLog:
* python.texi (Events In Python): Document clear_objfiles event.
gdb/testsuite/ChangeLog:
* gdb.python/py-events.exp: Update expected output for clear_objfiles
event.
* gdb.python/py-events.py: Add clear_objfiles event.
gdb/ChangeLog:
* NEWS: Mention new gdb.Objfile.progspace attribute.
* python/py-objfile.c (objfpy_get_progspace): New function.
(objfile_getset): New entry for "progspace".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document new progspace attribute.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test progspace attribute.
Some testcases, mostly gdb.reverse ones, assume the presence of a
'/' directory separator before the source file name. This is
incorrect for mingw32 hosts, generating false failures for those
tests.
I attempted to catch most of the occurrences of the pattern
".*/$srcfile" and replaced them with ".*$srcfile". The latter
is used elsewhere in the testsuite. The resulting patch is attached.
I also see other occurrences of the same assumption throughout the
testsuite, but usually they are arguments for function calls and i
seem to recall either the test harness or GDB deals with those
paths properly.
gdb/testsuite:
2014-10-17 Luis Machado <lgustavo@codesourcery.com>
* gdb.guile/scm-breakpoint.exp: Do not assume any
directory separators when matching source file paths.
* gdb.python/py-breakpoint.exp: Likewise.
* gdb.reverse/break-precsave.exp: Likewise.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse-bkpt.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/i387-env-reverse.exp: Likewise.
* gdb.reverse/i387-stack-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
When I run test with board file local-remote-host-native.exp, I see
the following warning,
$ make check RUNTESTFLAGS="--host_board=local-remote-host-native
--target_board=local-remote-host-native tdesc-arch.exp
HOST_DIR=/tmp/foo/"
(gdb) set tdesc filename ../../../../git/gdb/testsuite/gdb.xml/trivial.xml^M
warning: Could not open "../../../../git/gdb/testsuite/gdb.xml/trivial.xml"
(gdb) quit^
because "${srcdir}/gdb.xml/trivial.xml" doesn't exist on host. This
patch is to copy trivial.xml to host and the warning goes away.
(gdb) set tdesc filename /tmp/foo/trivial.xml^M
(gdb) quit^
tdesc-regs.exp has the similar problem that single-reg.xml may not
exist on host at all, and it should be copied to host too.
gdb/testsuite:
2014-10-17 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (gdb_skip_xml_test): Copy trivial.xml to host.
* gdb.xml/tdesc-regs.exp: Copy single-reg.xml to host.
When we repeat a command, by just pressing <ret>, the input from the
previous command is reused for the new command invocation.
When an execution command strips the "&" out of its incoming argument
string, to detect background execution, we poke a '\0' directly to the
incoming argument string.
Combine both, and a repeat of a background command loses the "&".
This is actually only visible if args other than "&" are specified
(e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&"
alone (e.g. "c&") doesn't actually clobber the incoming string.
Fix this by making strip_bg_char return a new string instead of poking
a hole in the input string.
New test included.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* infcmd.c (strip_bg_char): Change prototype and rewrite. Now
returns a copy of the input.
(run_command_1, continue_command, step_1, jump_command)
(signal_command, until_command, advance_command, finish_command)
(attach_command): Adjust and install a cleanup to free the
stripped args.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* gdb.base/bg-execution-repeat.c: New file.
* gdb.base/bg-execution-repeat.exp: New file.
If all threads in the target were already running when the user does
"c -a", nothing puts the inferior's terminal settings in effect and
removes stdin from the event loop, which we must when running a
foreground command. The result is that user input afterwards crashes
readline/gdb:
(gdb) start
Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23.
Starting program: continue-all-already-running
Temporary breakpoint 1, main () at continue-all-already-running.c:23
23 sleep (10);
(gdb) c -a&
Continuing.
(gdb) c -a
Continuing.
p 1
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
$
Backtrace:
Program received signal SIGABRT, Aborted.
0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(top-gdb) p 1
$1 = 1
(top-gdb) bt
#0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x0000003b36a36f68 in __GI_abort () at abort.c:89
#2 0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116
#3 0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167
#4 0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373
#5 0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763
#6 0x0000000000617631 in process_event () at gdb/event-loop.c:340
#7 0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404
#8 0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429
#9 0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182
#10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318
#11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323
#12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
at gdb/exceptions.c:237
#13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151
#14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
at gdb/exceptions.c:237
#15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159
#16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32
(top-gdb)
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* infcmd.c (continue_1): If continuing all threads in the
foreground, make sure the inferior's terminal settings are put in
effect.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* gdb.base/continue-all-already-running.c: New file.
* gdb.base/continue-all-already-running.exp: New file.
Jan caught an intermittent GDB crash with the annota1.exp test:
Starting program: .../gdb/testsuite/gdb.base/annota1 ^M
[...]
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
[...]
readline: readline_callback_read_char() called with no handler!^M
ERROR: Process no longer exists
All we need to is to continue the inferior in the foreground, and type
a command while the inferior is running. E.g.:
(gdb) set annotate 2
▒▒pre-prompt
(gdb)
▒▒prompt
c
▒▒post-prompt
Continuing.
▒▒starting
▒▒frames-invalid
*inferior is running now*
p 1<ret>
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
$
When we run a foreground execution command we call
target_terminal_inferior to stop GDB from processing input, and to put
the inferior's terminal settings in effect. Then we tell readline to
hide the prompt with display_gdb_prompt, which clears readline's input
callback too. When the target stops, we call target_terminal_ours,
which re-installs stdin in the event loop, and then we redisplay the
prompt, reinstalling the readline callbacks.
However, when annotations are in effect, the "frames-invalid"
annotation code calls target_terminal_ours after 'resume' had already
called target_terminal_inferior:
(top-gdb) bt
#0 0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219
#1 0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705
#2 0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612
#3 0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136
#4 0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263
#5 0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613
And then once we hide the prompt and remove readline's input handler
callback, we're in a bad state. We end up with the target running
supposedly in the foreground, but with stdin still installed on the
event loop. Any input then calls into readline, which aborts because
no rl_linefunc callback handler is installed:
Program received signal SIGABRT, Aborted.
0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(top-gdb) bt
#0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x0000003b36a36f68 in __GI_abort () at abort.c:89
During symbol reading, debug info gives source 9 included from file at zero line 0.
During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1.
#2 0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116
#3 0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167
#4 0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373
#5 0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763
#6 0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340
#7 0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404
#8 0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429
#9 0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182
#10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318
#11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323
#12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
at src/gdb/exceptions.c:237
#13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151
#14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
at src/gdb/exceptions.c:237
#15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159
#16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32
The fix is to make the annotation code call target_terminal_inferior
again after printing, if the inferior's settings were in effect.
While at it, when we're doing output only, instead of
target_terminal_ours, we should call target_terminal_ours_for_output.
The latter doesn't actually remove stdin from the event loop, and also
leaves SIGINT forwarded to the target.
New test included.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* annotate.c (annotate_breakpoints_invalid): Use
target_terminal_our_for_output instead of target_terminal_ours.
Give back the terminal to the target.
(annotate_frames_invalid): Likewise.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* gdb.base/annota-input-while-running.c: New file.
* gdb.base/annota-input-while-running.exp: New file.
This commit does most of the mechanical removal. IOW, the easy part.
procfs.c isn't touched beyond removing a couple obvious bits that are
guarded by a couple macros defined in config/alpha/nm-osf3.h. Going
beyond that for procfs.c & co would be a harder excision that
potentially affects Solaris.
Some comments in the generic alpha code ABIs that may still be
relevant and I wouldn't know what to do with them. That can always be
done on a separate pass, preferably by someone who can test on alpha.
A couple other spots have references to OSF/Tru64 and related files
being removed, but it felt like removing them would make things worse,
not better. We can revisit those when we next need to touch that
code.
I didn't remove a reference to osf in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=alpha-osf3 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration alpha-unknown-osf3 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `build-osf'
make: *** [all] Error 2
gdb/
2014-10-17 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_64_TARGET_OBS): Remove alpha-osf1-tdep.o.
(HFILES_NO_SRCDIR): Remove config/alpha/nm-osf3.h.
(ALLDEPFILES): Remove alpha-nat.c, alpha-osf1-tdep.c and
solib-osf.c.
* NEWS: Mention that support for alpha*-*-osf* has been removed.
* ada-lang.h [__alpha__ && __osf__]
(ADA_KNOWN_RUNTIME_FILE_NAME_PATTERNS): Delete.
* alpha-nat.c, alpha-osf1-tdep.c: Delete files.
* alpha-tdep.c (alpha_gdbarch_init): Remove reference to
GDB_OSABI_OSF1.
* config/alpha/alpha-osf3.mh, config/alpha/nm-osf3.h: Delete
files.
* config/djgpp/fnchange.lst (config/alpha/alpha-osf1.mh)
(config/alpha/alpha-osf2.mh, config/alpha/alpha-osf3.mh): Delete.
* configure: Regenerate.
* configure.ac: Remove references to osf.
* configure.host: Handle alpha*-*-osf* in the obsolete hosts
section. Remove all other references to osf.
* configure.tgt: Add alpha*-*-osf* to the obsolete targets section.
Remove all other references to osf.
* dec-thread.c: Delete file.
* defs.h (GDB_OSABI_OSF1): Delete.
* inferior.h (START_INFERIOR_TRAPS_EXPECTED): New unconditionally
defined.
* osabi.c (gdb_osabi_names): Delete "OSF/1".
* procfs.c (procfs_debug_inferior) [PROCFS_DONT_TRACE_FAULTS]:
Delete code.
(unconditionally_kill_inferior)
[PROCFS_NEED_CLEAR_CURSIG_FOR_KILL]: Delete code.
* solib-osf.c: Delete file.
gdb/testsuite/
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.base/callfuncs.exp: emove references to osf.
* gdb.base/sigall.exp: Likewise.
* gdb.gdb/selftest.exp: Likewise.
* gdb.hp/gdb.base-hp/callfwmall.exp: Likewise.
* gdb.mi/non-stop.c: Likewise.
* gdb.mi/pthreads.c: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.threads/pthreads.c: Likewise.
* gdb.threads/pthreads.exp: Likewise.
gdb/doc/
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Ada Tasks and Core Files): Delete mention of Tru64.
(SVR4 Process Information): Delete mention of OSF/1.
I am confused by the noargs checking at each proc in commands.exp,
if [target_info exists noargs] {
verbose "Skipping progvar_simple_while_test because of noargs."
return
}
gdb_test_no_output "set args 5" "set args in progvar_simple_while_test"
if { ![runto factorial] } then { gdb_suppress_tests }
# Don't depend upon argument passing, since most simulators don't
# currently support it. Bash value variable to be what we want.
gdb_test "p value=5" ".*" "set value to 5 in progvar_simple_if_test #2"
They are conflicting to me. If the argument passing can't be done on
the target, we skip this test, why do we still have to set value below?
On the other hand, the test case is compiled with -DFAKEARGV, it doesn't
get anything from argv[1], why do we need to skip it if noargs is true?
I don't find any useful clues from the git log, as the code is quite
old, predating import to sourceware cvs. However, I find something
useful from the ChangeLog.
Thu Jul 20 13:28:36 1995 Jeffrey A. Law <law@rtl.cygnus.com>
.....
* gdb.base/commands.exp: Protect tests which need arguments with
$noargs conditionals.
Mon Apr 21 13:38:58 1997 Fred Fish <fnf@cygnus.com>
* gdb.base/run.c: Use FAKEARGV to build test executable that
does not require a command line arg, since most simulators
don't currently support passing such an arg into the simulated
program.
* gdb.base/commands.exp: Change tests to insert the proper
value as the arg to the first recursive factorial call. Change
compilation line to define FAKEARGV at compile time.
Jeff added noargs checking as argument is passed to the inferior. Then,
I presume Fred wanted to run this test on simulators which don't support
argument passing, and change the code not get input from argv. (I guess)
noargs wasn't set in simulator board files at that moment.
Since Fred changed test to set input by gdb, instead of getting input
from argv, the test should be able to run on target doesn't support
argument passing, such as simulator and gdbserver.
This patch is to remove these checks to noargs and "set args". I run
commands.exp with these board files, and no fail is found
- unix and native-gdbserver
- arm-none-eabi with qemu
- gdbserver on arm-linux-gnueabi with qemu
gdb/testsuite:
2014-10-17 Yao Qi <yao@codesourcery.com>
* gdb.base/commands.exp (gdbvar_complex_if_while_test): Don't check
'target_info exists noargs'.
(test_command_prompt_position): Likewise.
(progvar_simple_if_test): Don't check 'target_info exists noargs'.
Remove "set args".
(progvar_simple_while_test): Likewise.
(progvar_complex_if_while_test): Likewise.
(if_while_breakpoint_command_test): Likewise.
(infrun_breakpoint_command_test): Likewise.
(breakpoint_command_test): Likewise.
(watchpoint_command_test): Likewise.
(bp_deleted_in_command_test): Likewise.
(temporary_breakpoint_commands): Likewise.
The condition [target_info exists noargs] is checked when
remotetimeout.exp was added
https://sourceware.org/ml/gdb-patches/2005-02/msg00052.html
noargs means GDB does not support argument passing for inferior,
rather than doesn't support argument passing to GDB. remotetimeout.exp
passes -l to GDB only, doesn't pass any arguments to the inferior.
This patch is to remove such unnecessary checking, and
remotetimeout.exp then can be run with native-gdbserver board file.
gdb/testsuite:
2014-10-16 Yao Qi <yao@codesourcery.com>
* gdb.base/remotetimeout.exp: Remove noargs checking.
This patch makes single-step breakpoints "real" breakpoints on the
global location list.
There are several benefits to this:
- It removes the currently limitation that only 2 single-step
breakpoints can be inserted. See an example here of a discussion
around a case that wants more than 2, possibly unbounded:
https://sourceware.org/ml/gdb-patches/2014-03/msg00663.html
- makes software single-step work on read-only code regions.
The logic to convert a software breakpoint to a hardware breakpoint
if the memory map says the breakpoint address is in read only memory
is in insert_bp_location. Because software single-step breakpoints
bypass all that go and straight to target_insert_breakpoint, we
can't software single-step over read only memory. This patch
removes that limitation, and adds a test that makes sure that works,
by forcing a code region to read-only with "mem LOW HIGH ro" and
then stepping through that.
- Fixes PR breakpoints/9649
This is an assertion failure in insert_single_step_breakpoint in
breakpoint.c, because we may leave stale single-step breakpoints
behind on error.
The tests for stepping through read-only regions exercise the root
cause of the bug, which is that we leave single-step breakpoints
behind if we fail to insert any single-step breakpoint. Deleting
the single-step breakpoints in resume_cleanups,
delete_just_stopped_threads_infrun_breakpoints, and
fetch_inferior_event fixes this. Without that, we'd no longer hit
the assertion, as that code is deleted, but we'd instead run into
errors/warnings trying to insert/remove the stale breakpoints on
next resume.
- Paves the way to have multiple threads software single-stepping at
the same time, leaving update_global_location_list to worry about
duplicate locations.
- Makes the moribund location machinery aware of software single-step
breakpoints, paving the way to enable software single-step on
non-stop, instead of forcing serialized displaced stepping for all
single steps.
- It's generaly cleaner.
We no longer have to play games with single-step breakpoints
inserted at the same address as regular breakpoints, like we
recently had to do for 7.8. See this discussion:
https://sourceware.org/ml/gdb-patches/2014-06/msg00052.html.
Tested on x86_64 Fedora 20, on top of my 'single-step breakpoints on
x86' series.
gdb/
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* breakpoint.c (single_step_breakpoints, single_step_gdbarch):
Delete array globals.
(single_step_breakpoints): New global.
(breakpoint_xfer_memory): Remove special handling for single-step
breakpoints.
(update_breakpoints_after_exec): Delete bp_single_step
breakpoints.
(detach_breakpoints): Remove special handling for single-step
breakpoints.
(breakpoint_init_inferior): Delete bp_single_step breakpoints.
(bpstat_stop_status): Add comment.
(bpstat_what, bptype_string, print_one_breakpoint_location)
(adjust_breakpoint_address, init_bp_location): Handle
bp_single_step.
(new_single_step_breakpoint): New function.
(set_momentary_breakpoint, bkpt_remove_location): Remove special
handling for single-step breakpoints.
(insert_single_step_breakpoint, single_step_breakpoints_inserted)
(remove_single_step_breakpoints, cancel_single_step_breakpoints):
Rewrite.
(detach_single_step_breakpoints, find_single_step_breakpoint):
Delete functions.
(breakpoint_has_location_inserted_here): New function.
(single_step_breakpoint_inserted_here_p): Rewrite.
* breakpoint.h: Remove FIXME.
(enum bptype) <bp_single_step>: New enum value.
(insert_single_step_breakpoint): Update comment.
* infrun.c (resume_cleanups)
(delete_step_thread_step_resume_breakpoint): Remove single-step
breakpoints.
(fetch_inferior_event): Install a cleanup that removes infrun
breakpoints.
(switch_back_to_stepped_thread) <expect thread advanced also>:
Clear step-over info.
gdb/testsuite/
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* gdb.base/breakpoint-in-ro-region.c (main): Add more instructions.
* gdb.base/breakpoint-in-ro-region.exp
(probe_target_hardware_step): New procedure.
(top level): Probe hardware stepping and hardware breakpoint
support. Test stepping through a read-only region, with both
"breakpoint auto-hw" on and off and both "always-inserted" on and
off.
Test gdb.python/py-parameter.exp expects output "$srcdir/$subdir:\$cdir:\$cwd",
but proc gdb_reinitialize_dir doesn't set $srcdir/$subdir in search
directories on remote host because it doesn't exist on remote host.
proc gdb_reinitialize_dir { subdir } {
global gdb_prompt
if [is_remote host] {
return ""
}
It causes the fail below:
(gdb) python print (gdb.parameter ('directories'))^M
/tmp/gdb:$cdir:$cwd^M
(gdb) FAIL: gdb.python/py-parameter.exp: python print (gdb.parameter ('directories'))
This patch is to fix this fail by not matching $srcdir/$subdir on remote host.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-parameter.exp: Don't match $srcdir/$subdir on
remote host.
I see the following fails in the remote host testing we do for mingw32
hosted GDB,
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line current locationn filename
python print (symtab[1][0].symtab)^M
python.c^M
(gdb) FAIL: gdb.python/python.exp: Test decode_line python.c:26 filename
The test cases doesn't consider remote host and assumes that directory
on build also exists on host. In this patch, we only match file base
name if host is remote, otherwise, match file with dir name.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-symbol.exp: Match file base name if host is
remote, otherwise match file name with dir name.
* gdb.python/py-symtab.exp: Likewise.
* gdb.python/python.exp: Likewise.
This patch is to clean up various gdb.python/*.exp tests, such as
removing trailing ".*" from the pattern and fix one typo I find during
reading the code.
gdb/testsuite:
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Remove trailing ".*". Fix typo
locationn.
* gdb.python/py-symbol.exp: Remove trailing ".*" in the
pattern.
* gdb.python/py-symtab.exp: Likewise.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:
(gdb) p something'address + 0
$1 = (system.address) 0x613418 <pck.something>
(gdb) p 0 + something'address
Argument to arithmetic operation not a number or boolean.
Same issue when doing subtractions:
(gdb) p something'address - 0
$2 = (system.address) 0x613418 <pck.something>
(gdb) p 0 - something'address
Argument to arithmetic operation not a number or boolean.
This patch enhances the Ada expression evaluator to handle
these two situations.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
of the case where the second operand is a pointer.
<BINOP_SUB>: Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/addr_arith: New testcase.
Tested on x86_64-linux.
Joel contacted me offlist with a question about a warning that one of
his customers was seeing. The message came from the new
linker-debugger interface, which uses SDT probes internally. The
warning said:
(gdb) run
[...]
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Argument to arithmetic operation not a number or boolean.
This should not have happened in the environment the customer was
using (RHEL-6.x), so I found it strange. Another thing caught my
attention: the last message, saying "Argument to arithmetic operation
not a number or boolean.".
Joel kindly investigated the issue further, and found the answer for
this. To quote him:
(gdb) set lang c
(gdb) p 48+$ebp
$4 = (void *) 0xffffd0f8
So far so good. But...
(gdb) set lang ada
(gdb) p 48+$ebp
Argument to arithmetic operation not a number or boolean.
Ooops! Interestingly, if you revert the order of the operands...
(gdb) p $ebp+48
$5 = (access void) 0xffffd0f8
So the problem is doing pointer arithmetics when the language is set
to Ada.
I remembered that, during the parsing and the evaluation of SDT probe
arguments, the code sets the language as current_language, because, at
that time, I thought it was not necessary to worry about the language
given that the code implements its own parser. I was wrong. So here
is a patch to fix that, by setting the language as C, which should
guarantee that the maths are done in the right way (TM).
It was somewhat hard to find a reproducer for this issue. In the end,
what I had to do was to create a testcase that used the %ebp register
on some displacement (e.g., "-4(%ebp)"), which finally triggered the
bug. I am not sure why I could not trigger it when using other
registers, but I did not want to spend too much time investigating
this issue, which seemed like an Ada issue. Also, because of this
peculiar way to trigger the problem, the testcase only covers x86-like
targets (i.e., i*86 and x86_64 with -m32).
Joel kindly tested this for me, and it worked. I also ran a full
regression test here on my Fedora 20 x86_64, and everything is fine.
I will push this patch in a few days if there are no comments.
gdb/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_argument): Initialize expout explicitly
using language_c, instead of current_language.
gdb/testsuite/ChangeLog:
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/stap-eval-lang-ada.S: Likewise.
* gdb.arch/stap-eval-lang-ada.c: Likewise.
* gdb.arch/stap-eval-lang-ada.exp: New file.
Hi,
I see the following fails on arm-none-eabi target,
-var-list-children --simple-values struct_declarations ^M
^done,numchild="11",children=[...,child={name="struct_declarations.func_ptr_struct",exp="func_ptr_struct",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl (*)(int, char *, long)",thread-id="1"},child={name="struct_declarations.func_ptr_ptr",exp="func_ptr_ptr",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl *(*)(int, char *, long)",thread-id="1"},...
(gdb) ^M
FAIL: gdb.mi/mi-var-child.exp: listing of children, simple types: names, type and values, complex types: names and types
-var-set-format weird.func_ptr_ptr natural^M
^done,format="natural",value="0x0 <_ftext>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr in natural
In the test, "0x0" is expected, but "0x0 <_ftext>" is in the output.
Function pointers point to address zero, and tests assume there is no
symbol on address zero. However, on my arm-none-eabi target, there is
a code symbol _ftext on address zero, and test fails. Note that "set
print symbol off" doesn't take effect for function pointer.
int (*f) (void);
f = main;
(gdb) p f
$1 = (int (*)(void)) 0x8048400 <main>
(gdb) set print symbol off
(gdb) p f
$2 = (int (*)(void)) 0x8048400 <main>
In order to erase the difference, we can assign some function address
explicitly to function pointer, so the test behaves in a unique way.
In this patch, we assign nothing1 and nothing2 to function pointers
func_ptr_struct and func_ptr_ptr respectively, and update test as the
source file is changed.
gdb/testsuite:
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-child.exp: Step over new added statements.
Update test to match the new output.
* gdb.mi/var-cmd.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-display.exp: Update test to match output.
Step to the line specified by $line_dct_nothing.
Increase the number of lines to step.
Hi,
I modify mi-var-child.exp and find that the pattern to match the output
of -var-update * is quite complicated. However, it can be simplified by
using mi_varobj_update. That is what this patch does.
gdb/testsuite:
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.exp: Use mi_varobj_update to simplify
tests.
* gdb.mi/mi2-var-child.exp: Likewise.
This test will pass if the CU is the first CU in the binary.
If libc debugging info is installed it may not be, in which case
the CU offset values are wrong.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-out-param.S: Make DW_FORM_ref4 values be the offset
from the start of the CU.
gdb/ChangeLog
2014-10-13 Miroslav Franc <mfranc@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "save breakpoints" for "catch" command.
* break-catch-sig.c (signal_catchpoint_print_recreate): Add trailing
newline.
gdb/testsuite/ChangeLog
2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Yao Qi <yao@codesourcery.com>
Fix "save breakpoints" for "catch" command.
* gdb.base/catch-signal.exp: Add gdb_breakpoint "main".
Remove -nonewline. Match also the added "main" line.
But IMO it is a functionality regression as:
* gdb_test_sequence permits arbitary number of lines of text between those
lines being matched. Former regex string did not allow it.
This may make a difference if GDB regresses by printing some unexpected
line after the breakpoint info line (like a "silent" line).
> * \[\r\n\]+ can be used to anchor the beginning of the pattern, in the sense
> of Perl regex ^ /m match. At least I have found such cases in existing
> *.exp files so I used that. Using ^ really does not work.
>
> But I am not aware how to do Perl regex $ /m match. Using $ really does
> not work. But this means that for example the trailing
> ( \\((host|target) evals\\))?
> on the line
> "\[\r\n\]+\[ \t\]+stop only if i == 1( \\((host|target) evals\\))?"
> originally made sense there but now it can be removed as it has no longer
> any functionality there - it will match now any trailing line garbage.
by Yao Qi:
In this test case, ( \\((host|target) evals\\))? isn't needed in the
pattern. What we test here is to save breakpoints into file and restore
them from file. The contents saved in file are:
break save-bp.c:31
condition $bpnum i == 1
the information about the place where the condition is evaluated isn't
saved, so we don't need to check. Breakpoint save and restore has
nothing to do with where the condition is evaluated (host or target). I
am fine to leave it here now.
gdb/testsuite/ChangeLog
2014-10-09 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/save-bp.exp (info break): Use gdb_test_sequence.
Nowadays, we are using command "tstatus" to send a packet to GDBserver
in order to check the connection. However, on the target doesn't
support tracepoint, the following error is emitted before sending any
packet to GDBserver.
tstatus^M
Trace can not be run on this target.^M
(gdb) FAIL: gdb.server/server-kill.exp: tstatus
qTStatus is disabled after receiving the empty reply during connecting
to the remote target. When the test executes command "tstatus" again,
remote_get_trace_status returns -1 at the very beginning, and no RSP
packet is sent out.
This patch is to enable qTStatus packet again.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Execute command
"set remote trace-status-packet on" before "tstatus".
Hi,
We see the following fail in the real remote testing...
(gdb) Executing on target: kill -9 29808 (timeout = 300)
spawn [open ...]^M
sh: 1: kill: No such process
The test tries to kill gdbserver in this way:
set server_pid [exp_pid -i [board_info target fileid]]
remote_exec target "kill -9 $server_pid"
in native testing, we'll get the pid of spawned gdbserver, however, in
remote testing, we'll get the pid of ssh session, since we start
gdbserver on the remote target through ssh. The pid on build doesn't
exist on target.
In this patch, we tweak server-kill.c to get the parent pid, which is
the pid of GDBserver. GDB gets it and kill GDBserver on target.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.c: Include sys/types.h and unistd.h.
(main): Call getppid.
* gdb.server/server-kill.exp: Set breakpoint on line "i = 0;"
and continue to it. Read variable "server_pid".
This patch is to remove some lines which looks unnecessary. These
lines were added when server-kill.exp was added. In the version 1,
https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html the test
calls runto_main and delete breakpoint on main,
+if ![runto_main] {
+ return -1
+}
+
+# Otherwise the breakpoint at 'main' would not cause insert
breakpoints during
+# first step.
+delete_breakpoints
However, in the version 2
https://sourceware.org/ml/gdb-patches/2013-03/msg00854.html runto_main
is removed but delete_breakpoints is still there. AFAICS, the line of
delete_breakpoints can be removed too.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Remove "delete_breakpoints".
As the result of the patch below, GDB updates thread list when a stop is
presented to user. The tests don't have to fetch thread list explicitly.
[PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes
https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html
This patch is to remove the test code updating thread list.
Run these three tests many times on arm-linux-gnueabi and x86-linux.
No regressions.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.threads/thread-find.exp: Don't execute command
"info threads".
* gdb.threads/attach-into-signal.exp (corefunc): Likewise.
* gdb.threads/linux-dp.exp: Don't check the condition
$threads_created equals to zero.
This does most of the mechanical removal. IOW, the easy part.
This doesn't touch procfs.c as that'd be a harder excision,
potentially affecting Solaris.
mips-tdep.c is left alone. E.g., I didn't delete the GDB_OSABI_IRIX
enum value, nor references to it in mips-tdep.c. Some comments
mentioning IRIX ABIs may still be relevant and I wouldn't know what to
do with them. in That can always be done on a separate pass,
preferably by someone who can test on MIPS.
I didn't remove a reference to IRIX in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.
Built and tested on x86_64 Fedora 20, with --enable-targets=all.
Tested that building for --target=mips-sgi-irix6 on x86_64 Fedora 20
fails with:
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load
*** Configuration mips-sgi-irix6 is obsolete.
*** Support has been REMOVED.
make[1]: *** [configure-gdb] Error 1
make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix'
make: *** [all] Error 2
gdb/
2014-10-10 Pedro Alves <palves@redhat.com>
* Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o.
(ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c.
(HFILES_NO_SRCDIR): Remove solib-irix.h.
* NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6*
and been removed.
* config/mips/irix5.mh, config/mips/irix6.mh: Delete files.
* configure.ac: Remove references to IRIX.
* configure.host: Add *-*-irix* to the obsolete hosts section.
Remove all other references to irix.
* irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h:
Delete files.
gdb/testsuite/
2014-10-10 Pedro Alves <palves@redhat.com>
* gdb.base/bigcore.exp: Remove references to IRIX.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/mips_pro.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/setvar.exp: Likewise.
* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
With upstream glibc, GDB prints:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
A bug's been filed for glibc a few years back:
http://sourceware.org/bugzilla/show_bug.cgi?id=13097
but it's still not resolved. It's not clear whether there's even
consensus that this is indeed a glibc bug. It would actually be nice
if GDB also listed the vDSO in the shared library list, but there are
some design considerations with that:
- the vDSO is mapped by the kernel, not userspace, therefore we
should load its symbols right from the process's start of life,
even before glibc / the userspace loader sets up the initial DSO
list. The program might even be using a custom loader or no
loader.
- that kind of hints at that solib.c should handle retrieving shared
library lists from more than one source, and that symfile-mem.c's
loading of the vDSO would be converted to load and relocate the
vDSO's bfd behind the target_so_ops interface.
- and then, once glibc links in the vDSO to its DSO list, we'd need
to either:
a) somehow hand over the vDSO from one target_so_ops to the other
b) simply keep hiding glibc's entry.
And then b) seems the simplest.
With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.
We can match the vDSO address range with the addresses found iterating
the dynamic linker list, to tell which dynamic linker entry is the
vDSO.
Tested on x86_64 Fedora 20.
gdb/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* solib-svr4.c (svr4_read_so_list): Rename to ...
(svr4_current_sos_1): ... this and change the function comment.
(svr4_current_sos): New function.
gdb/testsuite/
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* gdb.base/vdso-warning.c: New file.
* gdb.base/vdso-warning.exp: New file.
In git b57bacec, I said:
> With that in place, the need to delay "Program received signal FOO"
> was actually caught by the manythreads.exp test. Without that bit, I
> was getting:
>
> [Thread 0x7ffff7f13700 (LWP 4499) exited]
> [New Thread 0x7ffff7f0b700 (LWP 4500)]
> ^C
> Program received signal SIGINT, Interrupt.
> [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output
> [Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
> __GI___nptl_death_event () at events.c:31
> 31 {
> (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
>
> That is, I was now getting "New Thread" lines after the "Program
> received signal" line, and the test doesn't expect them. As the
> number of new threads discovered before and after the "Program
> received signal" output is unbounded, it's much nicer to defer
> "Program received signal" until after synching the thread list, thus
> close to the "switching to thread" output and "current frame/source"
> info:
>
> [Thread 0x7ffff7863700 (LWP 7647) exited]
> ^C[New Thread 0x7ffff786b700 (LWP 7648)]
>
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
> __GI___nptl_create_event () at events.c:25
> 25 {
> (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
This commit factors out the two places in the test that are effected
by this, and adds there a destilled version of the comment above.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
(top level) <stop threads 1, stop threads 2>: Use it.
Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove
"breakpoint always-inserted auto") regressed non-stop remote
debugging.
This was exposed by mi-nsintrall.exp intermittently failing with a
spurious SIGTRAP.
The problem is that when debugging with "target remote", new threads
the target has spawned but have never reported a stop aren't visible
to GDB until it explicitly resyncs its thread list with the target's.
For example, in a program like this:
int
main (void)
{
pthread_t child_thread;
pthread_create (&child_thread, NULL, child_function, NULL);
return 0; <<<< set breakpoint here
}
If the user sets a breakpoint at the "return" statement, and runs the
program, when that breakpoint hit is reported, GDB is only aware of
the main thread. So if we base the decision to remove or insert
breakpoints from the target based on whether all the threads we know
about are stopped, we'll miss that child_thread is running, and thus
we'll remove breakpoints from the target, even through they should
still remain inserted, otherwise child_thread will miss them.
The break-while-running.exp test actually should also be exposing this
thread-list-out-of-synch problem. That test sets a breakpoint while
the main thread is stopped, but other threads are running. Because
other threads are running, the breakpoint is supposed to be inserted
immediately. But, unless something forces a refetch of the thread
list, like, e.g., "info threads", GDB won't be aware of the other
threads that had been spawned by the main thread, and so won't insert
new or old breakpoints in the target. And it turns out that the test
is exactly doing an explicit "info threads", masking out the
problem... This commit adjust the test to exercise the case of not
issuing "info threads". The test then fails without the GDB fix.
In the ni-nsintrall.exp case, what happens is that several threads hit
the same breakpoint, and when the first thread reports the stop,
because GDB wasn't aware other threads exist, all threads known to GDB
are found stopped, so GDB removes the breakpoints from the target.
The other threads follow up with SIGTRAPs too for that same
breakpoint, which has already been removed. For the first few
threads, the moribund breakpoints machinery suppresses the SIGTRAPs,
but after a few events (precisely '3 * thread_count () + 1' at the
time the breakpoint was removed, see update_global_location_list), the
moribund breakpoint machinery is no longer aware of the removed
breakpoint, and the SIGTRAP is reported as a spurious stop.
The fix is naturally then to stop assuming that if no thread in the
list is executing, then the target is fully stopped. We can't know
that until we fully sync the thread list. Because updating the thread
list on every stop would be too much RSP traffic, I chose instead to
update it whenever we're about to present a stop to the user.
Actually updating the thread list at that point happens to be an item
I had added to the local/remote parity wiki page a while ago:
Native GNU/Linux debugging adds new threads to the thread list as
the program creates them "The [New Thread foo] messages". Remote
debugging can't do that, and it's arguable whether we shouldn't even
stop native debugging from doing that, as it hinders inferior
performance. However, a related issue is that with remote targets
(and gdbserver), even after the program stops, the user still needs
to do "info threads" to pull an updated thread list. This, should
most likely be addressed, so that GDB pulls the list itself, perhaps
just before presenting a stop to the user.
With that in place, the need to delay "Program received signal FOO"
was actually caught by the manythreads.exp test. Without that bit, I
was getting:
[Thread 0x7ffff7f13700 (LWP 4499) exited]
[New Thread 0x7ffff7f0b700 (LWP 4500)]
^C
Program received signal SIGINT, Interrupt.
[New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output
[Switching to Thread 0x7ffff7f0b700 (LWP 4500)]
__GI___nptl_death_event () at events.c:31
31 {
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
That is, I was now getting "New Thread" lines after the "Program
received signal" line, and the test doesn't expect them. As the
number of new threads discovered before and after the "Program
received signal" output is unbounded, it's much nicer to defer
"Program received signal" until after synching the thread list, thus
close to the "switching to thread" output and "current frame/source"
info:
[Thread 0x7ffff7863700 (LWP 7647) exited]
^C[New Thread 0x7ffff786b700 (LWP 7648)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff7fc4740 (LWP 6243)]
__GI___nptl_create_event () at events.c:25
25 {
(gdb) PASS: gdb.threads/manythreads.exp: stop threads 1
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoints_should_be_inserted_now): Use
threads_are_executing.
* breakpoint.h (breakpoints_should_be_inserted_now): Add
describing comment.
* gdbthread.h (threads_are_executing): Declare.
(handle_signal_stop) <random signals>: Don't print about the
signal here if stopping.
(end_stepping_range): Don't notify observers here.
(normal_stop): Update the thread list. If stopped by a random
signal or a stepping range ended, notify observers.
* thread.c (threads_executing): New global.
(init_thread_list): Clear 'threads_executing'.
(set_executing): Set or clear 'threads_executing'.
(threads_are_executing): New function.
(update_threads_executing): New function.
(update_thread_list): Use it.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp (test): Add new
'update_thread_list' argument. Skip "info threads" if false.
(top level): Add new 'update_thread_list' axis.
Following an exec with "breakpoint always-inserted on" tries to insert
breakpoints in the new image at the addresses the symbols had in the
old image.
With "always-inserted off", we see:
gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off"
GNU gdb (GDB) 7.8.50.20140924-cvs
...
(gdb) b main
Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24.
^^^^^^^^
(gdb) c
The program is not being run.
(gdb) r
Starting program: testsuite/gdb.multi/multi-arch-exec
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
process 9212 is executing new program: gdb/testsuite/gdb.multi/multi-arch-exec-hello
Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40
40 bar();
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080484e4 in main at gdb/testsuite/gdb.multi/hello.c:40
^^^^^^^^^^
breakpoint already hit 2 times
(gdb)
Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in
gdb.multi/hello.
With "always-inserted on", we get:
Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
24 execl (BASEDIR "/multi-arch-exec-hello",
(gdb) c
Continuing.
infrun: target_wait (-1, status) =
infrun: 9444 [process 9444],
infrun: status->kind = execd
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_EXECD
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400664
(gdb)
That is, GDB is trying to insert a breakpoint at 0x400664, after the
exec, and then that address happens to not be mapped at all in the new
image.
The problem is that update_breakpoints_after_exec is creating
breakpoints, which ends up in update_global_location_list immediately
inserting breakpoints if "breakpoints always-inserted" is "on".
update_breakpoints_after_exec is called very early when we see an exec
event. At that point, we haven't loaded the symbols of the new
post-exec image yet, and thus haven't reset breakpoint's addresses to
whatever they may be in the new image. All we should be doing in
update_breakpoints_after_exec is deleting breakpoints that no longer
make sense after an exec. So the fix removes those breakpoint
creations.
The question is then, if not here, where are those breakpoints
re-created? Turns out we don't need to do anything else, because at
the end of follow_exec, we call breakpoint_re_set, whose tail is also
creating exactly the same breakpoints update_breakpoints_after_exec is
currently creating:
breakpoint_re_set (void)
{
...
create_overlay_event_breakpoint ();
create_longjmp_master_breakpoint ();
create_std_terminate_master_breakpoint ();
create_exception_master_breakpoint ();
}
A new test is added to exercise this.
Tested on x86_64 Fedora 20.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* breakpoint.c (update_breakpoints_after_exec): Don't create
overlay, longjmp, std terminate nor exception breakpoints here.
gdb/testsuite/
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* gdb.base/execl-update-breakpoints.c: New file.
* gdb.base/execl-update-breakpoints.exp: New file.
Currently, with "set breakpoint auto-hw off", we'll still try to
insert a software breakpoint at addresses covered by supposedly
read-only or inacessible regions:
(top-gdb) mem 0x443000 0x450000 ro
(top-gdb) set mem inaccessible-by-default off
(top-gdb) disassemble
Dump of assembler code for function main:
0x0000000000443956 <+34>: movq $0x0,0x10(%rax)
=> 0x000000000044395e <+42>: movq $0x0,0x18(%rax)
0x0000000000443966 <+50>: mov -0x24(%rbp),%eax
0x0000000000443969 <+53>: mov %eax,-0x20(%rbp)
End of assembler dump.
(top-gdb) b *0x0000000000443969
Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29.
(top-gdb) c
Continuing.
warning: cannot set software breakpoint at readonly address 0x443969
Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29
29 args.argc = argc;
(top-gdb)
We warn, saying that the insertion can't be done, but then proceed
attempting the insertion anyway, and in case of manually added
regions, the insert actually succeeds.
This is a regression; GDB used to fail inserting the breakpoint. More
below.
I stumbled on this as I wrote a test that manually sets up a read-only
memory region with the "mem" command, in order to test GDB's behavior
with breakpoints set on read-only regions, even when the real memory
the breakpoints are set at isn't really read-only. I wanted that in
order to add a test that exercises software single-stepping through
read-only regions.
Note that the memory regions that target_memory_map returns aren't
like e.g., what would expect to see in /proc/PID/maps on Linux.
Instead, they're the physical memory map from the _debuggers_
perspective. E.g., a read-only region would be real ROM or flash
memory, while a read-only+execute mapping in /proc/PID/maps is still
read-write to the debugger (otherwise the debugger wouldn't be able to
set software breakpoints in the code segment).
If one tries to manually write to memory that falls within a memory
region that is known to be read-only, with e.g., "p foo = 1", then we
hit a check in memory_xfer_partial_1 before the write mananges to make
it to the target side.
But writing a software/memory breakpoint nowadays goes through
target_write_raw_memory, and unlike when writing memory with
TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path
checks whether we're trying to write to a read-only region.
At the time "breakpoint auto-hw" was added, we didn't have the
TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object
distinction yet, and the code path in memory_xfer_partial that blocks
writes to read-only memory was hit for memory breakpoints too. With
GDB 6.8 we had:
warning: cannot set software breakpoint at readonly address 0000000000443943
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x443943: Input/output error.
So I started out by fixing this by adding the memory region validation
to TARGET_OBJECT_RAW_MEMORY too.
But later, when testing against GDBserver, I realized that that would
only block software/memory breakpoints GDB itself inserts with
gdb/mem-break.c. If a target has a to_insert_breakpoint method, the
insertion request will still pass through to the target. So I ended
up converting the "cannot set breakpoint" warning in breakpoint.c to a
real error return, thus blocking the insertion sooner.
With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY
changes once software single-step breakpoints are converted to real
breakpoints. We need them today as software single-step breakpoints
bypass insert_bp_location. But, it'll be best to leave that in as
safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Error out if inserting a
software breakpoint at a read-only address.
* target.c (memory_xfer_check_region): New function, factored out
from ...
(memory_xfer_partial_1): ... this. Make the 'reg_len' local a
ULONGEST.
(target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access
against the memory region attributes.
gdb/testsuite/
2014-10-01 Pedro Alves <palves@redhat.com>
* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.
Don't reset the exit code at inferior exit and print it in
-list-thread-groups.
gdb/ChangeLog:
* NEWS: Announce new exit-code field in -list-thread-groups
output.
* inferior.c (exit_inferior_1): Don't clear exit code.
(inferior_appeared): Clear exit code.
* mi/mi-main.c (print_one_inferior): Add printing of the exit
code.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-exit-code.exp: New file.
* gdb.mi/mi-exit-code.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Miscellaneous gdb/mi Commands): Document new
exit-code field in -list-thread-groups output.
I see the following fails on arm-linux-gnueabi,
result of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is 1
output of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is not a dynamic executable
child process exited abnormally
FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so
FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so output contains libs
the test script invokes ldd (on host) for the target libraries, which
is wrong. ldd can't be cross because it invokes dynamic linker with
LD_TRACE_LOADED_OBJECTS and gets the dependent libraries. My first
reaction to this problem is to execute ld.so on the target (like
remote_exec target). When I start to hack proc build_executable_own_libs,
I find it has assumptions here and there that the native testing is
performed. Then I check the callers of build_executable_own_libs,
and they are all skipped if isnative is false. It is reasonable to do
the same in dlopen-libpthread.exp too.
gdb/testsuite:
2014-09-30 Yao Qi <yao@codesourcery.com>
* gdb.threads/dlopen-libpthread.exp: Skip it if isnative is
false.
By default, GDB removes all breakpoints from the target when the
target stops and the prompt is given back to the user. This is useful
in case GDB crashes while the user is interacting, as otherwise,
there's a higher chance breakpoints would be left planted on the
target.
But, as long as any thread is running free, we need to make sure to
keep breakpoints inserted, lest a thread misses a breakpoint. With
that in mind, in preparation for non-stop mode, we added a "breakpoint
always-inserted on" mode. This traded off the extra crash protection
for never having threads miss breakpoints, and in addition is more
efficient if there's a ton of breakpoints to remove/insert at each
user command (e.g., at each "step").
When we added non-stop mode, and for a period, we required users to
manually set "always-inserted on" when they enabled non-stop mode, as
otherwise GDB removes all breakpoints from the target as soon as any
thread stops, which means the other threads still running will miss
breakpoints. The test added by this patch exercises this.
That soon revealed a nuisance, and so later we added an extra
"breakpoint always-inserted auto" mode, that made GDB behave like
"always-inserted on" when non-stop was enabled, and "always-inserted
off" when non-stop was disabled. "auto" was made the default at the
same time.
In hindsight, this "auto" setting was unnecessary, and not the ideal
solution. Non-stop mode does depends on breakpoints always-inserted
mode, but only as long as any thread is running. If no thread is
running, no breakpoint can be missed. The same is true for all-stop
too. E.g., if, in all-stop mode, and the user does:
(gdb) c&
(gdb) b foo
That breakpoint at "foo" should be inserted immediately, but it
currently isn't -- currently it'll end up inserted only if the target
happens to trip on some event, and is re-resumed, e.g., an internal
breakpoint triggers that doesn't cause a user-visible stop, and so we
end up in keep_going calling insert_breakpoints. The test added by
this patch also covers this.
IOW, no matter whether in non-stop or all-stop, if the target fully
stops, we can remove breakpoints. And no matter whether in all-stop
or non-stop, if any thread is running in the target, then we need
breakpoints to be immediately inserted. And then, if the target has
global breakpoints, we need to keep breakpoints even when the target
is stopped.
So with that in mind, and aiming at reducing all-stop vs non-stop
differences for all-stop-on-stop-of-non-stop, this patch fixes
"breakpoint always-inserted off" to not remove breakpoints from the
target until it fully stops, and then removes the "auto" setting as
unnecessary. I propose removing it straight away rather than keeping
it as an alias, unless someone complains they have scripts that need
it and that can't adjust.
Tested on x86_64 Fedora 20.
gdb/
2014-09-22 Pedro Alves <palves@redhat.com>
* NEWS: Mention merge of "breakpoint always-inserted" modes "off"
and "auto" merged.
* breakpoint.c (enum ugll_insert_mode): New enum.
(always_inserted_mode): Now a plain boolean.
(show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO.
(breakpoints_always_inserted_mode): Delete.
(breakpoints_should_be_inserted_now): New function.
(insert_breakpoints): Pass UGLL_INSERT to
update_global_location_list instead of calling
insert_breakpoint_locations manually.
(create_solib_event_breakpoint_1): New, factored out from ...
(create_solib_event_breakpoint): ... this.
(create_and_insert_solib_event_breakpoint): Use
create_solib_event_breakpoint_1 instead of calling
insert_breakpoint_locations manually.
(update_global_location_list): Change parameter type from boolean
to enum ugll_insert_mode. All callers adjusted. Adjust to use
breakpoints_should_be_inserted_now and handle UGLL_INSERT.
(update_global_location_list_nothrow): Change parameter type from
boolean to enum ugll_insert_mode.
(_initialize_breakpoint): "breakpoint always-inserted" option is
now a boolean command. Update help text.
* breakpoint.h (breakpoints_always_inserted_mode): Delete declaration.
(breakpoints_should_be_inserted_now): New declaration.
* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
Remove breakpoints_always_inserted_mode check.
(normal_stop): Adjust to use breakpoints_should_be_inserted_now.
* remote.c (remote_start_remote): Likewise.
gdb/doc/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Set Breaks): Document that "set breakpoint
always-inserted off" is the default mode now. Delete
documentation of "set breakpoint always-inserted auto".
gdb/testsuite/
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp: New file.
* gdb.threads/break-while-running.c: New file.
This patch is to extend dw2-var-zero-add.exp to cover the case that
partial symtabl is not used while full symtab is used, in order to
cover the changes in patch 2/3. This patch restarts GDB with
--readnow and does the same test again.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-var-zero-addr.exp: Move test into new proc test.
Invoke test. Restart GDB with --readnow and invoke test again.
I see the following fail on arm-none-eabi target,
(gdb) b 24^M
Breakpoint 1 at 0x4: file
../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc,
line 24.^M
(gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24
Currently, we are using flag has_section_at_zero to determine whether
address zero in debug info means the corresponding code has been
GC'ed, like this:
case DW_LNE_set_address:
address = read_address (abfd, line_ptr, cu, &bytes_read);
if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
{
/* This line table is for a function which has been
GCd by the linker. Ignore it. PR gdb/12528 */
However, this is incorrect on some bare metal targets, as .text
section is located at 0x0, so dwarf2_per_objfile->has_section_at_zero
is true. If a function is GC'ed by linker, the address is zero. GDB
thinks address zero is a function's address rather than this function
is GC'ed.
In this patch, we choose 'lowpc' got in read_file_scope to check
whether 'lowpc' is greater than zero. If it isn't, address zero really
means the function is GC'ed. In this patch, we pass 'lowpc' in
read_file_scope through handle_DW_AT_stmt_list and dwarf_decode_lines,
and to dwarf_decode_lines_1 finally.
This patch fixes the fail above. This patch also covers the path that
partial symbol isn't used, which is tested by starting gdb with
--readnow option.
It is regression tested on x86-linux with
target_board=dwarf4-gdb-index, and arm-none-eabi. OK to apply?
gdb:
2014-09-19 Yao Qi <yao@codesourcery.com>
* dwarf2read.c (dwarf_decode_lines): Update declaration.
(handle_DW_AT_stmt_list): Add argument 'lowpc'. Update
comments. Callers update.
(dwarf_decode_lines): Likewise.
(dwarf_decode_lines_1): Add argument 'lowpc'. Update
comments. Skip the line table if 'lowpc' is greater than
'address'. Don't check
dwarf2_per_objfile->has_section_at_zero.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.base/break-on-linker-gcd-function.exp: Move test into new
proc set_breakpoint_on_gcd_function. Invoke
set_breakpoint_on_gcd_function. Restart GDB with --readnow and
invoke set_breakpoint_on_gcd_function again.
This is just a testcase addition that I am proposing for upstream GDB.
We have this in our internal tree, and the related RH bug is:
<https://bugzilla.redhat.com/show_bug.cgi?id=809179>
(You might not be able to see all the comments without privileges.)
This bug is about a global variable that got incorrectly displayed by
GDB. This bug has already been fixed a long time ago by Joel's
commit:
commit 19630284f5
Author: Joel Brobecker <brobecker@gnat.com>
Date: Tue Jun 5 13:50:50 2012 +0000
But I think a testcase for it wouldn't hurt.
So, consider the following scenario:
$ cat solib1.c
int test;
void c_main (void)
{
test = 42;
}
$ cat solib2.c
int test;
void b_main (void)
{
test = 42;
}
$ cat main.c
int main (int argc, char *argv[])
{
c_main ();
b_main ();
return 0;
}
$ gcc -g -fPIC -shared -o libSO1.so -c solib1.c
$ gcc -g -fPIC -shared -o libSO2.so -c solib2.c
$ gcc -g -o main -L$PWD -lSO1 -lSO2 main.c
$ LD_LIBRARY_PATH=. gdb -q -batch -ex 'b c_main' -ex r -ex n -ex 'p test' ./main
...
$1 = 0
This happened with GDB before Joel's commit above. Now, things work
and GDB is able to correctly display the nested global variable:
$ LD_LIBRARY_PATH=. gdb -q -batch -ex 'b c_main' -ex r -ex n -ex 'p test' ./main
...
$1 = 42
The testcase attached tests this behavior.
gdb/testsuite/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/global-var-nested-by-dso-solib1.c: New file.
* gdb.base/global-var-nested-by-dso-solib2.c: Likewise.
* gdb.base/global-var-nested-by-dso.c: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
Make test messages unique and a couple other tweaks.
gdb/testsuite/
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/watch-bitfields.exp: Pass string other than test file
name to prepare_for_testing.
(watch): New procedure.
(expect_watchpoint): Use with_test_prefix.
(top level): Factor out tests to ...
(test_watch_location, test_regular_watch): ... these new
procedures, and use with_test_prefix and gdb_continue_to_end.
PR 12526 reports that -location watchpoints against bitfield arguments
trigger false positives when bits around the bitfield, but not the
bitfield itself, are modified.
This happens because -location watchpoints naturally operate at the
byte level, not at the bit level. When the address of a bitfield
lvalue is taken, information about the bitfield (i.e. its offset and
size) is lost in the process.
This information must first be retained throughout the lifetime of the
-location watchpoint. This patch achieves this by adding two new
fields to the watchpoint struct: val_bitpos and val_bitsize. These
fields are set when a watchpoint is first defined in watch_command_1.
They are both equal to zero if the watchpoint is not a -location
watchpoint or if the argument is not a bitfield.
Then these bitfield parameters are used inside update_watchpoint and
watchpoint_check to extract the actual value of the bitfield from the
watchpoint address, with the help of a local helper function
extract_bitfield_from_watchpoint_value.
Finally when creating a HW breakpoint pointing to a bitfield, we
optimize the address and length of the breakpoint. By skipping over
the bytes that don't cover the bitfield, this step reduces the
frequency at which a read watchpoint for the bitfield is triggered.
It also reduces the number of times a false-positive call to
check_watchpoint is triggered for a write watchpoint.
gdb/
PR breakpoints/12526
* breakpoint.h (struct watchpoint): New fields val_bitpos and
val_bitsize.
* breakpoint.c (watch_command_1): Use these fields to retain
bitfield information.
(extract_bitfield_from_watchpoint_value): New function.
(watchpoint_check): Use it.
(update_watchpoint): Use it. Optimize the address and length of a
HW watchpoint pointing to a bitfield.
* value.h (unpack_value_bitfield): New prototype.
* value.c (unpack_value_bitfield): Make extern.
gdb/testsuite/
PR breakpoints/12526
* gdb.base/watch-bitfields.exp: New file.
* gdb.base/watch-bitfields.c: New file.
Silly typo...
gdb/testsuite/
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-stops-at-right-insn.exp (test): Compare
software and hardware addresses, not software address against
itself.
This adds a test that makes sure GDB knows whether the target has
continuable, or non-continuable watchpoints.
That is, the test confirms that GDB presents a watchpoint value change
at the first instruction right after the instruction that changes
memory.
gdb/testsuite/ChangeLog:
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-stops-at-right-insn.c: New file.
* gdb.base/watchpoint-stops-at-right-insn.exp: New file.
In the recent review to my patch about copying files to remote host,
we find that we need a board file which is more closely mapped real
remote host testing to improve coverage. With the board file
local-remote-host-native.exp, DejaGNU copies files to
$build/gdb/testsuite/remote-host to emulate the effect of remote host.
Is it OK?
gdb/testsuite:
2014-09-16 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-native.exp: New file.
The test does a backtrace to see which thread (#2 or #3) is assigned
to which SIGUSR (1 or 2). If the main thread gets to all_threads_running
before the sigusr threads get to their entry point, then the function
name isn't in the backtrace and the test fails.
Alas this version of the code is within epsilon of what I started with,
and then over-simplified things.
If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".
This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.
One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command. I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.
gdb/ChangeLog:
* NEWS: Mention new "queue-signal" command.
* infcmd.c (queue_signal_command): New function.
(_initialize_infcmd): Add new queue-signal command.
gdb/doc/ChangeLog:
* gdb.texinfo (Signaling): Document new queue-signal command.
gdb/testsuite/ChangeLog:
* gdb.threads/queue-signal.c: New file.
* gdb.threads/queue-signal.exp: New file.
I had occasion to use with_gdb_prompt in a test for the patch for PR 17314
and was passing the plain text prompt as the value, "(top-gdb)",
instead of a regexp, "\(top-gdb\)" (expressed as "\\(top-gdb\\)" in TCL).
I then discovered that in order to restore the prompt gdb passes the
original value of $gdb_prompt to "set prompt", which works because
"set prompt \(gdb\) " is equivalent to "set prompt (gdb) ".
Perhaps I'm being overly cautious but this feels a bit subtle,
but at any rate as an API choice I'd much rather pass the plain text
form to with_gdb_prompt.
I also discovered that the initial value of gdb_prompt is set in
two places to two different values.
At the global level gdb.exp sets it to "\[(\]gdb\[)\]"
and default_gdb_init sets it to "\\(gdb\\)".
The former form is undesirable as an argument to "set prompt",
but it's not clear to me that just deleting this code won't break
anything. Thus I just changed the value to be consistent and added
a comment.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_prompt): Add comment and change initial value to
be consistent with what default_gdb_init uses.
(with_gdb_prompt): Change form of PROMPT argument from a regexp to
the plain text of the prompt. Add some logging printfs.
* gdb.perf/disassemble.exp: Update call to with_gdb_prompt.
See:
https://sourceware.org/ml/gdb-patches/2014-09/msg00404.html
We have a number of places that do gdb_run_cmd followed by gdb_expect,
when it would be better to use gdb_test_multiple or gdb_test.
This converts all that "grep gdb_run_cmd -A 2 | grep gdb_expect"
found.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/testsuite/
2014-09-12 Pedro Alves <palves@redhat.com>
* gdb.arch/gdb1558.exp: Replace uses of gdb_expect after
gdb_run_cmd with gdb_test_multiple or gdb_test throughout.
* gdb.arch/i386-size-overlap.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.
* gdb.arch/i386-unwind.exp: Likewise.
* gdb.base/a2-run.exp: Likewise.
* gdb.base/break.exp: Likewise.
* gdb.base/charset.exp: Likewise.
* gdb.base/chng-syms.exp: Likewise.
* gdb.base/commands.exp: Likewise.
* gdb.base/dbx.exp: Likewise.
* gdb.base/find.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/jit-simple.exp: Likewise.
* gdb.base/reread.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/step-bt.exp: Likewise.
* gdb.cp/mb-inline.exp: Likewise.
* gdb.cp/mb-templates.exp: Likewise.
* gdb.objc/basicclass.exp: Likewise.
* gdb.threads/killed.exp: Likewise.
The problem is that rs6000_frame_cache attempts to read the stack backchain via
read_memory_unsigned_integer, which throws an exception if the stack pointer is
invalid. With this patch, it calls safe_read_memory_integer instead, which
doesn't throw an exception and allows for safe handling of that situation.
gdb/ChangeLog
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Ulrich Weigand <uweigand@de.ibm.com>
PR tdep/17379
* rs6000-tdep.c (rs6000_frame_cache): Use safe_read_memory_integer
instead of read_memory_unsigned_integer.
gdb/testcase/ChangeLog
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
PR tdep/17379
* gdb.arch/powerpc-stackless.S: New file.
* gdb.arch/powerpc-stackless.exp: New file.
I have started seeing occasional runaway 'attach' processes these days.
I cannot be certain it is really caused by this patch, for example
grep 'FAIL.*cmdline attach run' does not show anything in my logs.
But as I remember this 'attach' runaway process always happened in GDB (but
I do not remember it in the past months) I think it would be most safe to just
solve it forever by [attached].
gdb/testsuite/ChangeLog
2014-09-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/attach.c: Include unistd.h.
(main): Call alarm. Add label postloop.
* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
gdb_breakpoint, gdb_continue_to_breakpoint.
(test_command_line_attach_run): Kill ${testpid} in one exit path.
Doing:
gdb --pid=PID -ex run
Results in GDB getting a SIGTTIN, and thus ending stopped. That's
usually indicative of a missing target_terminal_ours call.
E.g., from the PR:
$ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
[1] 28263
[1] Killed sleep 1h
[2]+ Stopped gdb -batch sleep $p -ex run
The workaround is doing:
gdb -ex "attach $PID" -ex "run"
instead of
gdb [-p] $PID -ex "run"
With the former, gdb waits for the attach command to complete before
moving on to the "run" command, because the interpreter is in sync
mode at this point, within execute_command. But for the latter,
attach_command is called directly from captured_main, and thus misses
that waiting. IOW, "run" is running before the attach continuation
has run, before the program stops and attach completes. The broken
terminal settings are just one symptom of that. Any command that
queries or requires input results in the same.
The fix is to wait in catch_command_errors (which is specific to
main.c nowadays), just like we wait in execute_command.
gdb/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* main.c: Include "infrun.h".
(catch_command_errors, catch_command_errors_const): Wait for the
foreground command to complete.
* top.c (maybe_wait_sync_command_done): New function, factored out
from ...
(maybe_wait_sync_command_done): ... here.
* top.h (maybe_wait_sync_command_done): New declaration.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
* gdb.base/attach.exp (test_command_line_attach_run): New
procedure.
(top level): Call it.
Several places in the testsuite have a copy of a snippet of code that
spawns a test program, waits a bit, and then does some PID munging for
Cygwin. This is in order to have GDB attach to the spawned program.
This refactors all that to a common procedure.
(multi-attach.exp wants to spawn multiple processes, so this makes the
new procedure's interface work with lists.)
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (spawn_wait_for_attach): New procedure.
* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
(do_command_attach_tests): Use spawn_wait_for_attach.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
This fixes two FAIL results on this testcase which were caused by a
misplaced "continue" command. This testcase used to end inferior's
execution too soon, causing the following tests to fail. Now we break
right after inferior's loop and perform the rest of the tests there.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-element.exp: Remove unexpected "continue"
command in testcase. Simplify testcase.
Trying to print the bounds or the length of a pointer to an array
whose bounds are dynamic results in the following error:
(gdb) p foo.three_ptr.all'first
Location address is not set.
(gdb) p foo.three_ptr.all'length
Location address is not set.
This is because, after having dereferenced our array pointer, we
use the type of the resulting array value, instead of the enclosing
type. The former is the original type where the bounds are unresolved,
whereas we need to get the actual array bounds.
Similarly, trying to apply those attributes to the array pointer
directly (without explicitly dereferencing it with the '.all'
operator) yields the same kind of error:
(gdb) p foo.three_ptr'first
Location address is not set.
(gdb) p foo.three_ptr'length
Location address is not set.
This is caused by the fact that the dereference was done implicitly
in this case, and perform at the type level only, which is not
sufficient in order to resolve the array type.
This patch fixes both issues, thus allowing us to get the expected output:
(gdb) p foo.three_ptr.all'first
$1 = 1
(gdb) p foo.three_ptr.all'length
$2 = 3
(gdb) p foo.three_ptr'first
$3 = 1
(gdb) p foo.three_ptr'length
$4 = 3
gdb/ChangeLog:
* ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR,
dereference it first. Use value_enclosing_type instead of
value_type.
(ada_array_length): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
Consider a pointer to an array which dynamic bounds, described in
DWARF as follow:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is now able to correctly print the entire array, but not one
element of the array. Eg:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
(gdb) p foo.three_ptr.all(1)
Cannot access memory at address 0xfffffffff4123a0c
The problem occurs because we are missing a dynamic resolution of
the variable's array type when subscripting the array. What the current
code does is "fix"-ing the array type using the GNAT encodings, but
that operation ignores any of the array's dynamic properties.
This patch fixes the issue by using ada_value_ind to dereference
the array pointer, which takes care of the array type resolution.
It also continues to "fix" arrays described using GNAT encodings,
so backwards compatibility is preserved.
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Remove parameter "type".
Adjust function implementation and documentation accordingly.
(ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if
NOSIDE is EVAL_AVOID_SIDE_EFFECTS.
Update call to ada_value_ptr_subscript.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
Consider the following declaration:
type Array_Type is array (Natural range <>) of Integer;
type Array_Ptr is access all Array_Type;
for Array_Ptr'Size use 64;
Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3);
This creates a pointer to an array where the bounds are stored
in a memory region just before the array itself (aka a "thin pointer").
In DWARF, this is described as a the usual pointer type to an array
whose subrange has dynamic values for its bounds:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is currently printing the value of the array incorrectly:
(gdb) p foo.three_ptr.all
$1 = (26629472 => 1, 2,
value.c:819: internal-error: value_contents_bits_eq: [...]
The dereferencing (".all" operator) is done by calling ada_value_ind,
which itself calls value_ind. It first produces a new value where
the bounds of the array were correctly resolved to their actual value,
but then calls readjust_indirect_value_type which replaces the resolved
type by the original type.
The problem starts when ada_value_print does not take this situation
into account, and starts using the type of the resulting value, which
has unresolved array bounds, instead of using the value's enclosing
type.
After fixing this issue, the debugger now correctly prints:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use VAL's enclosing type
instead of VAL's type.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.c: New file.
* gdb.dwarf2/dynarr-ptr.exp: New file.
Similarly to the previous changes to gdb.reverse/sigall-reverse.exp and
gdb.reverse/until-precsave.exp this corrects the timeout tweak in
gdb.base/watchpoint-solib.exp.
This test case executes a large amount of code with a software watchpoint
enabled. This means single-stepping all the way through and takes a lot
of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 714
for the same board and a `-mthumb -march=armv5te' multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 1275
and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:
PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 115
(values in seconds) -- all of which having the default timeout of 60s,
set based on the requirement of the remaining test cases (other than
gdb.reverse ones).
Here again the timeout extension to have a meaning should be calculated
by scaling rather than using an arbitrary constant, and a larger factor
of 30 will do, leaving some margin. Hopefully for everyone or otherwise
we'll probably have to come up with a smarter solution.
OTOH the other test cases in this script do not require the extension so
they can be moved outside its umbrella so as to avoid unnecessary delays
if something goes wrong and a genuine timeout triggers.
* gdb.base/watchpoint-solib.exp: Increase the timeout by a factor
of 30 rather than hardcoding 120 for a slow test case. Take the
`gdb,timeout' target setting into account for this calculation.
Don't extend the timeout for the test cases that don't need it.
There are three cases in two scripts in the gdb.reverse subset that
take a particularly long time. Two of them are already attempted to
take care of by extending the timeout from the default. The remaining
one has no precautions taken. The timeout extension is ineffective
though, it is done by adding a constant rather than by scaling and as
a result while it may work for target boards that get satisfied with
the detault test timeout of 10s, it does not serve its purpose for
slower ones.
Here are indicative samples of execution times (in seconds) observed
for these cases respectively, for an ARMv7 Panda board running Linux
and a `-march=armv5te' multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 385
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4440
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 965
for the same board and a `-mthumb -march=armv5te' multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 465
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4191
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 669
and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:
PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 45
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 433
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 104
Based on the performance of other tests these two test configurations
have their default timeout set to 450s and 60s respectively.
The remaining two multilibs (`-mthumb -march=armv4t' and `-mthumb
-march=armv7-a') do not produce test results usable enough to have data
available for these cases.
Based on these results I have tweaked timeouts for these cases as
follows. This, together with a suitable board timeout setting, removes
timeouts for these cases. Note that for the default timeout of 10s the
new setting for the first case in gdb.reverse/until-precsave.exp is
compatible with the old one, just a bit higher to keep the convention
of longer timeouts to remain multiples of 30s. The second case there
does not need such a high setting so I have lowered it a bit to avoid
an unnecessary delay where this test case genuinely times out.
* gdb.reverse/sigall-reverse.exp: Increase the timeout by
a factor of 2 for a slow test case. Take the `gdb,timeout'
target setting into account for this calculation.
* gdb.reverse/until-precsave.exp: Increase the timeout by
a factor of 15 and 3 respectively rather than adding 120
for a pair of slow test cases. Take the `gdb,timeout'
target setting into account for this calculation.
The recent change to introduce `gdb_reverse_timeout' turned out
ineffective for board setups that set the `gdb,timeout' target variable.
A lower `gdb,timeout' setting takes precedence and defeats the effect of
`gdb_reverse_timeout'. This is because the global timeout is overridden
in gdb_test_multiple and then again in gdb_expect.
Three timeout variables are taken into account in these two places, in
this precedence:
1. The `gdb,timeout' target variable.
2. The caller's local `timeout' variable (upvar timeout)
3. The global `timeout' variable.
This precedence is obeyed by gdb_test_multiple strictly. OTOH
gdb_expect will select the higher of the two formers and will only take
the latter into account if none of the formers is present. However the
two timeout selections are conceptually the same and gdb_test_multiple
does its only for the purpose of passing it down to gdb_expect.
Therefore I decided there is no point to keep carrying on this
duplication and removed the sequence from gdb_test_multiple, however
retaining the `upvar timeout' variable definition. This way gdb_expect
will still access gdb_test_multiple's caller `timeout' variable (if any)
via its own `upvar timeout' reference.
Now as to the sequence in gdb_expect. In addition to the three
variables described above it also takes a timeout argument into account,
as the fourth value to choose from. It is currently used if it is
higher than the timeout selected from the variables as described above.
With the timeout selection code from gdb_test_multiple gone, gone is
also the most prominent use of this timeout argument, it's now used in
a couple of places only, mostly within this test framework library code
itself for preparatory commands or suchlike. With this being the case
this timeout selection code can be simplified as follows:
1. Among the three timeout variables, the highest is always chosen.
This is so that a test case doesn't inadvertently lower a high value
timeout needed by slow target boards. This is what all test cases
use.
2. Any timeout argument takes precedence. This is for special cases
such as within the framework library code, e.g. it doesn't make sense
to send `set height 0' with a timeout of 7200 seconds. This is a
local command that does not interact with the target and setting a
high timeout here only risks a test suite run taking ages if it goes
astray for some reason.
3. The fallback timeout of 60s remains.
* lib/gdb.exp (gdb_test_multiple): Remove code to select the
timeout, don't pass one down to gdb_expect.
(gdb_expect): Rework timeout selection.
As it happens we have a board that fails a gdb.base/gcore-relro.exp
test case reproducibly and moreover the case appears to trigger a
kernel bug making the it less than usable. Specifically the board
remains responsive to some extent, however processes do not appear
to be able to successfully complete termination anymore and perhaps
more importantly further gdbserver processes can be started, but they
never reach the stage of listening on the RSP socket.
This change handles timeouts in gdbserver start properly, by throwing
a TCL error exception when gdbserver does not report listening on the
RSP socket in time. This is then caught at the outer level and
reported, and 2 rather than 1 is returned so that the caller may tell
the failure to start gdbserver and other issues apart and act
accordingly (or do nothing).
I thought letting the exception unwind further on might be a good idea
for any test harnesses out there to break outright where a gdbserver
start error is silently ignored right now, however I figured out the
calls to gdbserver-support.exp are buried down too deep in the GDB test
suite for such a change to be made easily. I think returning a distinct
return value is good enough (the API says "non-zero", so 2 is as good as
1) and we can always make the error harder in a later step if required.
With config/gdbserver.exp being used this change remains transparent
to the target board, the return value is passed up by gdb_reload and
the error exception unwinds through gdbserver_gdb_load and is caught
and handled by mi_gdb_target_load. A call to perror is still made,
reporting the timeout, and in the case of mi_gdb_target_load the
procedure returns a value denoting unsuccessful completion. An
unsuccessful completion of gdb_reload is already handled elsewhere.
An alternative gdbserver board configuration can interpret the return
value in its gdb_reload implementation and catch the error in
gdbserver_gdb_load in an attempt to recover a target board that has
gone astray, for example by rebooting the board somehow. This has
proved effective with our failing board, that now completes the
remaining test cases with no further hiccups.
* lib/gdbserver-support.exp (gdbserver_start): Throw an error
exception on timeout.
(gdbserver_run): Catch any `gdbserver_spawn' error exceptions.
(gdbserver_start_extended): Catch any `gdbserver_start' error
exceptions.
(gdbserver_start_multi, mi_gdbserver_start_multi): Likewise.
* lib/mi-support.exp (mi_gdb_target_load): Catch any
`gdbserver_gdb_load' error exceptions.
Gdbserver support code uses the global timeout value to determine when
to stop waiting for a gdbserver process being started to respond before
continuing anyway. This timeout is usually as low as 10s and may not
be enough in this context, for example on the first run where the
filesystem cache is cold, even if it is elsewhere.
E.g. I observe this reliably with gdbserver started the first time in
QEMU running in the system emulation mode:
(gdb) file .../gdb.base/advance
Reading symbols from .../gdb.base/advance...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c,
line 41.
(gdb) set remotetimeout 15
(gdb) kill
The program is not being run.
(gdb)
[...]
.../bin/gdbserver --once :6014 advance
target remote localhost:6014
Remote debugging using localhost:6014
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) continue
The program is not being run.
(gdb) Process advance created; pid = 999
Listening on port 6014
FAIL: gdb.base/advance.exp: Can't run to main
-- notice how the test harness proceeded with the `target remote ...'
command even though gdbserver hasn't completed its startup yet. A
while later when it's finally ready it's too late already. I checked
the timing here and it takes gdbserver roughly 25 seconds to start in
this scenario. Subsequent gdbserver starts in the same test run take
less time and usually complete within 10 seconds although occasionally
`target remote ...' precedes the corresponding `Listening on port...'
message again.
Therefore I have fixed this problem by setting an explicit timeout to
120s on the expect call in question. If this turns out too arbitrary
sometime, then perhaps a separate `gdbserver_timeout' setting might be
due.
* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
120 on waiting for the TCP socket to open.
Hi,
I see the following fail on arm-none-eabi target,
-var-evaluate-expression -f nat foo^M
^done,value="0x3 <_ftext+2>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: eval variable -f nat foo
the "<_ftext+2>" isn't expected in the test, so "set print symbol off"
can prevent printing it. It is obvious and I'll commit it in three
days if no comments.
gdb/testsuite:
2014-09-09 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-display.exp: Set print symbol off.
have empty bodies.
User-defined commands that have empty bodies weren't being shown because
the print function returned too soon. Now, it prints the command's name
before checking if it has any body at all. This also fixes the same
problem on "show user <myemptycommand>", which wasn't being printed due
to a similar reason.
gdb/Changelog:
* cli/cli-cmds.c (show_user): Use cli_user_command_p to
decide whether we display the command on "show user".
* cli/cli-script.c (show_user_1): Only verify cmdlines after
printing command name.
* cli/cli-decode.h (cli_user_command_p): Declare new function.
* cli/cli-decode.c (cli_user_command_p): Create helper function
to verify whether cmd_list_element is a user-defined command.
gdb/testsuite/Changelog:
* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.
https://bugzilla.redhat.com/show_bug.cgi?id=1126177
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540
T0)
#0 0x992bee in value_type .../gdb/value.c:925
#1 0x87c951 in py_print_single_arg python/py-framefilter.c:445
#2 0x87cfae in enumerate_args python/py-framefilter.c:596
#3 0x87e0b0 in py_print_args python/py-framefilter.c:968
It crashes because frame_arg::val is documented it may contain NULL
(frame_arg::error is then non-NULL) but the code does not handle it.
Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH
which messes up GDB cleanup chain crashing GDB later.
It is probably 7.7 regression (I have not verified it) due to the introduction
of Python frame filters.
gdb/ChangeLog
PR python/17355
* python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL.
Fix goto out of TRY_CATCH.
gdb/testsuite/ChangeLog
PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.
This patch is a fix to PR gdb/17235. The bug is about an unused
variable that got declared and set during one of the parsing phases of
an SDT probe's argument. I took the opportunity to rewrite some of the
code to improve the parsing. The bug was actually a thinko, because
what I wanted to do in the code was to discard the number on the string
being parsed.
During this portion, the code identifies that it is dealing with an
expression that begins with a sign ('+', '-' or '~'). This means that
the expression could be:
- a numeric literal (e.g., '+5')
- a register displacement (e.g., '-4(%rsp)')
- a subexpression (e.g., '-(2*3)')
So, after saving the sign and moving forward 1 char, now the code needs
to know if there is a digit followed by a register displacement prefix
operand (e.g., '(' on x86_64). If yes, then it is a register
operation. If not, then it will be handled recursively, and the code
will later apply the requested operation on the result (either a '+', a
'-' or a '~').
With the bug, the code was correctly discarding the digit (though using
strtol unnecessarily), but it wasn't properly dealing with
subexpressions when the register indirection prefix was '(', like on
x86_64. This patch also fixes this bug, and includes a testcase. It
passes on x86_64 Fedora 20.
This commit fixes the PR mentioned in $subject. It is about a set but
unused variable that refers to the output format of integer values
printed in Fortran.
This was probably a thinko (like most set-but-unused-vars), but it
could cause an internal error depending on the scenario. I am sending
a testcase which triggers this error as well.
gdb/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* f-valprint.c (f_val_print): Specify the correct print option to
use when printing integer values.
gdb/testsuite/ChangeLog:
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* gdb.fortran/print-formatted.exp: New file.
* gdb.fortran/print-formatted.f90: Likewise.
The ability to read registers is needed to use Frame Filter API to
display the frames created by JIT compilers.
gdb/ChangeLog:
2014-08-29 Sasha Smundak <asmundak@google.com>
* python/py-frame.c (frapy_read_register): New function.
gdb/doc/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* python.texi (Frames in Python): Add read_register description.
gdb/testsuite/ChangeLog:
2014-08-26 Sasha Smundak <asmundak@google.com>
* gdb.python/py-frame.exp: Test Frame.read_register.
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
This commit renames nine files that contain code used by both 32- and
64-bit Intel ports such that their names are prefixed with "x86"
rather than "i386". All types, functions and variables within these
files are likewise renamed such that their names are prefixed with
"x86" rather than "i386". This makes GDB follow the convention used
by gdbserver such that 32-bit Intel code lives in files called
"i386-*", 64-bit Intel code lives in files called "amd64-*", and code
for both 32- and 64-bit Intel lives in files called "x86-*".
This commit only renames OS-independent files. The Linux ports of
both GDB and gdbserver now follow the i386/amd64/x86 convention fully.
Some ports still use the old convention where "i386" in file/function/
type/variable names can mean "32-bit only" or "32- and 64-bit" but I
don't want to touch ports I can't fully test except where absolutely
necessary.
gdb/ChangeLog:
* i386-nat.h: Renamed as...
* x86-nat.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-nat.c: Renamed as...
* x86-nat.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* common/i386-xstate.h: Renamed as...
* common/x86-xstate.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-cpuid.h: Renamed as...
* nat/x86-cpuid.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-gcc-cpuid.h: Renamed as...
* nat/x86-gcc-cpuid.h: New file. All type, function and variable
name prefixes changed from "i386_" to "x86_". All references
updated.
* nat/i386-dregs.h: Renamed as...
* nat/x86-dregs.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* nat/i386-dregs.c: Renamed as...
* nat/x86-dregs.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
gdb/gdbserver/ChangeLog:
* i386-low.h: Renamed as...
* x86-low.h: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
* i386-low.c: Renamed as...
* x86-low.c: New file. All type, function and variable name
prefixes changed from "i386_" to "x86_". All references updated.
clang was using eax to construct %0 here:
asm ("mov %%eax, 0(%0)\n\t"
"mov %%ebx, 4(%0)\n\t"
"mov %%ecx, 8(%0)\n\t"
"mov %%edx, 12(%0)\n\t"
"mov %%esi, 16(%0)\n\t"
"mov %%edi, 20(%0)\n\t"
: /* no output operands */
: "r" (data)
: "eax", "ebx", "ecx", "edx", "esi", "edi");
which caused amd64-word.exp (and others similarly) to fail.
It's a perfectly legit thing for clang to do given the available data.
The patch fixes this by marking the registers as live from the
time of the preceding breakpoint.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-pseudo.c (main): Rewrite to better specify when
eax,etc. are live with values set by gdb and thus the compiler can't
use them.
* gdb.arch/i386-pseudo.c (main): Ditto.
I see the following fails on arm-none-eabi target,
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.python/py-value.exp: print sn
print sn^M
$14 = 0x0 <_ftext>^M
(gdb) FAIL: gdb.guile/scm-value.exp: print sn
as <_ftext> is unexpected. This patch is to set print symbol off to
avoid printing this.
gdb/testsuite:
2014-08-24 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-value.exp (test_lazy_strings): Set print
symbol off.
* gdb.python/py-value.exp (test_lazy_strings): Likewise.
See the description here:
https://sourceware.org/ml/gdb-patches/2014-08/msg00283.html
This patch keeps track of whether the current line has seen a
non-zero discriminator, and if so coalesces consecutive entries
for the same line (by ignoring all entries after the first).
gdb/ChangeLog:
PR 17276
* dwarf2read.c (dwarf_record_line_p): New function.
(dwarf_decode_lines_1): Ignore subsequent line number entries
for the same line if any entry had a non-zero discriminator.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-single-line-discriminators.S: New file.
* gdb.dwarf2/dw2-single-line-discriminators.c: New file.
* gdb.dwarf2/dw2-single-line-discriminators.exp: New file.
Some gdb.python/*.exp tests fail because the .py files aren't copied
to the (remote) host. This patch is to copy needed .py files to host.
Most of gdb.python/*.exp tests do this.
As it is still controversial to delete *.py files on host, we don't do
that in this patch.
gdb/testsuite:
2014-08-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/python.exp: Likewise. Use .py file on the host
instead of the build.
Program received signal SIGABRT, Aborted.
[...]
(gdb) gcore foobar
Couldn't get registers: No such process.
(gdb) info threads
[...]
(gdb) gcore foobar
Saved corefile foobar
(gdb)
gcore tries to access the exited thread:
[Thread 0x7ffff7fce700 (LWP 6895) exited]
ptrace(PTRACE_GETREGS, 6895, 0, 0x7fff18167dd0) = -1 ESRCH (No such process)
Without the TRY_CATCH protection testsuite FAILs for:
gcore .../gdb/testsuite/gdb.threads/gcore-thread0.test
Cannot find new threads: debugger service failed
(gdb) FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile
+
core .../gdb/testsuite/gdb.threads/gcore-thread0.test
".../gdb/testsuite/gdb.threads/gcore-thread0.test" is not a core dump: File format not recognized
(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format)
Maybe the TRY_CATCH could be more inside update_thread_list().
Similar update_thread_list() call is IMO missing in procfs_make_note_section()
but I do not have where to verify that change.
gdb/ChangeLog
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* linux-tdep.c (linux_corefile_thread_callback): Ignore THREAD_EXITED.
(linux_make_corefile_notes): call update_thread_list, protected against
exceptions.
gdb/testsuite/ChangeLog
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/gcore-stale-thread.c: New file.
* gdb.threads/gcore-stale-thread.exp: New file.
Checking whether the gcore command is included in the GDB build as
proxy for checking whether core dumping is supported by the target is
useless, as gcore.o has been in COMMON_OBS since git 9b4eba8e:
2009-10-26 Michael Snyder <msnyder@vmware.com>
Hui Zhu <teawater@gmail.com>
* Makefile.in (SFILES): Add gcore.c.
(COMMON_OBS): Add gcore.o.
* config/alpha/alpha-linux.mh (NATDEPFILES): Delete gcore.o.
* config/alpha/fbsd.mh (NATDEPFILES): Ditto.
...
IOW, the command is always included in the build.
Instead, nowadays, tests bail out if actually trying to generate a
core fails with an indication the target doesn't support it. See
gdb_gcore_cmd and callers.
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
* gdb.base/gcore-buffer-overflow.exp: Remove "help gcore" test.
* gdb.base/gcore-relro-pie.exp: Likewise.
* gdb.base/gcore-relro.exp: Likewise.
* gdb.base/gcore.exp: Likewise.
* gdb.base/print-symbol-loading.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* lib/gdb.exp (gdb_gcore_cmd): Don't expect "Undefined command".
This integrates Jan Kratochvil's nice race reproducer from PR
testsuite/12649 into the testsuite infrustructure directly.
With this, one only has to do either 'make check-read1' or 'make check
READ1="1"' to preload the read1.so library into expect.
Currently only enabled for glibc/GNU systems, and if
build==host==target.
gdb/testsuite/ChangeLog:
* Makefile.in (EXTRA_RULES, CC): New variables, get from
configure.
(EXPECT): Handle READ1 being set.
(all): Depend on EXTRA_RULES.
(check-read1, expect-read1, read1.so, read1): New rules.
* README (Testsuite Parameters): Document the READ1 make variable.
(Race detection): New section.
* configure: Regenerate.
* configure.ac: If build==host==target, and running under a
GNU/glibc system, add read1 to the extra Makefile rules.
(EXTRA_RULES): AC_SUBST it.
* lib/read1.c: New file.
gdb/ChangeLog:
* Makefile.in (check-read1): New rule.
Consider an array described in the debugging information as being
a typedef of an array type for which there is a DW_AT_data_location
attribute. Trying to print the value of that array currently yields
incorrect element values. For instance:
(gdb) print foo.three_tdef
$1 = (6293760, 0, 6293772)
The problem occurs because we check for the data_location attribute
only on the typedef type, whereas we should be checking for the
typedef's target type. As a result, GDB erroneously thinks that
there is no data_location, and therefore starts reading the array's
content from the address of the descriptor instead of the data_location
address.
gdb/ChangeLog:
* value.c (value_from_contents_and_address): Strip resolved_type's
typedef layers before checking its TYPE_DATA_LOCATION.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Add additional tests exercising
the handling of variables declared as a typedef to an array
which a DW_AT_data_location attribute.
This fixes PR symtab/14604, PR symtab/14605, and Jan's test at
https://sourceware.org/ml/gdb-patches/2014-07/msg00158.html, in a tree
with bddbbed reverted:
2014-07-22 Pedro Alves <palves@redhat.com>
* value.c (allocate_optimized_out_value): Don't mark value as
non-lazy.
The PRs are about variables described by the DWARF as being split over
multiple registers using DWARF piece information, but some of those
registers being marked as optimised out (not saved) by a later frame.
GDB currently incorrectly mishandles these partially-optimized-out
values.
Even though we can usually tell from the debug info whether a local or
global is optimized out, handling the case of a local living in a
register that was not saved in a frame requires fetching the variable.
GDB also needs to fetch a value to tell whether parts of it are
"<unavailable>". Given this, it's not worth it to try to avoid
fetching lazy optimized-out values based on debug info alone.
So this patch makes GDB track which chunks of a value's contents are
optimized out like it tracks <unavailable> contents. That is, it
makes value->optimized_out be a bit range vector instead of a boolean,
and removes the struct lval_funcs check_validity and check_any_valid
hooks.
Unlike Andrew's series which this is based on (at
https://sourceware.org/ml/gdb-patches/2013-08/msg00300.html, note some
pieces have gone in since), this doesn't merge optimized out and
unavailable contents validity/availability behind a single interface,
nor does it merge the bit range vectors themselves (at least yet).
While it may be desirable to have a single entry point that returns
existence of contents irrespective of what may make them
invalid/unavailable, several places want to treat optimized out /
unavailable / etc. differently, so each spot that potentially could
use it will need to be careful considered on case-by-case basis, and
best done as a separate change.
This fixes Jan's test, because value_available_contents_eq wasn't
considering optimized out value contents. It does now, and because of
that it's been renamed to value_contents_eq.
A new intro comment is added to value.h describing "<optimized out>",
"<not saved>" and "<unavailable>" values.
gdb/
PR symtab/14604
PR symtab/14605
* ada-lang.c (coerce_unspec_val_to_type): Use
value_contents_copy_raw.
* ada-valprint.c (val_print_packed_array_elements): Adjust.
* c-valprint.c (c_val_print): Use value_bits_any_optimized_out.
* cp-valprint.c (cp_print_value_fields): Let the common printing
code handle optimized out values.
(cp_print_value_fields_rtti): Use value_bits_any_optimized_out.
* d-valprint.c (dynamic_array_type): Use
value_bits_any_optimized_out.
* dwarf2loc.c (entry_data_value_funcs): Remove check_validity and
check_any_valid fields.
(check_pieced_value_bits): Delete and inline ...
(check_pieced_synthetic_pointer): ... here.
(check_pieced_value_validity): Delete.
(check_pieced_value_invalid): Delete.
(pieced_value_funcs): Remove check_validity and check_any_valid
fields.
(read_pieced_value): Use mark_value_bits_optimized_out.
(write_pieced_value): Switch to use
mark_value_bytes_optimized_out.
(dwarf2_evaluate_loc_desc_full): Copy the value contents instead
of assuming the whole value is optimized out.
* findvar.c (read_frame_register_value): Remove special handling
of optimized out registers.
(value_from_register): Use mark_value_bytes_optimized_out.
* frame-unwind.c (frame_unwind_got_optimized): Use
mark_value_bytes_optimized_out.
* jv-valprint.c (java_value_print): Adjust.
(java_print_value_fields): Let the common printing code handle
optimized out values.
* mips-tdep.c (mips_print_register): Remove special handling of
optimized out registers.
* opencl-lang.c (lval_func_check_validity): Delete.
(lval_func_check_any_valid): Delete.
(opencl_value_funcs): Remove check_validity and check_any_valid
fields.
* p-valprint.c (pascal_object_print_value_fields): Let the common
printing code handle optimized out values.
* stack.c (read_frame_arg): Remove special handling of optimized
out values. Fetch both VAL and ENTRYVAL before comparing
contents. Adjust to value_available_contents_eq rename.
* valprint.c (valprint_check_validity)
(val_print_scalar_formatted): Use value_bits_any_optimized_out.
(val_print_array_elements): Adjust.
* value.c (struct value) <optimized_out>: Now a VEC(range_s).
(value_bits_any_optimized_out): New function.
(value_entirely_covered_by_range_vector): New function, factored
out from value_entirely_unavailable.
(value_entirely_unavailable): Reimplement.
(value_entirely_optimized_out): New function.
(insert_into_bit_range_vector): New function, factored out from
mark_value_bits_unavailable.
(mark_value_bits_unavailable): Reimplement.
(struct ranges_and_idx): New struct.
(find_first_range_overlap_and_match): New function, factored out
from value_available_contents_bits_eq.
(value_available_contents_bits_eq): Rename to ...
(value_contents_bits_eq): ... this. Check both unavailable
contents and optimized out contents.
(value_available_contents_eq): Rename to ...
(value_contents_eq): ... this.
(allocate_value_lazy): Remove reference to the old optimized_out
boolean.
(allocate_optimized_out_value): Use
mark_value_bytes_optimized_out.
(require_not_optimized_out): Adjust to check whether the
optimized_out vec is empty.
(ranges_copy_adjusted): New function, factored out from
value_contents_copy_raw.
(value_contents_copy_raw): Also copy the optimized out ranges.
Assert the destination ranges aren't optimized out.
(value_contents_copy): Update comment, remove call to
require_not_optimized_out.
(value_contents_equal): Adjust to check whether the optimized_out
vec is empty.
(set_value_optimized_out, value_optimized_out_const): Delete.
(mark_value_bytes_optimized_out, mark_value_bits_optimized_out):
New functions.
(value_entirely_optimized_out, value_bits_valid): Delete.
(value_copy): Take a VEC copy of the 'optimized_out' field.
(value_primitive_field): Remove special handling of optimized out.
(value_fetch_lazy): Assert that lazy values have no unavailable
regions. Use value_bits_any_optimized_out. Remove some special
handling for optimized out values.
* value.h: Add intro comment about <optimized out> and
<unavailable>.
(struct lval_funcs): Remove check_validity and check_any_valid
fields.
(set_value_optimized_out, value_optimized_out_const): Remove.
(mark_value_bytes_optimized_out, mark_value_bits_optimized_out):
New declarations.
(value_bits_any_optimized_out): New declaration.
(value_bits_valid): Delete declaration.
(value_available_contents_eq): Rename to ...
(value_contents_eq): ... this, and extend comments.
gdb/testsuite/
PR symtab/14604
PR symtab/14605
* gdb.dwarf2/dw2-op-out-param.exp: Remove kfail branches and use
gdb_test.
This comment is no longer true for watchpoints since commit 31e77af2
(PR breakpoints/7143 - Watchpoint does not trigger when first set).
gdb/testsuite/
* gdb.base/watchpoint-hw-hit-once.c (main): Update comment.
In gdb.base/watchpoint-hw-hit-once.exp, test scans source and set
breakpoint on the line having "break-at-exit",
gdb_breakpoint [gdb_get_line_number "break-at-exit"]
However, in watchpoint-hw-hit-once.c, there are two lines having
this key word:
dummy = 1; /* Stub to catch break-at-exit after WATCHEE has been hit. */
dummy = 2; /* break-at-exit */
so the test sets breakpoint on the first one, while I think it is
expected to set breakpoint on the second one, as far as I can tell
from the comments in watchpoint-hw-hit-once.c:
/* Stub lines are present as no breakpoints/watchpoint gets hit if current PC
already stays on the line PC while entering "step"/"continue". */
This patch is to change the source matching pattern so that test
can correctly set breakpoint on the right line. This patch fixes
a fail we found on arm-none-eabi target.
(gdb) PASS: gdb.base/watchpoint-hw-hit-once.exp: continue
continue^M
Continuing.^M
^M
*** EXIT code 0^M
[Inferior 1 (Remote target) exited normally]^M
(gdb) FAIL: gdb.base/watchpoint-hw-hit-once.exp: continue to break-at-exit (the program exited)
Run it again on x86_64-linux, no result changes.
gdb/testsuite:
2014-08-19 Yao Qi <yao@codesourcery.com>
* gdb.base/watchpoint-hw-hit-once.exp: Set breakpoint on the
right line.
The testcase generates an assembly file where a second DW_AT_upper_bound
attribute gets generated in the array range. This was definitely
unintentional, and I only noticed this after pushing the testcase,
when dumping one more time the DWARF data using readelf.
This patch fixes it.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Remove second DW_AT_upper bound
attribute in array range.
This testcase allows us to test the proper processing of both
DW_AT_data_location and DW_OP_push_object_address using a hand-crafted
testcase duplicating how we expect the Ada compiler to represent
unbounded arrays.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
This is a fix for PR c++/17132.
If this new argument is set to EVAL_AVOID_SIDE_EFFECTS, then the object's
memory will not be read while picking the best overload match.
gdb/
* eval.c: Update all calls to find_overload_match.
* valarith.c: Likewise.
(value_user_defined_cpp_op, value_user_defined_op): New
argument NOSIDE. Update all callers.
* valops.c (find_overload_match): New argument NOSIDE.
* value.h (find_overload_match): Update signature.
gdb/testsuite
* gdb.cp/pr17132.cc: New file.
* gdb.cp/pr17132.exp: New file.
gdb/
* python/lib/gdb/command/xmethods.py (set_xm_status1): Use the
'items' methods instead of 'iteritems' method on dictionaries.
gdb/testsuite/
* gdb.python/py-xmethods.py (A_getarrayind)
(E_method_char_worker.__call__, E_method_int_worker.__call__):
Use 'print' with function call syntax.
(E_method_matcher.match): Fix tab vs space indentation mixup.
I added proc generate_tracefile in this patch
https://sourceware.org/ml/gdb-patches/2014-03/msg00591.html but
tfile.exp isn't skipped as changelog entry said:
* gdb.trace/tfile.exp: Skip the test if generate_tracefile
return 0.
it is a mistake I made at the last minute. Patch below fixed it.
gdb/testsuite:
2014-08-15 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Return -1 if generate_tracefile returns
false.
GDB in default prints the symbol associated on an address, and tests
assume that there is no symbol on address zero. However, on bare
metal target, address may be mapped to zero and there may be a
symbol. Then, some tests fail as below:
print const_cast<void *> (0)^M
$8 = (void *) 0x0 <_ftext>^M
(gdb) FAIL: gdb.cp/casts.exp: const_cast of 0
p acp->c1^M
$9 = (A *) 0x0 <_ftext>^M
(gdb) FAIL: gdb.cp/class2.exp: p acp->c1
This patch is to set print symbol off in these tests, like what
I did previously https://sourceware.org/ml/gdb-patches/2014-07/msg00257.html
gdb/testsuite:
2014-08-15 Yao Qi <yao@codesourcery.com>
* gdb.cp/casts.exp: Set print symbol off.
* gdb.cp/class2.exp: Likewise.
* gdb.cp/overload.exp: Likewise.
* gdb.cp/templates.exp: Likewise.
* solib.c (solib_read_symbols): Delete "Loaded symbols for ..."
message, it is redundant with "Reading symbols from ..." message.
testsuite/
* gdb.base/print-symbol-loading.exp (test_load_core): Update.
(test_load_shlib): Update.
I find some gdb.python tests fail on arm-none-eabi target, because the
tests assume that memory on address 0x is inaccessible. Some tests
(in gdb.base) are aware of this, so do a "x 0" check first. However,
the code is copy-n-paste.
This patch is to move the "x 0" check to a procedure in lib/gdb.exp,
and get needed tests call it. The original code matches pattern
"0x0:\[ \t\]*Error accessing memory address 0x0\r\n$gdb_prompt $", but
I remove it from the new proc is_address_zero_readable, because GDB
doesn't emit such message any more.
gdb/testsuite:
2014-08-09 Yao Qi <yao@codesourcery.com>
* gdb.base/display.exp: Invoke is_address_zero_readable.
* gdb.guile/scm-value.exp (test_value_in_inferior): Likewise.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* gdb.base/hbreak-unmapped.exp: Return if
is_address_zero_readable returns true.
* gdb.base/signest.exp: Likewise.
* gdb.base/signull.exp: Likewise.
* gdb.base/sigbpt.exp: Likewise.
* gdb.guile/scm-disasm.exp: Do the test if
is_address_zero_readable returns false.
* gdb.guile/scm-pretty-print.exp (run_lang_tests): Likewise.
* gdb.python/py-arch.exp: Likewise.
* gdb.python/py-prettyprint.exp (run_lang_tests): Likewise.
* lib/gdb.exp (is_address_zero_readable): New proc.
When I fix a bug in gdb.mi/mi-var-display.exp, I find its test
messages aren't unique, which makes some confusions for me.
$ cat testsuite/gdb.sum | grep "PASS" | sort | uniq -c | sort -n
...
2 PASS: gdb.mi/mi-var-display.exp: set format variable bar
2 PASS: gdb.mi/mi-var-display.exp: set format variable foo
2 PASS: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr
2 PASS: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr
2 PASS: gdb.mi/mi-var-display.exp: show format variable foo
3 PASS: gdb.mi/mi-var-display.exp: eval variable foo
This patch is to make test messages in mi-var-display.exp unique.
gdb/testsuite:
2014-08-09 Yao Qi <yao@codesourcery.com>
PR testsuite/13443
* gdb.mi/mi-var-display.exp: Make test messages unique.
Right now, "set debug target" acts a bit strangely.
Most target APIs only notice that it has changed when the target stack
is changed in some way. This is because many methods implement the
setting using the special debug target. However, a few spots do
change their behavior immediately -- any place explicitly checking
"targetdebug".
Some of this peculiar behavior is documented. However, I think that
it just isn't very useful for it to work this way. So, this patch
changes "set debug target" to take effect immediately in all cases.
This is done by simply calling update_current_target when the setting
is changed.
This required one small change in the test suite. Here a test was
expecting the current behavior.
Built and regtested on x86-64 Fedora 20.
2014-08-04 Tom Tromey <tromey@redhat.com>
* target.c (set_targetdebug): New function.
(initialize_targets): Pass set_targetdebug when creating "set
debug target".
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Debugging Output): Update for change to "set debug
target".
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Expect output from "set debug
target 0".
This fixes a test suite regession that Yao noticed.
This test checks for some specific "target debug" output
that has changed since the test was written.
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Match "to_resume", not
"target_resume".
In Ada, variable-sized field can be located at any position of
a structure. Consider for instance the following declarations:
Dyn_Size : Integer := 1;
type Table is array (Positive range <>) of Integer;
type Inner is record
T1 : Table (1 .. Dyn_Size) := (others => 1);
T2 : Table (1 .. Dyn_Size) := (others => 2);
end record;
type Inner_Array is array (1 .. 2) of Inner;
type Outer is
record
I0 : Integer := 0;
A1 : Inner_Array;
Marker : Integer := 16#01020304#;
end record;
Rt : Outer;
What this does is declare a variable "Rt" of type Outer, which
contains 3 fields where the second (A1) is of type Inner_Array.
type Inner_Array is an array with 2 elements of type Inner.
Because type Inner contains two arrays whose upper bound depend
on a variable, the size of the array, and therefore the size of
type Inner is dynamic, thus making field A1 a dynamically-size
field.
When trying to print the value of Rt, we hit the following limitation:
(gdb) print rt
Attempt to resolve a variably-sized type which appears in the interior of
a structure type
The limitation was somewhat making sense in C, but needs to be lifted
for Ada. This patch mostly lifts that limitation. As a result of this
patch, the type length computation had to be reworked a little bit.
gdb/ChangeLog:
* gdbtypes.c (resolve_dynamic_struct): Do not generate an error
if detecting a variable-sized field that is not the last field.
Fix struct type length computation.
gdb/testsuite/ChangeLog:
* gdb.base/vla-datatypes.c (vla_factory): Add new variable
inner_vla_struct_object_size.
* gdb.base/vla-datatypes.exp: Adjust last test, and mark it
as xfail.
As reported in PR 17206, an internal error is triggered when command
until is executed. In infcmd.c:until_next_command, step_range_end is
set to 'pc',
if (!func)
{
struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc);
if (msymbol.minsym == NULL)
error (_("Execution is not within a known function."));
tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol);
tp->control.step_range_end = pc;
}
and later in infrun.c:resume, the assert below is triggered in PR
17206.
if (tp->control.may_range_step)
{
/* If we're resuming a thread with the PC out of the step
range, then we're doing some nested/finer run control
operation, like stepping the thread out of the dynamic
linker or the displaced stepping scratch pad. We
shouldn't have allowed a range step then. */
gdb_assert (pc_in_thread_step_range (pc, tp));
}
In until_next_command, we set step range to [XXX, pc), so pc isn't
within the range. pc_in_thread_step_range returns false and the
assert is triggered. AFAICS, the range we want in until_next_command
is [XXX, pc] instead of [XXX, pc), because we want to program step
until greater than pc. This patch is to set step_range_end to
'pc + 1'. Running until-nodebug.exp with unpatched GDB will get the
following fail,
FAIL: gdb.base/until-nodebug.exp: until 2 (GDB internal error)
and the fail goes away when the fix is applied.
gdb:
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* infcmd.c (until_next_command): Set step_range_end to PC + 1.
gdb/testsuite:
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* gdb.base/until-nodebug.exp: New.
* guile/scm-param.c (pascm_parameter_defined_p): New function.
(gdbscm_register_parameter_x): Call it. Raise error for pre-existing
parameters.
testsuite/
* gdb.guile/scm-parameter.exp: Add tests for trying to create
previously existing parameter, and previously ambiguously spelled
parameter.
These tests used to fail on ARM but now pass, so remove the KFAIL.
gdb/testsuite/ChangeLog:
2014-07-28 Will Newton <will.newton@linaro.org>
* gdb.base/varargs.exp: Remove KFAILs for ARM.
* data-directory/Makefile.in (GUILE_FILES): Add support.scm.
* guile/lib/gdb/support.scm: New file.
* guile/guile.c (gdbscm_init_module_name): Change to "gdb".
* guile/lib/gdb.scm: Load gdb/init.scm as an include file.
All uses updated.
* guile/lib/gdb/init.scm (SCM_ARG1, SCM_ARG2): Moved to support.scm.
All uses updated.
(%assert-type): Ditto, and renamed to assert-type.
(%exception-print-style): Delete.
testsuite/
* gdb.guile/types-module.exp: Add tests for wrong type arguments.
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.
E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1. This obviously messes up programs that use
pthread_kill to send signals to specific threads.
This has been a known issue for a long while. Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.
The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.
Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint... If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).
"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for. These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do. GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test). At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.
Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:
(gdb) continue
Thread 1 stopped for signal SIGFOO.
(gdb) thread 2
(gdb) signal SIGBAR
... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).
So the patch makes GDB detect that, and ask for confirmation:
(gdb) thread 1
[Switching to thread 1 (Thread 10979)]
(gdb) signal SIGUSR2
Note:
Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
Continuing thread 1 (the current thread) with specified signal will
still deliver the signals noted above to their respective threads.
Continue anyway? (y or n)
All these scenarios are covered by the new tests.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* NEWS: Mention signal passing and "signal" command changes.
* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
comment.
* breakpoint.c (until_break_command): Adjust clear_proceed_status
call.
* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
* infcmd.c (proceed_thread_callback, continue_1, step_once)
(jump_command): Adjust clear_proceed_status call.
(signal_command): Warn if other thread that are resumed have
signals that will be delivered. Adjust clear_proceed_status call.
(until_next_command, finish_command)
(proceed_after_attach_callback, attach_command_post_wait)
(attach_command): Adjust clear_proceed_status call.
* infrun.c (proceed_after_vfork_done): Likewise.
(proceed_after_attach_callback): Adjust comment.
(clear_proceed_status_thread): Clear stop_signal if not in pass
state.
(clear_proceed_status_callback): Delete.
(clear_proceed_status): New 'step' parameter. Only clear the
proceed status of threads the command being prepared is about to
resume.
(proceed): If passed in an explicit signal, override stop_signal
with it. Don't pass the last stop signal to the thread we're
resuming.
(init_wait_for_inferior): Adjust clear_proceed_status call.
(switch_back_to_stepped_thread): Clear the signal if it should not
be passed.
* infrun.h (clear_proceed_status): New 'step' parameter.
(user_visible_resume_ptid): Add comment.
* linux-nat.c (linux_nat_resume_callback): Don't check whether the
signal is in pass state.
* remote.c (append_pending_thread_resumptions): Likewise.
* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
gdb/doc/
2014-07-25 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Signaling) <signal command>: Explain what happens
with multi-threaded programs.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
Jan pointed out in
<https://sourceware.org/ml/gdb-patches/2014-07/msg00553.html> that
these testcases have racy results:
gdb.base/double-prompt-target-event-error.exp
gdb.base/paginate-after-ctrl-c-running.exp
gdb.base/paginate-bg-execution.exp
gdb.base/paginate-execution-startup.exp
gdb.base/paginate-inferior-exit.exp
This is easily reproducible with "read1" from:
[reproducer for races of expect incomplete reads]
http://sourceware.org/bugzilla/show_bug.cgi?id=12649
The '-notransfer -re "<return>" { exp_continue }' trick in the current
tests doesn't actually work.
The issue that led to the -notransfer trick was that
"---Type <return> to continue, or q <return> to quit---"
has two "<return>"s. If one wants gdb_test_multiple to not hit the
built-in "<return>" match that results in FAIL, one has to expect the
pagination prompt in chunks, first up to the first "<return>", then
again, up to the second. Something around these lines:
gdb_test_multiple "" $test {
-re "<return>" {
exp_continue
}
-re "to quit ---" {
pass $test
}
}
The intent was for -notransfer+exp_continue to make expect fetch more
input, and rerun the matches against the now potentially fuller
buffer, and then eventually the -re that includes the full pagination
prompt regex would match instead (because it's listed higher up, it
would match first). But, once that "<return>" -notransfer -re
matches, it keeps re-matching forever. It seems like with
exp_continue, expect immediately retries matching, instead of first
reading in more data into the buffer, if available.
Fix this like I should have done in the first place. There's actually
no good reason for gdb_test_multiple to only match "<return>". We can
make gdb_test_multiple expect the whole pagination prompt text
instead, which is store in the 'pagination_prompt' global (similar to
'gdb_prompt'). Then a gdb_test_multiple caller that doesn't want the
default match to trigger, because it wants to see one pagination
prompt, does simply:
gdb_test_multiple "" $test {
-re "$pagination_prompt$" {
pass $test
}
}
which is just like when we don't want the default $gdb_prompt match
within gdb_test_multiple to trigger, like:
gdb_test_multiple "" $test {
-re "$gdb_prompt $" {
pass $test
}
}
Tested on x86_64 Fedora 20. In addition, I've let the racy tests run
all in parallel in a loop for 30 minutes, and they never failed.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.base/double-prompt-target-event-error.exp
(cancel_pagination_in_target_event): Remove '-notransfer <return>'
match.
(cancel_pagination_in_target_event): Rework double prompt
detection.
* gdb.base/paginate-after-ctrl-c-running.exp
(test_ctrlc_while_target_running_paginates): Remove '-notransfer
<return>' match.
* gdb.base/paginate-bg-execution.exp
(test_bg_execution_pagination_return)
(test_bg_execution_pagination_cancel): Remove '-notransfer
<return>' matches.
* gdb.base/paginate-execution-startup.exp
(test_fg_execution_pagination_return)
(test_fg_execution_pagination_cancel): Remove '-notransfer
<return>' matches.
* gdb.base/paginate-inferior-exit.exp
(test_paginate_inferior_exited): Remove '-notransfer <return>'
match.
* lib/gdb-utils.exp (string_to_regexp): Move here from lib/gdb.exp.
* lib/gdb.exp (pagination_prompt): Run text through
string_to_regexp.
(gdb_test_multiple): Match $pagination_prompt instead of
"<return>".
(string_to_regexp): Move to lib/gdb-utils.exp.
I noticed that the existing code casts a function's address to 'long',
but that doesn't work correctly on some ABIs, like Win64, where long
is 32-bit and while pointers are 64-bit:
func_addr = (long) &write_basic_trace_file;
Fixing that showed there's actually another place in the file that
writes a function address to file, and therefore should clear the
Thumb bit. This commit adds a macro+function pair to centralize the
Thumb bit handling, and uses it in both places.
The rest is just enough changes to make the file build without
warnings with "-Wall -Wextra" with x86_64-w64-mingw32-gcc and
i686-w64-mingw32-gcc cross compilers, and with -m32/-m64 on x86_64
GNU/Linux. Currently with x86_64-w64-mingw32-gcc we get:
$ x86_64-w64-mingw32-gcc tfile.c -Wall -DTFILE_DIR=\"\"
tfile.c: In function 'start_trace_file':
tfile.c:51:23: error: 'S_IRGRP' undeclared (first use in this function)
S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
^
tfile.c:51:23: note: each undeclared identifier is reported only once for each function it appears in
tfile.c:51:31: error: 'S_IROTH' undeclared (first use in this function)
S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
^
tfile.c: In function 'add_memory_block':
tfile.c:79:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
ll_x = (unsigned long) addr;
^
tfile.c: In function 'write_basic_trace_file':
tfile.c:113:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
func_addr = (long) &write_basic_trace_file;
^
tfile.c:137:3: warning: passing argument 1 of 'add_memory_block' from incompatible pointer type [enabled by default]
add_memory_block (&testglob, sizeof (testglob));
^
tfile.c:72:1: note: expected 'char *' but argument is of type 'int *'
add_memory_block (char *addr, int size)
^
tfile.c:139:3: warning: passing argument 1 of 'add_memory_block' from incompatible pointer type [enabled by default]
add_memory_block (&testglob2, 1);
^
tfile.c:72:1: note: expected 'char *' but argument is of type 'int *'
add_memory_block (char *addr, int size)
^
tfile.c: In function 'write_error_trace_file':
tfile.c:185:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
char *hex = alloca (len * 2 + 1);
^
tfile.c:185:15: warning: incompatible implicit declaration of built-in function 'alloca' [enabled by default]
char *hex = alloca (len * 2 + 1);
^
tfile.c:211:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(long) &write_basic_trace_file);
^
Tested on x86_64 Fedora 20, -m64 and -m32.
Tested by Yao on arm targets.
gdb/testsuite/
2014-07-16 Pedro Alves <palves@redhat.com>
* gdb.trace/tfile.c: Include unistd.h and stdint.h.
(start_trace_file): Guard S_IRGRP and S_IROTH uses behind #ifdef.
(tfile_write_64, tfile_write_16, tfile_write_8, tfile_write_addr)
(tfile_write_buf): New functions.
(add_memory_block): Rewrite using the above.
(adjust_function_address): New function.
(FUNCTION_ADDRESS): New macro.
(write_basic_trace_file): Remove short_x local, and use
tfile_write_16. Change type of func_addr local to unsigned long
long. Use FUNCTION_ADDRESS instead of handling the Thumb bit
here. Cast argument of add_memory_block to char pointer.
(write_error_trace_file): Avoid alloca. Use FUNCTION_ADDRESS.
(main): Remove parameters.
* gdb.trace/tfile.exp: Remove nowarnings.
As Joel pointed out in...
https://sourceware.org/ml/gdb-patches/2014-07/msg00391.html
...it would be nice to add a test for that.
Tested on Linux x86_64 (Ubuntu 14.10).
gdb/testsuite/ChangeLog
2014-07-15 Simon Marchi <simon.marchi@ericsson.com>
* gdb.base/debug-expr.exp: Test string evaluation with
"debug expression" on.
The other day I noticed that default_gdb_start reuses the GDB process
if it has been spawned already:
proc default_gdb_start { } {
...
if [info exists gdb_spawn_id] {
return 0
}
I was a bit surprised, and so I hacked in an error to check whether
anything is relying on it:
+ if [info exists gdb_spawn_id] {
+ error "GDB already spawned"
+ }
And lo, that tripped on a funny buglet (see below). The comment in
reread.exp says "Restart GDB entirely", but in reality, due to the
above, that's not what is happening, as a gdb_exit call is missing.
The test is proceeding with the previous GDB process...
I don't really want to go hunt for whether there's an odd setup out
there that assumes this in its board file or something, so for now,
I'm taking the simple route of just making the test do what it says it
does. I think this much makes it an obvious fix.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(gdb) PASS: gdb.base/reread.exp: run to foo() second time
ERROR: tcl error sourcing ../src/gdb/testsuite/gdb.base/reread.exp.
ERROR: GDB already spawned
while executing
"error "GDB already spawned""
invoked from within
"if [info exists gdb_spawn_id] {
error "GDB already spawned"
}"
(procedure "default_gdb_start" line 22)
invoked from within
"default_gdb_start"
(procedure "gdb_start" line 2)
invoked from within
"gdb_start"
invoked from within
"if [is_remote target] {
unsupported "second pass: GDB should check for changes before running"
} else {
# Put the older executable back in pl..."
(file "../src/gdb/testsuite/gdb.base/reread.exp" line 114)
invoked from within
"source ../src/gdb/testsuite/gdb.base/reread.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source ../src/gdb/testsuite/gdb.base/reread.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
testcase ../src/gdb/testsuite/gdb.base/reread.exp completed in 1 seconds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gdb/testsuite/
2014-07-15 Pedro Alves <palves@redhat.com>
* gdb.base/reread.exp: Use clean_restart.
The __flash qualifier is part of the named address spaces for AVR [1]. It
allows putting read-only data in the flash memory, normally reserved for
code.
When used together with a pointer, the DW_AT_address_class attribute is set
to 1 and allows GDB to detect that when it will be dereferenced, the data
will be loaded from the flash memory (with the LPM instruction).
We can now properly debug the following code:
~~~
const __flash char data_in_flash = 0xab;
int
main (void)
{
const __flash char *pointer_to_flash = &data_in_flash;
}
~~~
~~~
(gdb) print pointer_to_flash
$1 = 0x1e8 <data_in_flash> "\253"
(gdb) print/x *pointer_to_flash
$2 = 0xab
(gdb) x/x pointer_to_flash
0x1e8 <data_in_flash>: 0xXXXXXXab
~~~
Whereas previously, GDB would revert to the default address space which is
RAM and mapped in higher memory:
~~~
(gdb) print pointer_to_flash
$1 = 0x8001e8 ""
~~~
[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
2014-07-15 Pierre Langlois <pierre.langlois@embecosm.com>
gdb/
* avr-tdep.c (AVR_TYPE_ADDRESS_CLASS_FLASH): New macro.
(AVR_TYPE_INSTANCE_FLAG_ADDRESS_CLASS_FLASH): Likewise.
(avr_address_to_pointer): Check for AVR_TYPE_ADDRESS_CLASS_FLASH.
(avr_pointer_to_address): Likewise.
(avr_address_class_type_flags): New function.
(avr_address_class_type_flags_to_name): Likewise.
(avr_address_class_name_to_type_flags): Likewise.
(avr_gdbarch_init): Set address_class_type_flags,
address_class_type_flags_to_name and
address_class_name_to_type_flags.
gdb/testsuite/
* gdb.arch/avr-flash-qualifer.c: New.
* gdb.arch/avr-flash-qualifer.exp: New.
Put GDB's terminal settings into effect when paginating
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
* utils.c (prompt_for_continue): Call target_terminal_ours.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/paginate-after-ctrl-c-running.c: New file.
* gdb.base/paginate-after-ctrl-c-running.exp: New file.
When the target is resumed in the foreground, we put the inferior's
terminal settings into effect, and remove stdin from the event loop.
When the target stops, we put GDB's terminal settings into effect
again, and re-register stdin in the event loop, ready for user input.
The former is done by target_terminal_inferior, and the latter by
target_terminal_ours.
There's an intermediate -- target_terminal_ours_for_output -- that is
called when printing output related to target events, and we don't
know yet whether we'll stop the program. That puts our terminal
settings into effect, enough to get proper results from our output,
but leaves input wired into the inferior.
If such output paginates, then we need the full target_terminal_ours
in order for the user to be able to provide input to answer the
pagination query.
The test in this commit hangs in async-capable targets without the fix
(as the user/test can't answer the pagination query). It doesn't hang
on sync targets because on those we don't unregister stdin from the
event loop while the target is running (because we block in
target_wait instead of in the event loop in that case).
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
* utils.c (prompt_for_continue): Call target_terminal_ours.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/paginate-after-ctrl-c-running.c: New file.
* gdb.base/paginate-after-ctrl-c-running.exp: New file.
If an error is thrown while handling a target event (within
fetch_inferior_event), and, the interpreter is not async (but the
target is), then GDB prints the prompt twice.
One way to see that in action is throw a QUIT while in a pagination
prompt issued from within fetch_inferior_event (or one of its
callees). E.g. from the test:
---Type <return> to continue, or q <return> to quit---
^CQuit
(gdb) (gdb) p 1
^^^^^^^^^^^
$1 = 1
(gdb)
The issue is that inferior_event_handler swallows errors and notifies
the observers (the interpreters) about the command error, even if the
interpreter is forced sync while we're handling a nested event loop
(for execute_command). The observers print a prompt, and then when we
get back to the top event loop, we print another (in
start_event_loop).
I see no reason the error should be swallowed here. Just cancel the
execution related bits and let the error propagate to the top level
(start_event_loop), which re-enables stdin and notifies observers.
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
* inf-loop.c (inferior_event_handler): Use TRY_CATCH instead of
catch_errors. Don't re-enable stdin or notify observers where,
and rethrow error.
(fetch_inferior_event_wrapper): Delete.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/double-prompt-target-event-error.c: New file.
* gdb.base/double-prompt-target-event-error.exp: New file.
If a pagination prompt triggers while the target is running, and the
target exits before the user responded to the pagination query, this
happens:
Starting program: foo
---Type <return> to continue, or q <return> to quit---No unwaited-for children left.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb)
To reiterate, the user hasn't replied to the pagination prompt above.
A pagination query nests an event loop (in gdb_readline_wrapper). In
async mode, in addition to stdin and signal handlers, we'll have the
target also installed in the event loop still. So if the target
reports an event, that wakes up the nested event loop, which calls
into fetch_inferior_event etc. to handle the event which generates
further output, all while we should be waiting for pagination
confirmation...
(TBC, any target event that generates output ends up spuriously waking
up the pagination, though exits seem to be the worse kind.)
I've played with a couple different approaches to fixing this, while
at the same time trying to avoid being invasive. Both revolve around
not listening to target events while in a pagination prompt (doing
anything else I think would be a much bigger change).
The approach taken just removes the target from the event loop while
within gdb_readline_wrapper. The other approach used gdb_select
directly, with only input_fd installed, but that had the issue that it
didn't handle the async signal handlers, and turned out to be a bit
more code than the first version.
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c: Include "inf-loop.h".
(struct gdb_readline_wrapper_cleanup) <target_is_async_orig>: New
field.
(gdb_readline_wrapper_cleanup): Make the target async again, if it
was async before.
(gdb_readline_wrapper): Store whether the target is async, and
make it sync.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* gdb.base/paginate-inferior-exit.c: New file.
* gdb.base/paginate-inferior-exit.exp: New file.
If pagination occurs as result of output sent as response to a target
event while the target is executing in the background, subsequent
input aborts readline/gdb:
$ gdb program
...
(gdb) continue&
Continuing.
(gdb)
---Type <return> to continue, or q <return> to quit---
*return*
---Type <return> to continue, or q <return> to quit---
Breakpoint 2, after_sleep () at paginate-bg-execution.c:21
---Type <return> to continue, or q <return> to quit---
21 return; /* after sleep */
p 1
readline: readline_callback_read_char() called with no handler!
*abort/SIGABRT*
$
gdb_readline_wrapper_line removes the handler after a line is
processed. Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler. But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler. So the next input wakes up the event loop and calls into
readline, which aborts.
We should do better with the prompt handling while the target is
running (I think we should coordinate with readline, and
hide/redisplay it around output), but that's a more invasive change
better done post 7.8, so this patch is conservative and just
reinstalls the handler as soon as we're out of the readline line
callback.
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* top.c (gdb_readline_wrapper_line): Tweak comment.
(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
the input handler callback.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* gdb.base/paginate-bg-execution.c: New file.
* gdb.base/paginate-bg-execution.exp: New file.
This fixes:
$ ./gdb program -ex "set height 2" -ex "start"
...
Reading symbols from /home/pedro/gdb/tests/threads...done.
---Type <return> to continue, or q <return> to quit---^CQuit << ctrl-c triggers a Quit
*type something*
readline: readline_callback_read_char() called with no handler!
Aborted
$
Usually, if an error propagates all the way to the top level, we'll
re-enable stdin, in case the command that was running was a
synchronous command. That's done in the event loop's actual loop
(event-loop.c:start_event_loop). However, if a foreground execution
command is run before the event loop starts and throws, nothing is
presently reenabling stdin, which leaves sync_execution set.
When we do start the event loop, because sync_execution is still
(mistakenly) set, display_gdb_prompt removes the readline input
callback, even though stdin is registered in the event loop. Any
input from here on results in readline aborting.
Such commands are run through catch_command_errors,
catch_command_errors_const, so add the tweak there.
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* main.c: Include event-top.h.
(handle_command_errors): New function.
(catch_command_errors, catch_command_errors_const): Use it.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* gdb.base/paginate-execution-startup.c: New file.
* gdb.base/paginate-execution-startup.exp: New file.
* lib/gdb.exp (pagination_prompt): New global.
(default_gdb_spawn): New procedure, factored out from
default_gdb_spawn.
(default_gdb_start): Adjust to call default_gdb_spawn.
(gdb_spawn): New procedure.
Often we'll do something like:
if {$ok} {
fail "whatever"
} else {
pass "whatever"
}
This adds a helper procedure for that, and converts one random place
to use it, as an example.
2014-07-14 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_assert): New procedure.
* gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Use it.
The "call" and "print" commands presently always run synchronously, in
the foreground, but GDB currently forgets to put the inferior's
terminal settings into effect while running them, on async-capable
targets, resulting in:
(gdb) print func ()
hello world
Program received signal SIGTTOU, Stopped (tty output).
0x000000373bceb8d0 in __libc_tcdrain (fd=1) at ../sysdeps/unix/sysv/linux/tcdrain.c:29
29 return INLINE_SYSCALL (ioctl, 3, fd, TCSBRK, 1);
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(func) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb)
That's because target_terminal_inferior skips actually doing anything
if running in the background, and, nothing is setting sync_execution
while running infcalls:
void
target_terminal_inferior (void)
{
/* A background resume (``run&'') should leave GDB in control of the
terminal. Use target_can_async_p, not target_is_async_p, since at
this point the target is not async yet. However, if sync_execution
is not set, we know it will become async prior to resume. */
if (target_can_async_p () && !sync_execution)
return;
This would best be all cleaned up by making GDB not even call
target_terminal_inferior and try to pass the terminal to the inferior
if running in the background, but that's a more invasive fix that is
better done post-7.8.
This was originally caught by a patch later in this series that makes
catch_command_errors use exception_print instead of
print_any_exception. Note that print_flush calls serial_drain_output
while print_any_exception doesnt't have that bit. And,
gdb.gdb/python-selftest.exp does:
gdb_test "call catch_command_errors(execute_command, \"python print 5\", 0, RETURN_MASK_ALL)" \
"Python not initialized.* = 0"
which without this fix results in SIGTTOU...
gdb/
2014-07-14 Pedro Alves <palves@redhat.com>
* infcall.c (run_inferior_call): Set 'sync_execution' while
running the inferior call.
gdb/testsuite/
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/execution-termios.c: New file.
* gdb.base/execution-termios.exp: New file.
This fixes PR 17106, a regression in printing.
The bug is that resolve_dynamic_type follows struct members and
references, but doesn't consider the possibility of infinite
recursion.
This patch fixes the problem by limiting reference following to the
topmost layer of calls -- that is, reference-typed struct members are
never considered as being VLAs.
Built and regtested on x86-64 Fedora 20.
New test case included.
2014-07-14 Tom Tromey <tromey@redhat.com>
PR exp/17106:
* gdbtypes.c (is_dynamic_type_internal): New function, from
is_dynamic_type.
(is_dynamic_type): Rewrite.
(resolve_dynamic_union): Use resolve_dynamic_type_internal.
(resolve_dynamic_struct): Likewise.
(resolve_dynamic_type_internal): New function, from
resolve_dynamic_type.
(resolve_dynamic_type): Rewrite.
2014-07-14 Tom Tromey <tromey@redhat.com>
* gdb.cp/vla-cxx.cc: New file.
* gdb.cp/vla-cxx.exp: New file.
This fixes the record "run" regression pointed out by Marc Khouzam:
https://sourceware.org/ml/gdb/2014-06/msg00096.html
The bug is that target_require_runnable must agree with the handling
of the "run" target, but currently it is out of sync. This patch
fixes the problem by changing target_require_runnable to also ignore
the record_stratum.
Built and regtested on x86-64 Fedora 20.
New test case included.
2014-07-14 Tom Tromey <tromey@redhat.com>
* target.c (target_require_runnable): Also check record_stratum.
Update comment.
2014-07-14 Tom Tromey <tromey@redhat.com>
* gdb.reverse/rerun-prec.c: New file.
* gdb.reverse/rerun-prec.exp: New file.
Right now we provide a board info entry, `gdb_init_command', that allows
one to send a single command to GDB before the program to be debugged is
started. This is useful e.g. for slow remote targets to change the
default "remotetimeout" setting. Occasionally I found a need to send
multiple commands instead, however this cannot be achieved with
`gdb_init_command'.
This change therefore extends the mechanism by adding a TCL list of GDB
commands to send, via a board info entry called `gdb_init_commands'.
There is no limit as to the number of commands put there. The old
`gdb_init_command' mechanism remains supported for compatibility with
existing people's environments.
* lib/gdb-utils.exp: New file.
* lib/gdb.exp (gdb_run_cmd): Call gdb_init_commands, replacing
inline `gdb_init_command' processing.
(gdb_start_cmd): Likewise.
* lib/mi-support.exp (mi_run_cmd): Likewise.
* README: Document `gdb_init_command' and `gdb_init_commands'.
We see the following fails on arm-none-eabi target,
print (void*)v_signed_char^M
$190 = (void *) 0x0 <_ftext>^M
(gdb) FAIL: gdb.base/exprs.exp: print (void*)v_signed_char (print
(void*)v_signed_char)
GDB behaves correctly but the test assumes there is no symbol on
address 0x0. This patch is set print symbol off, so that tests below
can match the address only.
gdb/testsuite:
2014-07-11 Yao Qi <yao@codesourcery.com>
* gdb.base/exprs.exp: "set print symbol off".
Here's an example, with the new test:
gdbserver :9999 gdb.threads/kill
gdb gdb.threads/kill
(gdb) b 52
Breakpoint 1 at 0x4007f4: file kill.c, line 52.
Continuing.
Breakpoint 1, main () at kill.c:52
52 return 0; /* set break here */
(gdb) k
Kill the program being debugged? (y or n) y
gdbserver :9999 gdb.threads/kill
Process gdb.base/watch_thread_num created; pid = 9719
Listening on port 1234
Remote debugging from host 127.0.0.1
Killing all inferiors
Segmentation fault (core dumped)
Backtrace:
(gdb) bt
#0 0x00000000004068a0 in find_inferior (list=0x66b060 <all_threads>, func=0x427637 <kill_one_lwp_callback>, arg=0x7fffffffd3fc) at src/gdb/gdbserver/inferiors.c:199
#1 0x00000000004277b6 in linux_kill (pid=15708) at src/gdb/gdbserver/linux-low.c:966
#2 0x000000000041354d in kill_inferior (pid=15708) at src/gdb/gdbserver/target.c:163
#3 0x00000000004107e9 in kill_inferior_callback (entry=0x6704f0) at src/gdb/gdbserver/server.c:2934
#4 0x0000000000406522 in for_each_inferior (list=0x66b050 <all_processes>, action=0x4107a6 <kill_inferior_callback>) at src/gdb/gdbserver/inferiors.c:57
#5 0x0000000000412377 in process_serial_event () at src/gdb/gdbserver/server.c:3767
#6 0x000000000041267c in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:3880
#7 0x00000000004189ff in handle_file_event (event_file_desc=4) at src/gdb/gdbserver/event-loop.c:434
#8 0x00000000004181c6 in process_event () at src/gdb/gdbserver/event-loop.c:189
#9 0x0000000000418f45 in start_event_loop () at src/gdb/gdbserver/event-loop.c:552
#10 0x0000000000411272 in main (argc=3, argv=0x7fffffffd8d8) at src/gdb/gdbserver/server.c:3283
The problem is that linux_wait_for_event deletes lwps that have exited
(even those not passed in as lwps of interest), while the lwp/thread
list is being walked on with find_inferior. find_inferior can handle
the current iterated inferior being deleted, but not others.
When killing lwps, we don't really care about any of the pending
status handling of linux_wait_for_event. We can just waitpid the lwps
directly, which is also what GDB does (see
linux-nat.c:kill_wait_callback). This way the lwps are not deleted
while we're walking the list. They'll be deleted by linux_mourn
afterwards.
This crash triggers several times when running the testsuite against
GDBserver with the native-gdbserver board (target remote), but as GDB
can't distinguish between GDBserver crashing and "kill" being
sucessful, as in both cases the connection is closed (the 'k' packet
doesn't require a reply), and the inferior is gone, that results in no
FAIL.
The patch adds a generic test that catches the issue with
extended-remote mode (and works fine with native testing too). Here's
how it fails with the native-extended-gdbserver board without the fix:
(gdb) info threads
Id Target Id Frame
6 Thread 15367.15374 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
5 Thread 15367.15373 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
4 Thread 15367.15372 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
3 Thread 15367.15371 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
2 Thread 15367.15370 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
* 1 Thread 15367.15367 main () at .../gdb.threads/kill.c:52
(gdb) kill
Kill the program being debugged? (y or n) y
Remote connection closed
^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) FAIL: gdb.threads/kill.exp: kill
Extended remote should remain connected after the kill.
gdb/gdbserver/
2014-07-11 Pedro Alves <palves@redhat.com>
* linux-low.c (kill_wait_lwp): New function, based on
kill_one_lwp_callback, but use my_waitpid directly.
(kill_one_lwp_callback, linux_kill): Use it.
gdb/testsuite/
2014-07-11 Pedro Alves <palves@redhat.com>
* gdb.threads/kill.c: New file.
* gdb.threads/kill.exp: New file.
We see the fail below happens on thumb related multi-libs
(-mthumb -march={armv4t,armv7-a}),
target tfile tfile-basic.tf ^M
warning: Uploaded tracepoint 1 has no source location, using raw address^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
Tracepoint 3 at 0x8958: file /scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.trace/tfile.c, line 91.^M
Created tracepoint 3 for target's tracepoint 1 at 0x8959.^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
(gdb) FAIL: gdb.trace/tfile.exp: complete-command 'target tfile'
The address of write_basic_trace_file is two-bytes aligned,
(gdb) p write_basic_trace_file
$1 = {void (void)} 0x8958 <write_basic_trace_file>
but the ld sets the LSB of every reference to the function address
(indicating the address is in thumb mode), so "&write_basic_trace_file"
in the program becomes 0x8959, which is saved in the trace file. That
is why the warnnings are emitted.
This patch is to clear the LSB of the function address written to trace
file in thumb and thumb2 mode. This patch fixes the fail above.
gdb/testsuite:
2014-07-10 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.c (write_basic_trace_file)
[__thumb__||__thumb2__]: Clear the Thumb bit of the function
address written to trace file.
On async targets, a synchronous attach is done like this:
#1 - target_attach is called (PTRACE_ATTACH is issued)
#2 - a continuation is installed
#3 - we go back to the event loop
#4 - target reports stop (SIGSTOP), event loop wakes up, and
attach continuation is called
#5 - among other things, the continuation calls
target_terminal_inferior, which removes stdin from the event
loop
Note that in #3, GDB is still processing user input. If the user is
fast enough, e.g., with something like:
echo -e "attach PID\nset xxx=1" | gdb
... then the "set" command is processed before the attach completes.
We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:
(gdb) attach PID\nset xxx=1
we then crash readline/gdb, with:
Attaching to program: attach-wait-input, process 14537
readline: readline_callback_read_char() called with no handler!
Aborted
$
Fix this by calling target_terminal_inferior before #3 above.
The test covers both scenarios by running with editing/readline forced
to both on and off.
gdb/
2014-07-09 Pedro Alves <palves@redhat.com>
* infcmd.c (attach_command_post_wait): Don't call
target_terminal_inferior here.
(attach_command): Call it here instead.
gdb/testsuite/
2014-07-09 Pedro Alves <palves@redhat.com>
* gdb.base/attach-wait-input.exp: New file.
* gdb.base/attach-wait-input.c: New file.
https://sourceware.org/ml/gdb-patches/2014-05/msg00383.html
The MI command -var-info-path-expression currently does not handle
non-anonymous structs / unions nested within other structs / unions,
it will skip parts of the expression. Consider this example:
## START EXAMPLE ##
$ cat ex.c
#include <string.h>
int
main ()
{
struct s1
{
int a;
};
struct ss
{
struct s1 x;
};
struct ss an_ss;
memset (&an_ss, 0, sizeof (an_ss));
return 0;
}
$ gcc -g -o ex.x ex.c
$ gdb ex.x
(gdb) break 18
Breakpoint 1 at 0x80483ba: file ex.c, line 18.
(gdb) run
Starting program: /home/user/ex.x
Breakpoint 1, main () at ex.c:18
18 return 0;
(gdb) interpreter-exec mi "-var-create an_ss * an_ss"
(gdb) interpreter-exec mi "-var-list-children an_ss"
^done,numchild="1",children=[child={name="an_ss.x",exp="x",numchild="1",type="struct s1",thread-id="1"}],has_more="0"
(gdb) interpreter-exec mi "-var-list-children an_ss.x"
^done,numchild="1",children=[child={name="an_ss.x.a",exp="a",numchild="0",type="int",thread-id="1"}],has_more="0"
(gdb) interpreter-exec mi "-var-list-children an_ss.x.a"
^done,numchild="0",has_more="0"
(gdb) interpreter-exec mi "-var-info-path-expression an_ss.x.a"
^done,path_expr="(an_ss).a"
(gdb) print (an_ss).a
There is no member named a.
## END EXAMPLE ##
Notice that the path expression returned is wrong, and as a result
the print command fails.
This patch adds a new method to the varobj_ops structure called
is_path_expr_parent, to allow language specific control over finding
the parent varobj, the current logic becomes the C/C++ version and is
extended to handle the nested cases. No other language currently uses
this code, so all other languages just get a default method.
With this patch, the above example now finishes like this:
## START EXAMPLE ##
$ gdb ex.x
(gdb) break 18
Breakpoint 1 at 0x80483ba: file ex.c, line 18.
(gdb) run
Starting program: /home/user/ex.x
Breakpoint 1, main () at ex.c:18
18 return 0;
(gdb) interpreter-exec mi "-var-list-children an_ss"
^done,numchild="1",children=[child={name="an_ss.x",exp="x",numchild="1",type="struct s1",thread-id="1"}],has_more="0"
(gdb) interpreter-exec mi "-var-list-children an_ss.x"
^done,numchild="1",children=[child={name="an_ss.x.a",exp="a",numchild="0",type="int",thread-id="1"}],has_more="0"
(gdb) interpreter-exec mi "-var-list-children an_ss.x.a"
^done,numchild="0",has_more="0"
(gdb) interpreter-exec mi "-var-info-path-expression an_ss.x.a"
^done,path_expr="((an_ss).x).a"
(gdb) print ((an_ss).x).a
$1 = 0
## END EXAMPLE ##
Notice that the path expression is now correct, and the print is a
success.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_ops): Fill in is_path_expr_parent
field.
* c-varobj.c (c_is_path_expr_parent): New function, moved core
from varobj.c, with additional checks.
(c_varobj_ops): Fill in is_path_expr_parent field.
(cplus_varobj_ops): Fill in is_path_expr_parent field.
* jv-varobj.c (java_varobj_ops): Fill in is_path_expr_parent
field.
* varobj.c (is_path_expr_parent): Call is_path_expr_parent varobj
ops method.
(varobj_default_is_path_expr_parent): New function.
* varobj.h (lang_varobj_ops): Add is_path_expr_parent field.
(varobj_default_is_path_expr_parent): Declare new function.
gdb/testsuite/ChangeLog:
* gdb.mi/var-cmd.c (do_nested_struct_union_tests): New function
setting up test structures.
(main): Call new test function.
* gdb.mi/mi2-var-child.exp: Create additional breakpoint in new
test function, continue into test function and walk test
structures.
We see some fails in gdb.trace/entry-values.exp in thumb mode
(-mthumb -march={armv4t,armv7-a}).
In thumb mode, the lsb of references to 'foo' and 'bar' in the assembly
(produced by dwarf assember) is set, so the generated debug
information is incorrect.
This patch copies the approach used by
[PATCH 4/4] Fix dw2-ifort-parameter.exp on PPC64
https://sourceware.org/ml/gdb-patches/2014-03/msg00202.html
to introduce new labels 'foo_start' and 'bar_start' which are about
the correct function address (without lsb set). This patch fixes
these fails we've seen.
gdb/testsuite:
2014-07-08 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.c: Define labels 'foo_start' and
'bar_start' at the beginning of functions 'foo' and 'bar'
respectively.
* gdb.trace/entry-values.exp: Use 'foo_start' and 'bar_start'
instead of 'foo' and 'bar'.
The reverse-finish command results in an internal error if it cannot determine
the current function.
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) reverse-finish
Run back to call of #0 0x0000000000000000 in ?? ()
gdb/infcmd.c:1576: internal-error: Finish: couldn't find function.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is not an internal error case since the command may be used in scenarios
where there is no function at the current PC, e.g. after calling through a bad
function pointer.
Turn this into a normal error.
gdb/
* infcmd.c (finish_backward): Turn internal error into normal error.
testsuite/
* gdb.btrace/segv.c: New.
* gdb.btrace/segv.exp: New.
does in a way, because the arm/aarch64 branch instruction is the
same as powerpc's, but the target triplet pattern is not there.
In summary, the testcase fails to locate the branch offset and causes
a failure and the early termination of the test.
The following patch adds a separate conditional block for powerpc (to keep
things organized), allowing the testcase to continue.
2014-07-02 Luis Machado <lgustavo@codesourcery.com>
* gdb.trace/entry-values.exp: Handle powerpc-specific branch
instruction.
read_tag_const_type propagates the cv-qualifier to the array element type,
but read_tag_volatile_type didn't. Make sure that both cv-qualifiers that
apply to array types are handled the same.
gdb/ChangeLog
* dwarf2read.c (add_array_cv_type): New function.
(read_tag_const_type): Call add_array_cv_type for TYPE_CODE_ARRAY.
(read_tag_volatile_type): Likewise.
gdb/testsuite/ChangeLog
* gdb.base/constvars.c (violent, violet, vips, virgen, vulgar,
vulture, vilify, villar): New volatile array constants.
(vindictive, vegetation): New const volatile array constants.
* gdb.base/volatile.exp: Test volatile and const volatile array
types.
The test case "watchpoint-reuse-slot.exp" yields a lot of failures on
s390/s390x: all instances of awatch, rwatch, and hbreak are performed
even though they aren't supported on these targets. This is because
the test case ignores non-support error messages when probing for
support of these commands, like:
(gdb) rwatch buf.byte[0]
Target does not support this type of hardware watchpoint.
The patch adds handling for this case in the appropriate
gdb_test_multiple invocations.
gdb/testsuite/
* gdb.base/watchpoint-reuse-slot.exp: Handle the case that the
target lacks support for awatch, rwatch, or hbreak.
This patch is to add ptid into dummy_frame and extend frame_id to
dummy_frame_id (which has a ptid field). With this change, GDB uses
dummy_frame_id (thread ptid and frame_id) to find the dummy frames.
Currently, dummy frames are looked up by frame_id, which isn't
accurate in non-stop or multi-process mode. The test case
gdb.multi/dummy-frame-restore.exp shows the problem and this patch can
fix it.
Test dummy-frame-restore.exp makes two inferiors stop at
different functions, say, inferior 1 stops at f1 while inferior 2
stops at f2. Set a breakpoint to a function, do the inferior call
in two inferiors, and GDB has two dummy frames of the same frame_id.
When the inferior call is finished, GDB will look up a dummy frame
from its stack/list and restore the inferior's regcache. Two
inferiors are finished in different orders, the inferiors' states are
restored differently, which is wrong. Running dummy-frame-restore.exp
under un-patched GDB, we'll get two fails:
FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 2
FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 1
With this patch applied, GDB will choose the correct dummy_frame to
restore for a given inferior, because ptid is considered when looking up
dummy frames. Two fails above are fixed.
Regression tested on x86_64-linux, both native and gdbserver.
gdb:
2014-06-27 Yao Qi <yao@codesourcery.com>
* breakpoint.c (check_longjmp_breakpoint_for_call_dummy):
Change parameter type to 'struct thread_info *'. Caller
updated.
* breakpoint.h (check_longjmp_breakpoint_for_call_dummy):
Update declaration.
* dummy-frame.c (struct dummy_frame_id): New.
(dummy_frame_id_eq): New function.
(struct dummy_frame) <id>: Change its type to 'struct
dummy_frame_id'.
(dummy_frame_push): Add parameter ptid and save it in
dummy_frame_id.
(pop_dummy_frame_bpt): Use ptid of dummy_frame instead of
inferior_ptid.
(pop_dummy_frame): Assert that the ptid of dummy_frame equals
to inferior_ptid.
(lookup_dummy_frame): Change parameter type to 'struct
dummy_frame_id *'. Callers updated. Call dummy_frame_id_eq
instead of frame_id_eq.
(dummy_frame_pop): Add parameter ptid. Callers updated.
Update comments. Compose dummy_frame_id and pass it to
lookup_dummy_frame.
(dummy_frame_discard): Add parameter ptid.
(dummy_frame_sniffer): Compose dummy_frame_id and call
dummy_frame_id_eq instead of frame_id_eq.
(fprint_dummy_frames): Print ptid.
* dummy-frame.h: Remove comments.
(dummy_frame_push): Add ptid in declaration.
(dummy_frame_pop, dummy_frame_discard): Likewise.
gdb/testsuite:
2014-06-27 Yao Qi <yao@codesourcery.com>
* gdb.multi/dummy-frame-restore.exp: New.
* gdb.multi/dummy-frame-restore.c: New.
gdb/doc:
2014-06-27 Yao Qi <yao@codesourcery.com>
* gdb.texinfo (Maintenance Commands): Update the output of
'maint print dummy-frames' command.
When generating a core file using the "generate-core-file" command while
replaying with the btrace record target, we won't be able to access all
registers and all memory. This leads to the following assertion:
gdb/regcache.c:1034: internal-error: regcache_raw_supply: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.btrace/gcore.exp: generate-core-file core (GDB internal error)
Resyncing due to internal error.
Pretend that we are not replaying while generating a core file. This will
forward fetch and store registers as well as xfer memory calls to the target
beneath.
gdb/
* record-btrace.c (record_btrace_generating_corefile)
(record_btrace_prepare_to_generate_core)
(record_btrace_done_generating_core): New.
(record_btrace_xfer_partial, record_btrace_fetch_registers)
(record_btrace_store_registers, record_btrace_prepare_to_store):
Forward request when generating a core file.
(record_btrace_open): Set record_btrace_generating_corefile to zero.
(init_record_btrace_ops): Set to_prepare_to_generate_core and
to_done_generating_core.
testsuite/
* gdb.btrace/gcore.exp: New.
This patch fixes this on x86 Linux:
(gdb) watch *buf@2
Hardware watchpoint 8: *buf@2
(gdb) si
0x00000000004005a7 34 for (i = 0; i < 100000; i++); /* stepi line */
(gdb) del
Delete all breakpoints? (y or n) y
(gdb) watch *(buf+1)@1
Hardware watchpoint 9: *(buf+1)@1
(gdb) si
0x00000000004005a7 in main () at ../../../src/gdb/testsuite/gdb.base/watchpoint-reuse-slot.c:34
34 for (i = 0; i < 100000; i++); /* stepi line */
Couldn't write debug register: Invalid argument.
(gdb)
In the example above the debug registers are being switched from this
state:
CONTROL (DR7): 0000000000050101 STATUS (DR6): 0000000000000000
DR0: addr=0x0000000000601040, ref.count=1 DR1: addr=0x0000000000000000, ref.count=0
DR2: addr=0x0000000000000000, ref.count=0 DR3: addr=0x0000000000000000, ref.count=0
to this:
CONTROL (DR7): 0000000000010101 STATUS (DR6): 0000000000000000
DR0: addr=0x0000000000601041, ref.count=1 DR1: addr=0x0000000000000000, ref.count=0
DR2: addr=0x0000000000000000, ref.count=0 DR3: addr=0x0000000000000000, ref.count=0
That is, before, DR7 was setup for watching a 2 byte region starting
at what's in DR0 (0x601040).
And after, DR7 is setup for watching a 1 byte region starting at
what's in DR0 (0x601041).
We always write DR0..DR3 before DR7, because if we enable a slot's
bits in DR7, you need to have already written the corresponding
DR0..DR3 registers -- the kernel rejects the DR7 write with EINVAL
otherwise.
The error shown above is the opposite scenario. When we try to write
0x601041 to DR0, DR7's bits still indicate intent of watching a 2-byte
region. That DR0/DR7 combination is invalid, because 0x601041 is
unaligned. To watch two bytes, we'd have to use two slots. So the
kernel errors out with EINVAL.
Fix this by always first clearing DR7, then writing DR0..DR3, and then
setting DR7's bits.
A little optimization -- if we're disabling the last watchpoint, then
we can clear DR7 just once. The changes to nat/i386-dregs.c make that
easier to detect, and as bonus, they make it a little easier to make
sense of DR7 in the debug logs, as we no longer need to remember we're
seeing stale bits.
Tested on x86_64 Fedora 20, native and GDBserver.
This adds an exhaustive test that switches between many different
combinations of watchpoint types and addresses and widths.
gdb/
2014-06-23 Pedro Alves <palves@redhat.com>
* amd64-linux-nat.c (amd64_linux_prepare_to_resume): Clear
DR_CONTROL before setting DR0..DR3.
* i386-linux-nat.c (i386_linux_prepare_to_resume): Likewise.
* nat/i386-dregs.c (i386_remove_aligned_watchpoint): Clear all
bits of DR_CONTROL related to the debug register slot being
disabled. If all slots are vacant, clear local slowdown as well,
and assert DR_CONTROL is 0.
gdb/gdbserver/
2014-06-23 Pedro Alves <palves@redhat.com>
* linux-x86-low.c (x86_linux_prepare_to_resume): Clear DR_CONTROL
before setting DR0..DR3.
gdb/testsuite/
2014-06-23 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-reuse-slot.c: New file.
* gdb.base/watchpoint-reuse-slot.exp: New file.
Yao Qi
Doug Evans
Luis Machado
Pedro Alves
Iain Buclaw
Siva Chandra
Joel Brobecker
Maciej W. Rozycki
Sergio Durigan Junior
Jan Kratochvil
Simon Marchi
Patrick Palka
Doug Evans
Edjunior Barbosa Machado
Gabriel Krisman Bertazi
Sasha Smundak
Gary Benson
David Blaikie
Tom Tromey
Will Newton
Pierre Langlois
Andrew Burgess
Markus Metzger
Mark Wielaard
Andreas Arnez