Ignoring expected and desired differences like whether the prompt is
output after *stoppped records, GDB MI output is still different in
sync and async modes.
In sync mode, when a CLI execution command is entered, the "reason"
field is missing in the *stopped async record. And in async mode, for
some events, like program exits, the corresponding CLI output is
missing in the CLI channel.
Vis, diff between sync vs async modes:
run
^running
*running,thread-id="1"
(gdb)
...
- ~"[Inferior 1 (process 15882) exited normally]\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
- *stopped
+ *stopped,reason="exited-normally"
si
...
(gdb)
~"0x000000000045e033\t29\t memset (&args, 0, sizeof args);\n"
- *stopped,frame=...,thread-id="1",stopped-threads="all",core="0"
+ *stopped,reason="end-stepping-range",frame=...,thread-id="1",stopped-threads="all",core="0"
(gdb)
In addition, in both cases, when a MI execution command is entered,
and a breakpoint triggers, the event is sent to the console too. But
some events like program exits have the CLI output missing in the CLI
channel:
-exec-run
^running
*running,thread-id="1"
(gdb)
...
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
- *stopped
+ *stopped,reason="exited-normally"
We'll want to make background commands always possible by default.
IOW, make target-async be the default. But, in order to do that,
we'll need to emulate MI sync on top of an async target. That means
we'll have yet another combination to care for in the testsuite.
Rather than making the testsuite cope with all these differences, I
thought it better to just fix GDB to always have the complete output,
no matter whether it's in sync or async mode.
This is all related to interpreter-exec, and the corresponding uiout
switching. (Typing a CLI command directly in MI is shorthand for
running it through -interpreter-exec console.)
In sync mode, when a CLI command is active, normal_stop is called when
the current interpreter and uiout are CLI's. So print_XXX_reason
prints the stop reason to CLI uiout (only), and we don't show it in
MI.
In async mode the stop event is processed when we're back in the MI
interpreter, so the stop reason is printed directly to the MI uiout.
Fix this by making run control event printing roughly independent of
whatever is the current interpreter or uiout. That is, move these
prints to interpreter observers, that know whether to print or be
quiet, and if printing, which uiout to print to. In the case of the
console/tui interpreters, only print if the top interpreter. For MI,
always print.
Breakpoint hits / normal stops are already handled similarly -- MI has
a normal_stop observer that prints the event to both MI and the CLI,
though that could be cleaned up further in the direction of this
patch.
This also makes all of:
(gdb) foo
and
(gdb) interpreter-exec MI "-exec-foo"
and
(gdb)
-exec-foo
and
(gdb)
-interpreter-exec console "foo"
print as expected.
Tested on x86_64 Fedora 20, sync and async modes.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* cli/cli-interp.c: Include infrun.h and observer.h.
(cli_uiout, cli_interp): New globals.
(cli_on_signal_received, cli_on_end_stepping_range)
(cli_on_signal_exited, cli_on_exited, cli_on_no_history): New
functions.
(cli_interpreter_init): Install them as 'end_stepping_range',
'signal_received' 'signal_exited', 'exited' and 'no_history'
observers.
(_initialize_cli_interp): Remove cli_interp local.
* infrun.c (handle_inferior_event): Call the several stop reason
observers instead of printing the stop reason directly.
(end_stepping_range): New function.
(print_end_stepping_range_reason, print_signal_exited_reason)
(print_exited_reason, print_signal_received_reason)
(print_no_history_reason): Make static, and add an uiout
parameter. Print to that instead of to CURRENT_UIOUT.
* infrun.h (print_end_stepping_range_reason)
(print_signal_exited_reason, print_exited_reason)
(print_signal_received_reason print_no_history_reason): New
declarations.
* mi/mi-common.h (struct mi_interp): Rename 'uiout' field to
'mi_uiout'.
<cli_uiout>: New field.
* mi/mi-interp.c (mi_interpreter_init): Adjust. Create the new
uiout for CLI output. Install 'signal_received',
'end_stepping_range', 'signal_exited', 'exited' and 'no_history'
observers.
(find_mi_interpreter, mi_interp_data, mi_on_signal_received)
(mi_on_end_stepping_range, mi_on_signal_exited, mi_on_exited)
(mi_on_no_history): New functions.
(ui_out_free_cleanup): Delete function.
(mi_on_normal_stop): Don't allocate a new uiout for CLI output,
instead use the one already stored in the MI interpreter data.
(mi_ui_out): Adjust.
* tui/tui-interp.c: Include infrun.h and observer.h.
(tui_interp): New global.
(tui_on_signal_received, tui_on_end_stepping_range)
(tui_on_signal_exited, tui_on_exited)
(tui_on_no_history): New functions.
(tui_init): Install them as 'end_stepping_range',
'signal_received' 'signal_exited', 'exited' and 'no_history'
observers.
(_initialize_tui_interp): Delete tui_interp local.
gdb/doc/
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* observer.texi (signal_received, end_stepping_range)
(signal_exited, exited, no_history): New observer subjects.
gdb/testsuite/
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-cli.exp: Always expect "end-stepping-range" stop
reason, even in sync mode.
If one sets a breakpoint with a condition that involves calling a
function in the inferior, and then the condition evaluates false, GDB
outputs one *running event for each time the program hits the
breakpoint. E.g.,
$ gdb return-false -i=mi
(gdb)
start
...
(gdb)
b 14 if return_false ()
&"b 14 if return_false ()\n"
~"Breakpoint 2 at 0x4004eb: file return-false.c, line 14.\n"
...
^done
(gdb)
c
&"c\n"
~"Continuing.\n"
^running
*running,thread-id=(...)
(gdb)
*running,thread-id=(...)
*running,thread-id=(...)
*running,thread-id=(...)
*running,thread-id=(...)
*running,thread-id=(...)
... repeat forever ...
An easy way a user can trip on this is with a dprintf with "set
dprintf-style call". In that case, a dprintf is just a breakpoint
that when hit GDB calls the printf function in the inferior, and then
resumes it, just like the case above.
If the breakpoint/dprintf is set in a loop, then these spurious events
can potentially slow down a frontend much, if it decides to refresh
its GUI whenever it sees this event (Eclipse is one such case).
When we run an infcall, we pretend we don't actually run the inferior.
This is already handled for the usual case of calling a function
directly from the CLI:
(gdb)
p return_false ()
&"p return_false ()\n"
~"$1 = 0"
~"\n"
^done
(gdb)
Note no *running, nor *stopped events. That's handled by:
static void
mi_on_resume (ptid_t ptid)
{
...
/* Suppress output while calling an inferior function. */
if (tp->control.in_infcall)
return;
and equivalent code on normal_stop.
However, in the cases of the PR, after finishing the infcall there's
one more resume, and mi_on_resume doesn't know that it should suppress
output then too, somehow.
The "running/stopped" state is a high level user/frontend state.
Internal stops are invisible to the frontend. If follows from that
that we should be setting the thread to running at a higher level
where we still know the set of threads the user _intends_ to resume.
Currently we mark a thread as running from within target_resume, a low
level target operation. As consequence, today, if we resume a
multi-threaded program while stopped at a breakpoint, we see this:
-exec-continue
^running
*running,thread-id="1"
(gdb)
*running,thread-id="all"
The first *running was GDB stepping over the breakpoint, and the
second is GDB finally resuming everything.
Between those two *running's, threads other than "1" still have their
state set to stopped. That's bogus -- in async mode, this opens a
tiny window between both resumes where the user might try to run
another execution command to threads other than thread 1, and very
much confuse GDB.
That is, the "step" below should fail the "step", complaining that the
thread is running:
(gdb) c -a &
(gdb) thread 2
(gdb) step
IOW, threads that GDB happens to not resume immediately (say, because
it needs to step over a breakpoint) shall still be marked as running.
Then, if we move marking threads as running to a higher layer,
decoupled from target_resume, plus skip marking threads as running
when running an infcall, the spurious *running events disappear,
because there will be no state transitions at all.
I think we might end up adding a new thread state -- THREAD_INFCALL or
some such, however since infcalls are always synchronous today, I
didn't find a need. There's no way to execute a CLI/MI command
directly from the prompt if some thread is running an infcall.
Tested on x86_64 Fedora 20.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
PR PR15693
* infrun.c (resume): Determine how much to resume depending on
whether the caller wanted a step, not whether we can hardware step
the target. Mark all threads that we intend to run as running,
unless we're calling an inferior function.
(normal_stop): If the thread is running an infcall, don't finish
thread state.
* target.c (target_resume): Don't mark threads as running here.
gdb/testsuite/
2014-05-29 Pedro Alves <palves@redhat.com>
Hui Zhu <hui@codesourcery.com>
PR PR15693
* gdb.mi/mi-condbreak-call-thr-state-mt.c: New file.
* gdb.mi/mi-condbreak-call-thr-state-st.c: New file.
* gdb.mi/mi-condbreak-call-thr-state.c: New file.
* gdb.mi/mi-condbreak-call-thr-state.exp: New file.
This patch removes support for the "set/show remotebaud" command,
which were deprecated in GDB 7.7, and should be now be removed
ahead of cutting the GDB 7.8 branch.
gdb/ChangeLog:
* serial.c (_initialize_serial): Remove support for
the "set remotebaud" and "show remotebaud" commands.
* NEWS: Add entry documenting the removal of that command.
gdb/testsuite/ChangeLog:
* config/monitor.exp (gdb_target_monitor): Replace use of
"set remotebaud" by "set serial baud".
When I run no-thread-db.exp, the breakpoint is set on line 26.
However, the breakpoint is set to line 26 of dl-start.S rather than
no-thread-db.c, which is not intended.
(gdb) monitor set libthread-db-search-path /foo/bar^M
libthread-db-search-path set to `/foo/bar'^M
(gdb) PASS: gdb.server/no-thread-db.exp: libthread-db is now unresolvable
break 26^M
Breakpoint 1 at 0x48018078: file ../sysdeps/powerpc/powerpc32/dl-start.S, line 26.^M
(gdb) continue^M
Continuing.
This patch is to change the breakpoint setting with source file
specified, then it is correct now.
gdb/testsuite:
2014-05-26 Yao Qi <yao@codesourcery.com>
* gdb.server/no-thread-db.exp: Specify source file name
explicitly when setting a breakpoint.
When loading symbols for the vdso, also add its sections to target_sections.
This fixes an issue with record btrace where vdso instructions could not be
disassembled during replay.
* symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
testsuite/
* gdb.btrace/vdso.c: New.
* gdb.btrace/vdso.exp: New.
Allow gcore's capture_command_output function to be used by other tests.
testsuite/
* gdb.base/gcore.exp (capture_command_output): Move ...
* lib/gdb.exp (capture_command_output): ... here.
The btrace record target does not trace data. We therefore do not allow
accessing read-write memory during replay.
In some cases, this might be useful to advanced users, though, who we assume
to know what they are doing.
Add a set|show command pair to turn this memory access restriction off.
* record-btrace.c (record_btrace_allow_memory_access): Remove.
(replay_memory_access_read_only, replay_memory_access_read_write)
(replay_memory_access_types, replay_memory_access)
(set_record_btrace_cmdlist, show_record_btrace_cmdlist)
(cmd_set_record_btrace, cmd_show_record_btrace)
(cmd_show_replay_memory_access): New.
(record_btrace_xfer_partial, record_btrace_insert_breakpoint)
(record_btrace_remove_breakpoint): Replace
record_btrace_allow_memory_access with replay_memory_access.
(_initialize_record_btrace): Add commands.
* NEWS: Announce it.
testsuite/
* gdb.btrace/data.exp: Test it.
doc/
* gdb.texinfo (Process Record and Replay): Document it.
It should clear up confusion about the args parameter to mi_run_cmd_full.
Thanks to Joel for clear formulation. I also added a comment about the
impact of use_gdb_stub.
gdb/testsuite/ChangeLog:
2014-05-22 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_run_cmd_full): Add comments.
The other part of PR gdb/13860 is about console execution commands in
MI getting their output half lost. E.g., take the finish command,
executed on a frontend's GDB console:
sync:
finish
&"finish\n"
~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n"
^running
*running,thread-id="1"
(gdb)
~"0x00000000004004d7 in foo () at stepinf.c:6\n"
~"6\t usleep (10);\n"
~"Value returned is $1 = 0\n"
*stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},thread-id="1",stopped-threads="all",core="1"
async:
finish
&"finish\n"
~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n"
^running
*running,thread-id="1"
(gdb)
*stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},gdb-result-var="$1",return-value="0",thread-id="1",stopped-threads="all",core="0"
Note how all the "Value returned" etc. output is missing in async mode.
The same happens with e.g., catchpoints:
=breakpoint-modified,bkpt={number="1",type="catchpoint",disp="keep",enabled="y",what="22016",times="1"}
~"\nCatchpoint "
~"1 (forked process 22016), 0x0000003791cbd8a6 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131\n"
~"131\t pid = ARCH_FORK ();\n"
*stopped,reason="fork",disp="keep",bkptno="1",newpid="22016",frame={addr="0x0000003791cbd8a6",func="__libc_fork",args=[],file="../nptl/sysdeps/unix/sysv/linux/fork.c",fullname="/usr/src/debug/glibc-2.14-394-g8f3b1ff/nptl/sysdeps/unix/sysv/linux/fork.c",line="131"},thread-id="1",stopped-threads="all",core="0"
where all those ~ lines are missing in async mode, or just the "step"
current line indication:
s
&"s\n"
^running
*running,thread-id="all"
(gdb)
~"13\t foo ();\n"
*stopped,frame={addr="0x00000000004004ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffdd78"}],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="13"},thread-id="1",stopped-threads="all",core="3"
(gdb)
Or in the case of the PRs example, the "Stopped due to shared library
event" note:
start
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="21990"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="3"
(gdb)
IMO, if you're typing execution commands in a frontend's console, you
expect to see their output. Indeed it's what you get in sync mode. I
think async mode should do the same. Deciding what to mirror to the
console wrt to breakpoints and random stops gets messy real fast.
E.g., say "s" trips on a breakpoint. We'd clearly want to mirror the
event to the console in this case. But what about more complicated
cases like "s&; thread n; s&", and one of those steps spawning a new
thread, and that thread hitting a breakpoint? It's impossible in
general to track whether the thread had any relation to the commands
that had been executed. So I think we should just simplify and always
mirror breakpoints and random events to the console.
Notes:
- mi->out is the same as gdb_stdout when MI is the current
interpreter. I think that referring to that directly is cleaner.
An earlier revision of this patch made the changes that are now
done in mi_on_normal_stop directly in infrun.c:normal_stop, and so
not having an obvious place to put the new uiout by then, and not
wanting to abuse CLI's uiout, I made a temporary uiout when
necessary.
- Hopefuly the rest of the patch is more or less obvious given the
comments added.
Tested on x86_64 Fedora 20, no regressions.
2014-05-21 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdbthread.h (struct thread_control_state): New field
`command_interp'.
* infrun.c (follow_fork): Copy the new thread control field to the
child fork thread.
(clear_proceed_status_thread): Clear the new thread control field.
(proceed): Set the new thread control field.
* interps.h (command_interp): Declare.
* interps.c (command_interpreter): New global.
(command_interp): New function.
(interp_exec): Set `command_interpreter' while here.
* cli-out.c (cli_uiout_dtor): New function.
(cli_ui_out_impl): Install it.
* mi/mi-interp.c: Include cli-out.h.
(mi_cmd_interpreter_exec): Add comment.
(restore_current_uiout_cleanup): New function.
(ui_out_free_cleanup): New function.
(mi_on_normal_stop): If finishing an execution command started by
a CLI command, or any kind of breakpoint-like event triggered,
print the stop event to the output (CLI) stream.
* mi/mi-out.c (mi_ui_out_impl): Install NULL `dtor' handler.
2014-05-21 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-cli.exp (line_callee4_next_step): New global.
(top level): Test that output related to execution commands is
sent to the console with CLI commands, but not with MI commands.
Test that breakpoint events are always mirrored to the console.
Also expect the new source line to be output after a "next" in
async mode too. Make it a pass/fail test.
* gdb.mi/mi-solib.exp: Test that the CLI solib event note is
output.
* lib/mi-support.exp (mi_gdb_expect_cli_output): New procedure.
I noticed that "list" behaves differently in CLI vs MI. Particularly:
$ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli...done.
(gdb) start
Temporary breakpoint 1 at 0x40054d: file ../../../src/gdb/testsuite/gdb.mi/basics.c, line 62.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62
62 callee1 (2, "A string argument.", 3.5);
(gdb) list
57 {
58 }
59
60 main ()
61 {
62 callee1 (2, "A string argument.", 3.5);
63 callee1 (2, "A string argument.", 3.5);
64
65 do_nothing (); /* Hello, World! */
66
(gdb)
Note the list started at line 57. IOW, the program stopped at line
62, and GDB centered the list on that.
compare with:
$ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli..."
~"done.\n"
(gdb)
start
&"start\n"
...
~"\nTemporary breakpoint "
~"1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62\n"
~"62\t callee1 (2, \"A string argument.\", 3.5);\n"
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000000000040054d",func="main",args=[],file="../../../src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/basics.c",line="62"},thread-id="1",stopped-threads="all",core="0"
=breakpoint-deleted,id="1"
(gdb)
-interpreter-exec console list
~"62\t callee1 (2, \"A string argument.\", 3.5);\n"
~"63\t callee1 (2, \"A string argument.\", 3.5);\n"
~"64\t\n"
~"65\t do_nothing (); /* Hello, World! */\n"
~"66\t\n"
~"67\t callme (1);\n"
~"68\t callme (2);\n"
~"69\t\n"
~"70\t return 0;\n"
~"71\t}\n"
^done
(gdb)
Here the list starts at line 62, where the program was stopped.
This happens because print_stack_frame, called from both normal_stop
and mi_on_normal_stop, is the function responsible for setting the
current sal from the selected frame, overrides the PRINT_WHAT
argument, and only after that does it decide whether to center the
current sal line or not, based on the overridden value, and it will
always decide false.
(The print_stack_frame call in mi_on_normal_stop is a little different
from the call in normal_stop, in that it is an unconditional
SRC_AND_LOC call. A future patch will make those uniform.)
A previous version of this patch made MI uniform with CLI here, by
making print_stack_frame also center when MI is active. That changed
the output of a "list" command in mi-cli.exp, to expect line 57
instead of 62, as per the example above.
However, looking deeper, that list in question is the first "list"
after the program stops, and right after the stop, before the "list",
the test did "set listsize 1". Let's try the same thing with the CLI:
(gdb) start
62 callee1 (2, "A string argument.", 3.5);
(gdb) set listsize 1
(gdb) list
57 {
Huh, that's unexpected. Why the 57? It's because print_stack_frame,
called in reaction to the breakpoint stop, expecting the next "list"
to show 10 lines (the listsize at the time) around line 62, sets the
lines listed range to 57-67 (62 +/- 5). If the user changes the
listsize before "list", why would we still show that range? Looks
bogus to me.
So the fix for this whole issue should be delay trying to center the
listing to until actually listing, so that the correct listsize can be
taken into account. This makes MI and CLI uniform too, as it deletes
the center code from print_stack_frame.
A series of tests are added to list.exp to cover this. mi-cli.exp was
after all correct all along, but it now gains an additional test that
lists lines with listsize 10, to ensure the centering is consistent
with CLI's.
One related Python test changed related output -- it's a test that
prints the line number after stopping for a breakpoint, similar to the
new list.exp tests. Previously we'd print the stop line minus 5 (due
to the premature centering), now we print the stop line. I think
that's a good change.
Tested on x86_64 Fedora 20.
gdb/
2014-05-21 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (list_command): Handle the first "list" after the
current source line having changed.
* frame.h (set_current_sal_from_frame): Remove 'center' parameter.
* infrun.c (normal_stop): Adjust call to
set_current_sal_from_frame.
* source.c (clear_lines_listed_range): New function.
(set_current_source_symtab_and_line, identify_source_line): Clear
the lines listed range.
(line_info): Handle the first "info line" after the current source
line having changed.
* stack.c (print_stack_frame): Remove center handling.
(set_current_sal_from_frame): Remove 'center' parameter. Don't
center sal.line.
gdb/testsuite/
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (build_pattern, test_list): New procedures.
Use them to test variations of "list" after reaching a breakpoint.
* gdb.mi/mi-cli.exp (line_main_callme_2): New global.
Test "list" with listsize 10 after reaching a breakpoint.
* gdb.python/python.exp (decode_line current location line
number): Adjust expected line number.
This reverts commit 8c217a4b68.
Following this
https://sourceware.org/ml/gdb-patches/2014-05/msg00462.html
I suggest reverting my previous commit. I will follow with another
patch to add comments, to clarify some things as stated in the mail
thread.
I ran make check with on gdb.mi, and the test that the commit broke
passes again.
gdb/testsuite/ChangeLog:
2014-05-21 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_run_cmd_full): Revert to original
behavior for $args, pass it directly to "run".
This fixes:
PASS: gdb.base/info-macros.exp: info macro -a -- FOO
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: info macros 2
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: info macros 3
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: info macros 4
FAIL: gdb.base/info-macros.exp: info macros *$pc
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: next
FAIL: gdb.base/info-macros.exp: info macros
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: next
FAIL: gdb.base/info-macros.exp: info macros 6
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: next
FAIL: gdb.base/info-macros.exp: info macros 7
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-macros.exp: info macros info-macros.c:42 (PRMS
gdb/NNNN)
with the arm-eabi target tested on the i686-mingw32 host where GCC
defines enough macros to exhaust expect's 30000 characters of buffer
space.
* lib/gdb.exp (default_gdb_init): Bump `match_max' up from
30000 to 65536.
Sometimes it's useful to be able to disable the automatic connection
to the native target. E.g., sometimes GDB disconnects from the
extended-remote target I was debugging, without me noticing it, and
then I do "run". That starts the program locally, and only after a
little head scratch session do I figure out the program is running
locally instead of remotely as intended. Same thing with "attach",
"info os", etc.
With the patch, we now can have this instead:
(gdb) set auto-connect-native-target off
(gdb) target extended-remote :9999
...
*gdb disconnects*
(gdb) run
Don't know how to run. Try "help target".
To still be able to connect to the native target with
auto-connect-native-target set to off, I've made "target native" work
instead of erroring out as today.
Before:
(gdb) target native
Use the "run" command to start a native process.
After:
(gdb) target native
Done. Use the "run" command to start a process.
(gdb) maint print target-stack
The current target stack is:
- native (Native process)
- exec (Local exec file)
- None (None)
(gdb) run
Starting program: ./a.out
...
I've also wanted this for the testsuite, when running against the
native-extended-gdbserver.exp board (runs against gdbserver in
extended-remote mode). With a non-native-target board, it's always a
bug to launch a program with the native target. Turns out we still
have one such case this patch catches:
(gdb) break main
Breakpoint 1 at 0x4009e5: file ../../../src/gdb/testsuite/gdb.base/coremaker.c, line 138.
(gdb) run
Don't know how to run. Try "help target".
(gdb) FAIL: gdb.base/corefile.exp: run: with core
On the patch itself, probably the least obvious bit is the need to go
through all targets, and move the unpush_target call to after the
generic_mourn_inferior call instead of before. This is what
inf-ptrace.c does too, ever since multi-process support was added.
The reason inf-ptrace.c does things in that order is that in the
current multi-process/single-target model, we shouldn't unpush the
target if there are still other live inferiors being debugged. The
check for that is "have_inferiors ()" (a misnomer nowadays...), which
does:
have_inferiors (void)
{
for (inf = inferior_list; inf; inf = inf->next)
if (inf->pid != 0)
return 1;
It's generic_mourn_inferior that ends up clearing inf->pid, so we need
to call it before the have_inferiors check. To make all native
targets behave the same WRT to explicit "target native", I've added an
inf_child_maybe_unpush_target function that targets call instead of
calling unpush_target directly, and as that includes the
have_inferiors check, I needed to adjust the targets.
Tested on x86_64 Fedora 20, native, and also with the
extended-gdbserver board.
Confirmed a cross build of djgpp gdb still builds.
Smoke tested a cross build of Windows gdb under Wine.
Untested otherwise.
gdb/
2014-05-21 Pedro Alves <palves@redhat.com>
* inf-child.c (inf_child_ops, inf_child_explicitly_opened): New
globals.
(inf_child_open_target): New function.
(inf_child_open): Use inf_child_open_target to push the target
instead of erroring out.
(inf_child_disconnect, inf_child_close)
(inf_child_maybe_unpush_target): New functions.
(inf_child_target): Install inf_child_disconnect and
inf_child_close. Store a pointer to the returned object.
* inf-child.h (inf_child_open_target, inf_child_maybe_unpush): New
declarations.
* target.c (auto_connect_native_target): New global.
(show_default_run_target): New function.
(find_default_run_target): Return NULL if automatically connecting
to the native target is disabled.
(_initialize_target): Install set/show auto-connect-native-target.
* NEWS: Mention "set auto-connect-native-target", and "target
native".
* linux-nat.c (super_close): New global.
(linux_nat_close): Call super_close.
(linux_nat_add_target): Store a pointer to the base class's
to_close method.
* inf-ptrace.c (inf_ptrace_mourn_inferior, inf_ptrace_detach): Use
inf_child_maybe_unpush.
* inf-ttrace.c (inf_ttrace_him): Don't push the target if it is
already pushed.
(inf_ttrace_mourn_inferior): Only unpush the target after mourning
the inferior. Use inf_child_maybe_unpush_target.
(inf_ttrace_attach): Don't push the target if it is already
pushed.
(inf_ttrace_detach): Use inf_child_maybe_unpush_target.
* darwin-nat.c (darwin_mourn_inferior): Only unpush the target
after mourning the inferior. Use inf_child_maybe_unpush_target.
(darwin_attach_pid): Don't push the target if it is already
pushed.
* gnu-nat.c (gnu_mourn_inferior): Only unpush the target after
mourning the inferior. Use inf_child_maybe_unpush_target.
(gnu_detach): Use inf_child_maybe_unpush_target.
* go32-nat.c (go32_create_inferior): Don't push the target if it
is already pushed.
(go32_mourn_inferior): Use inf_child_maybe_unpush_target.
* nto-procfs.c (procfs_is_nto_target): Adjust comment.
(procfs_open): Rename to ...
(procfs_open_1): ... this. Add target_ops parameter. Adjust
comments. Can target_preopen before changing node. Call
inf_child_open_target to push the target explicitly.
(procfs_attach): Don't push the target if it is already pushed.
(procfs_detach): Use inf_child_maybe_unpush_target.
(procfs_create_inferior): Don't push the target if it is already
pushed.
(nto_native_ops): New global.
(procfs_open): Reimplement.
(procfs_native_open): New function.
(init_procfs_targets): Install procfs_native_open as to_open of
"target native". Store a pointer to the "native" target in
nto_native_ops.
* procfs.c (procfs_attach): Don't push the target if it is already
pushed.
(procfs_detach): Use inf_child_maybe_unpush_target.
(procfs_mourn_inferior): Only unpush the target after mourning the
inferior. Use inf_child_maybe_unpush_target.
(procfs_init_inferior): Don't push the target if it is already
pushed.
* windows-nat.c (do_initial_windows_stuff): Don't push the target
if it is already pushed.
(windows_detach): Use inf_child_maybe_unpush_target.
(windows_mourn_inferior): Only unpush the target after mourning
the inferior. Use inf_child_maybe_unpush_target.
gdb/doc/
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Starting): Document "set/show
auto-connect-native-target".
(Target Commands): Document "target native".
gdb/testsuite/
2014-05-21 Pedro Alves <palves@redhat.com>
* boards/gdbserver-base.exp (GDBFLAGS): Set to "set
auto-connect-native-target off".
* gdb.base/auto-connect-native-target.c: New file.
* gdb.base/auto-connect-native-target.exp: New file.
I had been pondering renaming "target child" to something else.
"child" is a little lie in case of "attach", and not exactly very
clear to users, IMO. By best suggestion is "target native". If I
were to explain what "target child" is, I'd just start out with "it's
the native target" anyway. I was worrying a little that "native"
might be a lie too if some port comes up with a default target that
can run but is not really native, but I think that's a very minor
issue - we can consider that "native" really means the default built
in target that GDB supports, instead of saying that's the target that
debugs host native processes, if it turns out necessary.
This change doesn't affect users much, because "target child" results
in error today:
(gdb) target child
Use the "run" command to start a child process.
Other places "child" is visible:
(gdb) help target
...
List of target subcommands:
target child -- Child process (started by the "run" command)
target core -- Use a core file as a target
target exec -- Use an executable file as a target
...
(gdb) info target
Symbols from "/home/pedro/gdb/mygit/build/gdb/gdb".
Child process:
Using the running image of child Thread 0x7ffff7fc9740 (LWP 4818).
While running this, GDB does not access memory from...
...
These places will say "native" instead. I think that's a good thing.
gdb/
2014-05-21 Pedro Alves <palves@redhat.com>
* inf-child.c (inf_child_open): Remove mention of "child".
(inf_child_target): Rename target to "native" instead of "child".
gdb/testsuite/
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Test "target native" instead of "target
child".
I have posted:
TLS variables access for -static -lpthread executables
https://sourceware.org/ml/libc-help/2014-03/msg00024.html
and the GDB patch below has been confirmed as OK for current glibcs.
Further work should be done for newer glibcs:
Improve TLS variables glibc compatibility
https://sourceware.org/bugzilla/show_bug.cgi?id=16954
Still the patch below implements the feature in a fully functional way backward
compatible with current glibcs, it depends on the following glibc source line:
csu/libc-tls.c
main_map->l_tls_modid = 1;
gdb/
2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix TLS access for -static -pthread.
* linux-thread-db.c (struct thread_db_info): Add td_thr_tlsbase_p.
(try_thread_db_load_1): Initialize it.
(thread_db_get_thread_local_address): Call it if LM is zero.
* target.c (target_translate_tls_address): Remove LM_ADDR zero check.
* target.h (struct target_ops) (to_get_thread_local_address): Add
load_module_addr comment.
gdb/gdbserver/
2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix TLS access for -static -pthread.
* gdbserver/thread-db.c (struct thread_db): Add td_thr_tlsbase_p.
(thread_db_get_tls_address): Call it if LOAD_MODULE is zero.
(thread_db_load_search, try_thread_db_load_1): Initialize it.
gdb/testsuite/
2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix TLS access for -static -pthread.
* gdb.threads/staticthreads.c <HAVE_TLS> (tlsvar): New.
<HAVE_TLS> (thread_function, main): Initialize it.
* gdb.threads/staticthreads.exp: Try gdb_compile_pthreads for $have_tls.
Add clean_restart.
<$have_tls != "">: Check TLSVAR.
Message-ID: <20140410115204.GB16411@host2.jankratochvil.net>
The dcache (code/stack cache) is supposed to be transparent, but it's
actually not in one case. dcache tries to read chunks (cache lines)
at a time off of the target. This may end up trying to read
unaccessible or unavailable memory. Currently the caller gets an xfer
error in this case. But if the specific bits of memory the caller
actually wanted are available and accessible, then the caller should
get the memory it wanted, not an error.
gdb/
2014-05-21 Pedro Alves <palves@redhat.com>
* dcache.c (dcache_read_memory_partial): If reading the cache line
fails, fallback to reading just the memory the caller wanted.
gdb/testsuite/
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/dcache-line-read-error.c: New.
* gdb.base/dcache-line-read-error.exp: New.
This does two things:
1. Adds a test.
Recently compare-sections got a new "-r" switch, but given no test
existed for compare-sections, the patch was allowed in with no
testsuite addition. This now adds a test for both compare-sections
and compare-sections -r.
2. Makes the compare-sections command work against all targets.
Currently, compare-sections only works with remote targets, and only
those that support the qCRC packet. The patch makes it so that if the
target doesn't support accelerating memory verification, then GDB
falls back to comparing memory itself. This is of course slower, but
it's better than nothing, IMO. While testing against extended-remote
GDBserver I noticed that we send the qCRC request to the target if
we're connected, but not yet running a program. That can't work of
course -- the patch fixes that. This all also goes in the direction
of bridging the local/remote parity gap.
I didn't decouple 1. from 2., because that would mean that the test
would need to handle the case of the target not supporting the
command.
Tested on x86_64 Fedora 17, native, remote GDBserver, and
extended-remote GDBserver. I also hack-disabled qCRC support to make
sure the fallback paths in remote.c work.
gdb/doc/
2014-05-20 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Memory) <compare-sections>: Generalize comments to
not be remote specific. Add cross reference to the qCRC packet.
(Separate Debug Files): Update cross reference to the qCRC packet.
(General Query Packets) <qCRC packet>: Add anchor.
gdb/
2014-05-20 Pedro Alves <palves@redhat.com>
* NEWS: Mention that compare-sections now works with all targets.
* remote.c (PACKET_qCRC): New enum value.
(remote_verify_memory): Don't send qCRC if the target has no
execution. Use packet_support/packet_ok. If the target doesn't
support the qCRC packet, fallback to a deep memory copy.
(compare_sections_command): Say "target image" instead of "remote
executable".
(_initialize_remote): Add PACKET_qCRC to the list of config
packets that have no associated command. Extend comment.
* target.c (simple_verify_memory, default_verify_memory): New
function.
* target.h (struct target_ops) <to_verify_memory>: Default to
default_verify_memory.
(simple_verify_memory): New declaration.
* target-delegates.c: Regenerate.
gdb/testsuite/
2014-05-20 Pedro Alves <palves@redhat.com>
* gdb.base/compare-sections.c: New file.
* gdb.base/compare-sections.exp: New file.
This patch fixes hardware breakpoint regressions exposed by my fix for
"PR breakpoints/7143 - Watchpoint does not trigger when first set", at
https://sourceware.org/ml/gdb-patches/2014-03/msg00167.html
The testsuite caught them on Linux/x86_64, at least. gdb.sum:
gdb.sum:
FAIL: gdb.base/hbreak2.exp: next over recursive call
FAIL: gdb.base/hbreak2.exp: backtrace from factorial(5.1)
FAIL: gdb.base/hbreak2.exp: continue until exit at recursive next test
gdb.log:
(gdb) next
Program received signal SIGTRAP, Trace/breakpoint trap.
factorial (value=4) at ../../../src/gdb/testsuite/gdb.base/break.c:113
113 if (value > 1) { /* set breakpoint 7 here */
(gdb) FAIL: gdb.base/hbreak2.exp: next over recursive call
Actually, that patch just exposed a latent issue to "breakpoints
always-inserted off" mode, not really caused it. After that patch,
GDB no longer removes breakpoints at each internal event, thus making
some scenarios behave like breakpoint always-inserted on. The bug is
easy to trigger with always-inserted on.
The issue is that since the target-side breakpoint conditions support,
if the stub/server supports evaluating breakpoint conditions on the
target side, then GDB is sending duplicate Zx packets to the target
without removing them before, and GDBserver is not really expecting
that for Z packets other than Z0/z0. E.g., with "set breakpoint
always-inserted on" and "set debug remote 1":
(gdb) b main
Sending packet: $m410943,1#ff...Packet received: 48
Breakpoint 4 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028.
Sending packet: $Z0,410943,1#48...Packet received: OK
^^^^^^^^^^^^
(gdb) b main
Note: breakpoint 4 also set at pc 0x410943.
Sending packet: $m410943,1#ff...Packet received: 48
Breakpoint 5 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028.
Sending packet: $Z0,410943,1#48...Packet received: OK
^^^^^^^^^^^^
(gdb) b main
Note: breakpoints 4 and 5 also set at pc 0x410943.
Sending packet: $m410943,1#ff...Packet received: 48
Breakpoint 6 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028.
Sending packet: $Z0,410943,1#48...Packet received: OK
^^^^^^^^^^^^
(gdb) del
Delete all breakpoints? (y or n) y
Sending packet: $Z0,410943,1#48...Packet received: OK
Sending packet: $Z0,410943,1#48...Packet received: OK
Sending packet: $z0,410943,1#68...Packet received: OK
And for Z1, similarly:
(gdb) hbreak main
Sending packet: $m410943,1#ff...Packet received: 48
Hardware assisted breakpoint 4 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028.
Sending packet: $Z1,410943,1#49...Packet received: OK
^^^^^^^^^^^^
Packet Z1 (hardware-breakpoint) is supported
(gdb) hbreak main
Note: breakpoint 4 also set at pc 0x410943.
Sending packet: $m410943,1#ff...Packet received: 48
Hardware assisted breakpoint 5 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028.
Sending packet: $Z1,410943,1#49...Packet received: OK
^^^^^^^^^^^^
(gdb) hbreak main
Note: breakpoints 4 and 5 also set at pc 0x410943.
Sending packet: $m410943,1#ff...Packet received: 48
Hardware assisted breakpoint 6 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028.
Sending packet: $Z1,410943,1#49...Packet received: OK
^^^^^^^^^^^^
(gdb) del
Delete all breakpoints? (y or n) y
Sending packet: $Z1,410943,1#49...Packet received: OK
^^^^^^^^^^^^
Sending packet: $Z1,410943,1#49...Packet received: OK
^^^^^^^^^^^^
Sending packet: $z1,410943,1#69...Packet received: OK
^^^^^^^^^^^^
So GDB sent a bunch of Z1 packets, and then when finally removing the
breakpoint, only one z1 packet was sent. On the GDBserver side (with
monitor set debug-hw-points 1), in the Z1 case, we see:
$ ./gdbserver :9999 ./gdbserver
Process ./gdbserver created; pid = 8629
Listening on port 9999
Remote debugging from host 127.0.0.1
insert_watchpoint (addr=410943, len=1, type=instruction-execute):
CONTROL (DR7): 00000101 STATUS (DR6): 00000000
DR0: addr=0x410943, ref.count=1 DR1: addr=0x0, ref.count=0
DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0
insert_watchpoint (addr=410943, len=1, type=instruction-execute):
CONTROL (DR7): 00000101 STATUS (DR6): 00000000
DR0: addr=0x410943, ref.count=2 DR1: addr=0x0, ref.count=0
DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0
insert_watchpoint (addr=410943, len=1, type=instruction-execute):
CONTROL (DR7): 00000101 STATUS (DR6): 00000000
DR0: addr=0x410943, ref.count=3 DR1: addr=0x0, ref.count=0
DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0
insert_watchpoint (addr=410943, len=1, type=instruction-execute):
CONTROL (DR7): 00000101 STATUS (DR6): 00000000
DR0: addr=0x410943, ref.count=4 DR1: addr=0x0, ref.count=0
DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0
insert_watchpoint (addr=410943, len=1, type=instruction-execute):
CONTROL (DR7): 00000101 STATUS (DR6): 00000000
DR0: addr=0x410943, ref.count=5 DR1: addr=0x0, ref.count=0
DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0
remove_watchpoint (addr=410943, len=1, type=instruction-execute):
CONTROL (DR7): 00000101 STATUS (DR6): 00000000
DR0: addr=0x410943, ref.count=4 DR1: addr=0x0, ref.count=0
DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0
That's one insert_watchpoint call for each Z1 packet, and then one
remove_watchpoint call for the z1 packet. Notice how ref.count
increased for each insert_watchpoint call, and then in the end, after
GDB told GDBserver to forget about the hardware breakpoint, GDBserver
ends with the the first debug register still with ref.count=4! IOW,
the hardware breakpoint is left armed on the target, while on the GDB
end it's gone. If the program happens to execute 0x410943 afterwards,
then the CPU traps, GDBserver reports the trap to GDB, and GDB not
having a breakpoint set at that address anymore, reports to the user a
spurious SIGTRAP.
This is exactly what is happening in the hbreak2.exp test, though in
that case, it's a shared library event that triggers a
breakpoint_re_set, when breakpoints are still inserted (because
nowadays GDB doesn't remove breakpoints while handling internal
events), and that recreates breakpoint locations, which likewise
forces breakpoint reinsertion and Zx packet resends...
That is a lot of bogus Zx duplication that should possibly be
addressed on the GDB side. GDB resends Zx packets because the way to
change the target-side condition, is to resend the breakpoint to the
server with the new condition. (That's an option in the packet: e.g.,
"Z1,410943,1;X3,220027" for "hbreak main if 0". The packets in the
examples above are shorter because the breakpoints don't have
conditions attached). GDB doesn't remove the breakpoint first before
reinserting it because that'd be bad for non-stop, as it'd open a
window where the inferior could miss the breakpoint. The conditions
actually haven't changed between the resends, but GDB isn't smart
enough to realize that.
(TBC, if the target doesn't support target-side conditions, then GDB
doesn't trigger these resends (init_bp_location calls
mark_breakpoint_location_modified, and that does nothing if condition
evaluation is on the host side. The resends are caused by the
'loc->condition_changed = condition_modified.' line.)
But, even if GDB was made smarter, GDBserver should really still
handle the resends anyway. So target-side conditions also aren't
really to blame. The documentation of the Z/z packets says:
"To avoid potential problems with duplicate packets, the operations
should be implemented in an idempotent way."
As such, we may want to fix GDB, but we should definitely fix
GDBserver. The fix is a prerequisite for target-side conditions on
hardware breakpoints anyway (and while at it, on watchpoints too).
GDBserver indeed already treats duplicate Z0 packets in an idempotent
way. mem-break.c has the concept of high-level and low-level
breakpoints, somewhat similar to GDB's split of breakpoints vs
breakpoint locations, and keeps track of multiple breakpoints
referencing the same address/location, for the case of an internal
GDBserver breakpoint or a tracepoint being set at the same address as
a GDB breakpoint. But, it only allows GDB to ever contribute one
reference to a software breakpoint location. IOW, if gdbserver sees a
Z0 packet for the same address where it already had a GDB breakpoint
set, then GDBserver won't create another high-level GDB breakpoint.
However, mem-break.c only tracks GDB Z0 breakpoints. The same logic
should apply to all kinds of Zx packets. Currently, gdbserver passes
down each duplicate Zx (other than Z0) request directly to the
target->insert_point routine. The x86 watchpoint support itself
refcounts watchpoint / hw breakpoint requests, to handle overlapping
watchpoints, and save debug registers. But that code doesn't (and
really shouldn't) handle the duplicate requests, assuming that for
each insert there will be a corresponding remove.
So the fix is to generalize mem-break.c to track all kinds of Zx
breakpoints, and filter out duplicates. As mentioned, this ends up
adding support for target-side conditions on hardware breakpoints and
watchpoints too (though GDB itself doesn't support the latter yet).
Probably the least obvious change in the patch is that it kind of
turns the breakpoint insert/remove APIs inside out. Before, the
target methods were only called for GDB breakpoints. The internal
breakpoint set/delete methods inserted memory breakpoints directly
bypassing the insert/remove target methods. That's not good when the
target should use a debug API to set software breakpoints, instead of
relying on GDBserver patching memory with breakpoint instructions, as
is the case of NTO.
Now removal/insertion of all kinds of breakpoints/watchpoints, either
internal, or from GDB, always go through the target methods. The
insert_point/remove_point methods no longer get passed a Z packet
type, but an internal/raw breakpoint type. They're also passed a
pointer to the raw breakpoint itself (note that's still opaque outside
mem-break.c), so that insert_memory_breakpoint /
remove_memory_breakpoint have access to the breakpoint's shadow
buffer. I first tried passing down a new structure based on GDB's
"struct bp_target_info" (actually with that name exactly), but then
decided against it as unnecessary complication.
As software/memory breakpoints work by poking at memory, when setting
a GDB Z0 breakpoint (but not internal breakpoints, as those can assume
the conditions are already right), we need to tell the target to
prepare to access memory (which on Linux means stop threads). If that
operation fails, we need to return error to GDB. Seeing an error, if
this is the first breakpoint of that type that GDB tries to insert,
GDB would then assume the breakpoint type is supported, but it may
actually not be. So we need to check whether the type is supported at
all before preparing to access memory. And to solve that, the patch
adds a new target->supports_z_point_type method that is called before
actually trying to insert the breakpoint.
Other than that, hopefully the change is more or less obvious.
New test added that exercises the hbreak2.exp regression in a more
direct way, without relying on a breakpoint re-set happening before
main is reached.
Tested by building GDBserver for:
aarch64-linux-gnu
arm-linux-gnueabihf
i686-pc-linux-gnu
i686-w64-mingw32
m68k-linux-gnu
mips-linux-gnu
mips-uclinux
nios2-linux-gnu
powerpc-linux-gnu
sh-linux-gnu
tilegx-unknown-linux-gnu
x86_64-redhat-linux
x86_64-w64-mingw32
And also regression tested on x86_64 Fedora 20.
gdb/gdbserver/
2014-05-20 Pedro Alves <palves@redhat.com>
* linux-aarch64-low.c (aarch64_insert_point)
(aarch64_remove_point): No longer check whether the type is
supported here. Adjust to new interface.
(the_low_target): Install aarch64_supports_z_point_type as
supports_z_point_type method.
* linux-arm-low.c (raw_bkpt_type_to_arm_hwbp_type): New function.
(arm_linux_hw_point_initialize): Take an enum raw_bkpt_type
instead of a Z packet char. Adjust.
(arm_supports_z_point_type): New function.
(arm_insert_point, arm_remove_point): Adjust to new interface.
(the_low_target): Install arm_supports_z_point_type.
* linux-crisv32-low.c (cris_supports_z_point_type): New function.
(cris_insert_point, cris_remove_point): Adjust to new interface.
Don't check whether the type is supported here.
(the_low_target): Install cris_supports_z_point_type.
* linux-low.c (linux_supports_z_point_type): New function.
(linux_insert_point, linux_remove_point): Adjust to new interface.
* linux-low.h (struct linux_target_ops) <insert_point,
remove_point>: Take an enum raw_bkpt_type instead of a char. Add
raw_breakpoint pointer parameter.
<supports_z_point_type>: New method.
* linux-mips-low.c (mips_supports_z_point_type): New function.
(mips_insert_point, mips_remove_point): Adjust to new interface.
Use mips_supports_z_point_type.
(the_low_target): Install mips_supports_z_point_type.
* linux-ppc-low.c (the_low_target): Install NULL as
supports_z_point_type method.
* linux-s390-low.c (the_low_target): Install NULL as
supports_z_point_type method.
* linux-sparc-low.c (the_low_target): Install NULL as
supports_z_point_type method.
* linux-x86-low.c (x86_supports_z_point_type): New function.
(x86_insert_point): Adjust to new insert_point interface. Use
insert_memory_breakpoint. Adjust to new
i386_low_insert_watchpoint interface.
(x86_remove_point): Adjust to remove_point interface. Use
remove_memory_breakpoint. Adjust to new
i386_low_remove_watchpoint interface.
(the_low_target): Install x86_supports_z_point_type.
* lynx-low.c (lynx_target_ops): Install NULL as
supports_z_point_type callback.
* nto-low.c (nto_supports_z_point_type): New.
(nto_insert_point, nto_remove_point): Adjust to new interface.
(nto_target_ops): Install nto_supports_z_point_type.
* mem-break.c: Adjust intro comment.
(struct raw_breakpoint) <raw_type, size>: New fields.
<inserted>: Update comment.
<shlib_disabled>: Delete field.
(enum bkpt_type) <gdb_breakpoint>: Delete value.
<gdb_breakpoint_Z0, gdb_breakpoint_Z1, gdb_breakpoint_Z2,
gdb_breakpoint_Z3, gdb_breakpoint_Z4>: New values.
(raw_bkpt_type_to_target_hw_bp_type): New function.
(find_enabled_raw_code_breakpoint_at): New function.
(find_raw_breakpoint_at): New type and size parameters. Use them.
(insert_memory_breakpoint): New function, based off
set_raw_breakpoint_at.
(remove_memory_breakpoint): New function.
(set_raw_breakpoint_at): Reimplement.
(set_breakpoint): New, based on set_breakpoint_at.
(set_breakpoint_at): Reimplement.
(delete_raw_breakpoint): Go through the_target->remove_point
instead of assuming memory breakpoints.
(find_gdb_breakpoint_at): Delete.
(Z_packet_to_bkpt_type, Z_packet_to_raw_bkpt_type): New functions.
(find_gdb_breakpoint): New function.
(set_gdb_breakpoint_at): Delete.
(z_type_supported): New function.
(set_gdb_breakpoint_1): New function, loosely based off
set_gdb_breakpoint_at.
(check_gdb_bp_preconditions, set_gdb_breakpoint): New functions.
(delete_gdb_breakpoint_at): Delete.
(delete_gdb_breakpoint_1): New function, loosely based off
delete_gdb_breakpoint_at.
(delete_gdb_breakpoint): New function.
(clear_gdb_breakpoint_conditions): Rename to ...
(clear_breakpoint_conditions): ... this. Don't handle a NULL
breakpoint.
(add_condition_to_breakpoint): Make static.
(add_breakpoint_condition): Take a struct breakpoint pointer
instead of an address. Adjust.
(gdb_condition_true_at_breakpoint): Rename to ...
(gdb_condition_true_at_breakpoint_z_type): ... this, and add
z_type parameter.
(gdb_condition_true_at_breakpoint): Reimplement.
(add_breakpoint_commands): Take a struct breakpoint pointer
instead of an address. Adjust.
(gdb_no_commands_at_breakpoint): Rename to ...
(gdb_no_commands_at_breakpoint_z_type): ... this. Add z_type
parameter. Return true if no breakpoint was found. Change debug
output.
(gdb_no_commands_at_breakpoint): Reimplement.
(run_breakpoint_commands): Rename to ...
(run_breakpoint_commands_z_type): ... this. Add z_type parameter,
and change return type to boolean.
(run_breakpoint_commands): New function.
(gdb_breakpoint_here): Also check for Z1 breakpoints.
(uninsert_raw_breakpoint): Don't try to reinsert a disabled
breakpoint. Go through the_target->remove_point instead of
assuming memory breakpoint.
(uninsert_breakpoints_at, uninsert_all_breakpoints): Uninsert
software and hardware breakpoints.
(reinsert_raw_breakpoint): Go through the_target->insert_point
instead of assuming memory breakpoint.
(reinsert_breakpoints_at, reinsert_all_breakpoints): Reinsert
software and hardware breakpoints.
(check_breakpoints, breakpoint_here, breakpoint_inserted_here):
Check both software and hardware breakpoints.
(validate_inserted_breakpoint): Assert the breakpoint is a
software breakpoint. Set the inserted flag to -1 instead of
setting shlib_disabled.
(delete_disabled_breakpoints): Adjust.
(validate_breakpoints): Only validate software breakpoints.
Adjust to inserted flag change.
(check_mem_read, check_mem_write): Skip breakpoint types other
than software breakpoints. Adjust to inserted flag change.
* mem-break.h (enum raw_bkpt_type): New enum.
(raw_breakpoint, struct process_info): Forward declare.
(Z_packet_to_target_hw_bp_type): Delete declaration.
(raw_bkpt_type_to_target_hw_bp_type, Z_packet_to_raw_bkpt_type)
(set_gdb_breakpoint, delete_gdb_breakpoint)
(clear_breakpoint_conditions): New declarations.
(set_gdb_breakpoint_at, clear_gdb_breakpoint_conditions): Delete.
(breakpoint_inserted_here): Update comment.
(add_breakpoint_condition, add_breakpoint_commands): Replace
address parameter with a breakpoint pointer parameter.
(gdb_breakpoint_here): Update comment.
(delete_gdb_breakpoint_at): Delete.
(insert_memory_breakpoint, remove_memory_breakpoint): Declare.
* server.c (process_point_options): Take a struct breakpoint
pointer instead of an address. Adjust.
(process_serial_event) <Z/z packets>: Use set_gdb_breakpoint and
delete_gdb_breakpoint.
* spu-low.c (spu_target_ops): Install NULL as
supports_z_point_type method.
* target.h: Include mem-break.h.
(struct target_ops) <prepare_to_access_memory>: Update comment.
<supports_z_point_type>: New field.
<insert_point, remove_point>: Take an enum raw_bkpt_type argument
instead of a char. Also take a raw breakpoint pointer.
* win32-arm-low.c (the_low_target): Install NULL as
supports_z_point_type.
* win32-i386-low.c (i386_supports_z_point_type): New function.
(i386_insert_point, i386_remove_point): Adjust to new interface.
(the_low_target): Install i386_supports_z_point_type.
* win32-low.c (win32_supports_z_point_type): New function.
(win32_insert_point, win32_remove_point): Adjust to new interface.
(win32_target_ops): Install win32_supports_z_point_type.
* win32-low.h (struct win32_target_ops):
<supports_z_point_type>: New method.
<insert_point, remove_point>: Take an enum raw_bkpt_type argument
instead of a char. Also take a raw breakpoint pointer.
gdb/testsuite/
2014-05-20 Pedro Alves <palves@redhat.com>
* gdb.base/break-idempotent.c: New file.
* gdb.base/break-idempotent.exp: New file.
When using a reverse execution command without execution history, GDB
might end up in a state where replaying has been started but remains
at the current instruction. This state is illegal.
Do not step if there is no execution history to avoid this.
2014-05-20 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_step_thread): Check for empty history.
testsuite/
* gdb.btrace/nohist.exp: New.
Hi,
This patch is to add a new board setting gdb_reverse_timeout, which is
used to set timeout for all gdb.reverse test cases, which are usually
very slow and cause some TIMEOUT failures, for example, on some arm
boards. We have some alternatives to this approach, but I am not
satisfied with them:
- Increase the timeout value. This is the global change, and it may
cause some delay where actual failures happen.
- Set timeout by gdb_reverse_timeout in every gdb.reverse/*.exp.
Then, we have to touch every file under gdb.reverse.
In this patch, we choose a central place to set timeout for all tests
in gdb.reverse, which is convenient.
gdb/testsuite:
2014-05-20 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (gdb_init): Set timeout if test file is under
gdb.reverse directory and gdb_reverse_timeout exists in board
setting.
* README: Document gdb_reverse_timeout.
The argument ARGS of gdb_init is passed from dejagnu is a string, the
test file name. In dejagnu/runtest.exp:
proc runtest { test_file_name } {
....
....
if [info exists tool] {
if { [info procs "${tool}_init"] != "" } {
${tool}_init $test_file_name;
}
}
....
}
but inn default_gdb_init (callee of gdb_init), we have
set gdb_test_file_name [file rootname [file tail [lindex $args 0]]]
In tcl, all actual arguments are combined to a list and assigned to
args. This code here isn't wrong, but unnecessary, because its caller
(proc runtest) only passes one string to it, and IMO, we don't need
such tricky tcl "args".
I doubt that "[lindex $args 0]" is to be backward compatible with old
dejagnu, but dejagnu-1.4 release started to pass $test_file_name to
${too}_init, as I showed above. dejagnu-1.4 was released in 2001, and
it should be old enough. I also tried to check whether gdb testusite
works with dejagnu-1.3 or not, but failed to build dejagnu-1.3 on my
machine. Supposing GDB testsuite requires at least dejagnu-1.4, this
change should be safe.
This patch is update default_gdb_init to treat ARGS as a string instead
of a list. Then, 'args' sounds like a list, and this patch also renames
it by 'test_file_name', to align with dejagnu.
gdb/testsuite:
2014-05-20 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (default_gdb_init): Rename argument 'args' by
'test_file_name'. Treat args as a string instead of a list.
(gdb_init): Rename argument 'args' by 'test_file_name'.
gdb/testsuite/
2014-05-16 Pedro Alves <palves@redhat.com>
* lib/mi-support.exp (mi_expect_stop): On timeout, say "timeout"
instead of "unknown output after running".
Some gdb.dwarf2/*.exp tests copy file1.txt to host via gdb_remote_download
but dw2-filename.exp and dw2-anonymous-func.exp don't do that. Looks like
an oversight in this patch
https://sourceware.org/ml/gdb-patches/2013-08/msg00365.html
There are some fails in remote host testing.
FAIL: gdb.dwarf2/dw2-anonymous-func.exp: list file1.txt
FAIL: gdb.dwarf2/dw2-filename.exp: interpreter-exec mi -file-list-exec-source-files
FAIL: gdb.dwarf2/dw2-filename.exp: info sources
This patch is to invoke gdb_remote_download to copy file1.txt to host
and remote it at the end. This patch fixes these fails above.
gdb/testsuite:
2014-05-16 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-filename.exp: Copy file1.txt to host. Remove
file1.txt from host at the end.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
Since we're not compiling with gcc, we don't know where the
DWO file will ultimately be built. It could be built in
testsuite/gdb.dwarf2/foo (non-parallel mode) or
testsuite/outputs/gdb.dwarf2/foo (parallel mode).
* gdb.dwarf2/fission-reread.S: Remove directory from .dwo file path.
* gdb.dwarf2/fission-reread.exp: Set debug-file-directory before
loading file. Add test for TU lookup.
Passing arguments did not work when use_mi_command was set.
gdb/testsuite/ChangeLog:
2014-05-13 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_run_cmd_full): Set arguments by calling
"-exec-arguments" or "set args" before running the inferior.
The message displayed by gdb is different when the inferior exits with
zero and non-zero values, this fix takes that into account.
gdb/testsuite/ChangeLog:
2014-05-13 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_expect_stop): Expect message for
inferiors that exit with non-zero exit code.
This patch fixes mi-file.exp fails on remote host. First, we can't
assume ${srcdir}/${subdir}/${srcfile} directory exists on remote host,
so this patch changes it to match ${srcfile} only on remote host.
Second, regexp pattern ".*/${srcfile}" isn't friendly to Windows path.
The file name is "basics.c" in my test env and can't match the pattern
due to "/" in it. Remove "/" from the pattern.
gdb/testsuite:
2014-05-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-file.exp (test_file_list_exec_source_file): Don't
match absolute path on remote host.
(test_file_list_exec_source_files): Remove "/" from the
pattern.
After I run test like this,
$ make check RUNTESTFLAGS='--host_board=local-remote-host dw2-basic.exp'
gdb.dwarf2/file1.txt in source tree was removed. In some gdb.dwarf2/*.exp,
file1.txt is copied to host and then removed at the end. However, in
local-remote-host-notty.exp, ${board}_download doesn't copy the file but
return the absolute path of the src file. 'remote_file host delete' at
the end will remove the file in source tree.
This patch is to overwrite ${board}_file, and specially make "delete"
option do nothing. This approach is used in gdbserver-base.exp and
remote-stdio-gdbserver.exp too.
gdb/testsuite:
2014-05-14 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-notty.exp (${board}_file): New
proc.
gdb/Changelog:
* aarch64-tdep.c (aarch64_software_single_step): New function.
(aarch64_gdbarch_init): Handle single stepping of atomic sequences
with aarch64_software_single_step.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-atomic-inst.c: New file.
* gdb.arch/aarch64-atomic-inst.exp: New file.
Hi,
I recently see the fail in dwzbuildid.exp below on some targets,
(gdb) print the_int
No symbol "the_int" in current context.
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: print the_int
Looks the pattern expects to see "No symbol table is loaded", which
is emitted in c-exp.y,
variable: name_not_typename
....
if (msymbol.minsym != NULL)
write_exp_msymbol (pstate, msymbol);
else if (!have_full_symbols () && !have_partial_symbols ())
error (_("No symbol table is loaded. Use the \"file\" command."));
else
error (_("No symbol \"%s\" in current context."),
copy_name ($1.stoken));
it is expected to have no full symbols nor partial symbols, but something
brings full symbols or partial symbols in. I added "maint info symtabs"
and "maint info psymtabs" in dwzbuildid.exp, and it shows symbols are from
ld.so, which has debug information. Then, I reproduce the fail like this,
$ make check RUNTESTFLAGS="CFLAGS_FOR_TARGET='-Wl,-rpath=${glibc_build}:${glibc_build}/math -Wl,--dynamic-linker=${glibc_build}/elf/ld.so' dwzbuildid.exp"
${glibc_build} is the glibc build tree. Debug information is not striped,
so the test fail. However, if I strip debug information from libc.so, libm.so
and ld.so. The test passes.
This patch is to relax the pattern to match the both cases that glibc build
has and has not debug information.
gdb/testsuite:
2014-05-07 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwzbuildid.exp: Match output "No symbol "the_int" in
current context" too.
2014-05-05 Keith Seitz <keiths@redhat.com>
* linespec.c (linespec_parse_basic): Run cleanups if a convenience
variable or history value is successfully parsed.
2014-05-05 Keith Seitz <keiths@redhat.com>
* gdb.linespec/ls-dollar.exp: Add test for linespec
file:convenience_variable.
In gdb.trace/unavailable.exp, an action is defined to collect
struct_b.struct_a.array[2] and struct_b.struct_a.array[100],
struct StructB
{
int d, ef;
StructA struct_a;
int s:1;
static StructA static_struct_a;
const char *string;
};
and the other files are not collected.
When GDB examine traceframe collected by the action, "struct_b" is
unavailable completely, which is wrong.
(gdb) p struct_b
$1 = <unavailable>
When GDB reads 'struct_b', it will request to read memory at struct_b's address
of length LEN. Since struct_b.d is not collected, no 'M' block
includes the first part of the desired range, so tfile_xfer_partial returns
TARGET_XFER_UNAVAILABLE and GDB thinks the whole requested range is unavailable.
In order to fix this problem, in the iteration to 'M' blocks, we record the
lowest address of blocks within the request range. If it has, the requested
range isn't unavailable completely. This applies to ctf too. With this patch
applied, the result looks good and fails in unavailable.exp is fixed.
(gdb) p struct_b
$1 = {d = <unavailable>, ef = <unavailable>, struct_a = {a = <unavailable>, b = <unavailable>, array = {<unavailable>,
<unavailable>, -1431655766, <unavailable> <repeats 97 times>, -1431655766, <unavailable> <repeats 9899 times>}, ptr = <unavailable>, bitfield = <unavailable>}, s = <unavailable>, static static_struct_a = {a = <unavailable>, b = <unavailable>, array = {<unavailable> <repeats 10000 times>}, ptr = <unavailable>,
bitfield = <unavailable>}, string = <unavailable>}
gdb:
2014-05-05 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* tracefile-tfile.c (tfile_xfer_partial): Record the lowest
address of blocks that intersects the requested range. Trim
LEN up to LOW_ADDR_AVAILABLE if read from executable read-only
sections.
* ctf.c (ctf_xfer_partial): Likewise.
gdb/testsuite:
2014-05-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Save
traceframes into tfile and ctf trace files. Read data from
trace file and test collected data.
(gdb_collect_locals_test): Likewise.
(gdb_unavailable_registers_test): Likewise.
(gdb_unavailable_floats): Likewise.
(gdb_collect_globals_test): Likewise.
(top-level): Append "ctf" to trace_file_targets if GDB
supports.
This patch moves traceframe checking code out of traceframe generation,
so that we can generation traceframe once, and do the checking in multiple
times (with target remote, tfile and ctf respectively). This is a
pure refactor, not functional changes in unavailable.exp.
gdb/testsuite:
2014-05-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Move some
code to ...
(gdb_collect_args_test_1): ... it. New proc.
(gdb_collect_locals_test): Move some code to ...
(gdb_collect_locals_test_1): ... it. New proc.
(gdb_unavailable_registers_test): Move some code to ...
(gdb_unavailable_registers_test_1): ... it. New proc.
(gdb_unavailable_floats): Move some code to ...
(gdb_unavailable_floats_1): ... it. New proc.
This commit is actually an update to make the parser in
gdb/stap-probe.c be aware of all the possible prefixes that a probe
argument can have. According to the section "Argument Format" in:
<https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation>
The bitness of the arguments can be 8, 16, 32 or 64 bits, signed or
unsigned. Currently GDB recognizes only 32 and 64-bit arguments.
This commit extends this. It also provides a testcase, only for
x86_64 systems.
gdb/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (enum stap_arg_bitness): New enums to represent 8
and 16-bit signed and unsigned arguments. Update comment.
(stap_parse_probe_arguments): Extend code to handle such
arguments. Use warning instead of complaint to notify about
unrecognized bitness.
gdb/testsuite/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-stap-optional-prefix.S (main): Add several
probes to test for bitness recognition.
* gdb.arch/amd64-stap-optional-prefix.exp
(test_probe_value_without_reg): New procedure.
Add code to test for different kinds of bitness.
This commit fixes PR breakpoints/16889, which is about a bug that
triggers when GDB tries to parse probes whose arguments do not contain
the initial (and optional) "N@" part. For reference sake, the de
facto format is described here:
<https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation>
Anyway, this PR actually uncovered two bugs (related) that were
happening while parsing the arguments. The first one was that the
parser *was* catching *some* arguments that were missing the "N@"
part, but it wasn't correctly setting the argument's type. This was
causing a NULL pointer being dereferenced, ouch...
The second bug uncovered was that the parser was not catching all of
the cases for a probe which did not provide the "N@" part. The fix
for that was to simplify the check that the code was making to
identify non-prefixed probes. The code is simpler and easier to read
now.
I am also providing a testcase for this bug, only for x86_64
architectures.
gdb/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16889
* stap-probe.c (stap_parse_probe_arguments): Simplify
check for non-prefixed probes (i.e., probes whose
arguments do not start with "N@"). Always set the
argument type to a sane value.
gdb/testsuite/
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16889
* gdb.arch/amd64-stap-optional-prefix.S: New file.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
In a test I was writting, I needed a procedure that would connect to
the target, and do "load", or equivalent.
Years ago, boards would override gdb_load to implement that. Then
gdb_reload was added, and gdb_load was relaxed to allow boards avoid
the spawing and connecting to the target. This sped up gdbserver
testing. See
https://www.sourceware.org/ml/gdb-patches/2007-02/msg00318.html.
To actually spawn the target and load the executable on the target
side, gdb_reload was born:
# gdb_reload -- load a file into the target. Called before "running",
# either the first time or after already starting the program once,
# for remote targets. Most files that override gdb_load should now
# override this instead.
proc gdb_reload { } {
# For the benefit of existing configurations, default to gdb_load.
# Specifying no file defaults to the executable currently being
# debugged.
return [gdb_load ""]
}
Note the comment about specifying no file. Indeed looking at
config/sid.exp, or config/monitor.exp, we see examples of that.
However, the default gdb_load itself doesn't handle the case of no
file specified. When passed no file, it just calls gdb_file_cmd with
no file either, which ends up invocing the "file" command with no
argument, which means unloading the file and its symbols... That
means calling gdb_reload when testing against native targets is
broken. We don't see that today because the only call to gdb_reload
that exists today is guarded by target_info exists
gdb,do_reload_on_run.
The native-extended-gdbserver.exp board is likewise broken here. When
[gdb_load ""] is called, the board sets the remote exec-file to "" ...
Tested on x86_64 Fedora 17, native, remote gdbserver and
extended-remote gdbserver.
testsuite/
2014-05-01 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_load): Extend comment. Skip calling
gdb_file_cmd if no file is specified.
* boards/native-extended-gdbserver.exp (gdb_load): Use the
last_loaded_file to set the remote exec-file.
This adds a variant of local-remote-host-notty.exp that forces
pseudo-tty allocation, so that readline/editing is enabled.
$ ssh localhost gdb -q
(gdb) show editing
Editing of command lines as they are typed is off.
(gdb)
vs:
$ ssh -t localhost gdb -q
(gdb) show editing
Editing of command lines as they are typed is on.
We now get, e.g.:
Running ../../../src/gdb/testsuite/gdb.base/filesym.exp ...
PASS: gdb.base/filesym.exp: complete on "filesy"
PASS: gdb.base/filesym.exp: completion list for "filesym"
PASS: gdb.base/filesym.exp: set breakpoint at filesym
gdb/testsuite/
2014-05-01 Pedro Alves <palves@redhat.com>
* boards/local-remote-host.exp: New file.
When testing with this board, stdin is not a tty, and so
readline/editing is disabled:
$ ssh localhost gdb -q
(gdb) show editing
Editing of command lines as they are typed is off.
(gdb)
Rename the file, to make room for a version of this board that forces a pseudo-tty.
gdb/testsuite/
2014-05-01 Pedro Alves <palves@redhat.com>
* boards/local-remote-host.exp: Rename to ...
* boards/local-remote-host-notty.exp: ... this.
This add a testcases that verifies correct handling of dynamicity
for lower bounds of arrays.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_arrayidx: New testcase.
In Dwarf::assemble in dwz.exp, 10 is hard-coded in it,
subprogram {
{name main}
{low_pc main addr}
{high_pc "main + 10" addr}
}
however, the length of main function varies on architectures. The
hard-coded 10 here causes dwz.exp fails on some targets, such as
nios2.
This patch is to add some code to compute the length of function main,
which is similar to what we are doing in entry-values.exp.
gdb/testsuite:
2014-04-26 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Compile main.c to object. Restart GDB
and compute the length of function main. Save it in
$main_length.
(Dwarf::assemble): Use $main_length instead of hard-coded 10.
(top-level): Use gdb_compile to compile objects into
executable and restart GDB. Remove invocation to
prepare_for_testing.
On Linux, we need to explicitly ptrace attach to all lwps of a
process. Because GDB might not be connected yet when an attach is
requested, and thus it may not be possible to activate thread_db, as
that requires access to symbols (IOW, gdbserver --attach), a while ago
we make linux_attach loop over the lwps as listed by /proc/PID/task to
find the lwps to attach to.
linux_attach_lwp_1 has:
...
if (initial)
/* If lwp is the tgid, we handle adding existing threads later.
Otherwise we just add lwp without bothering about any other
threads. */
ptid = ptid_build (lwpid, lwpid, 0);
else
{
/* Note that extracting the pid from the current inferior is
safe, since we're always called in the context of the same
process as this new thread. */
int pid = pid_of (current_inferior);
ptid = ptid_build (pid, lwpid, 0);
}
That "safe" comment referred to linux_attach_lwp being called by
thread-db.c. But this was clearly missed when a new call to
linux_attach_lwp_1 was added to linux_attach. As a result,
current_inferior will be set to some random process, and non-initial
lwps of the second inferior get assigned the pid of the wrong
inferior. E.g., in the case of attaching to two inferiors, for the
second inferior (and so on), non-initial lwps of the second inferior
get assigned the pid of the first inferior. This doesn't trigger on
the first inferior, when current_inferior is NULL, add_thread switches
the current inferior to the newly added thread.
Rather than making linux_attach switch current_inferior temporarily
(thus avoiding further reliance on global state), or making
linux_attach_lwp_1 get the tgid from /proc, which add extra syscalls,
and will be wrong in case of the user having originally attached
directly to a non-tgid lwp, and then that lwp spawning new clones (the
ptid.pid field of further new clones should be the same as the
original lwp's pid, which is not the tgid), we note that callers of
linux_attach_lwp/linux_attach_lwp_1 always have the right pid handy
already, so they can pass it down along with the lwpid.
The only other reason for the "initial" parameter is to error out
instead of warn in case of attach failure, when we're first attaching
to a process. There are only three callers of
linux_attach_lwp/linux_attach_lwp_1, and each wants to print a
different warn/error string, so we can just move the error/warn out of
linux_attach_lwp_1 to the callers, thus getting rid of the "initial"
parameter.
There really nothing gdbserver-specific about attaching to two
threaded processes, so this adds a new test under gdb.multi/. The
test passes cleanly against the native GNU/Linux target, but
fails/triggers the bug against GDBserver (before the patch), with the
native-extended-remote board (as plain remote doesn't support
multi-process).
Tested on x86_64 Fedora 17, with the native-extended-gdbserver board.
gdb/gdbserver/
2014-04-25 Pedro Alves <palves@redhat.com>
PR server/16255
* linux-low.c (linux_attach_fail_reason_string): New function.
(linux_attach_lwp): Delete.
(linux_attach_lwp_1): Rename to ...
(linux_attach_lwp): ... this. Take a ptid instead of a pid as
argument. Remove "initial" parameter. Return int instead of
void. Don't error or warn here.
(linux_attach): Adjust to call linux_attach_lwp. Call error on
failure to attach to the tgid. Call warning when failing to
attach to an lwp.
* linux-low.h (linux_attach_lwp): Take a ptid instead of a pid as
argument. Remove "initial" parameter. Return int instead of
void. Don't error or warn here.
(linux_attach_fail_reason_string): New declaration.
* thread-db.c (attach_thread): Adjust to linux_attach_lwp's
interface change. Use linux_attach_fail_reason_string.
gdb/
2014-04-25 Pedro Alves <palves@redhat.com>
PR server/16255
* common/linux-ptrace.c (linux_ptrace_attach_warnings): Rename to ...
(linux_ptrace_attach_fail_reason): ... this. Remove "warning: "
and newline from built string.
* common/linux-ptrace.h (linux_ptrace_attach_warnings): Rename to ...
(linux_ptrace_attach_fail_reason): ... this.
* linux-nat.c (linux_nat_attach): Adjust to use
linux_ptrace_attach_fail_reason.
gdb/testsuite/
2014-04-25 Simon Marchi <simon.marchi@ericsson.com>
Pedro Alves <palves@redhat.com>
PR server/16255
* gdb.multi/multi-attach.c: New file.
* gdb.multi/multi-attach.exp: New file.
For several RSP packets, there's a corresponding "set remote
foo-packet on/off/auto" command that one can use do bypass
auto-detection of support for the packet or feature. However, I
noticed that setting several of these commands to 'on' or 'off'
doesn't actually have any effect. These are, at least:
set remote breakpoint-commands-packet
set remote conditional-breakpoints-packet
set remote fast-tracepoints-packet
set remote static-tracepoints-packet
set remote install-in-trace-packet
These are commands that control a remote protocol feature that doesn't
have a corresponding regular packet, and because of that we cache the
knowledge of the remote side support as returned by the qSupported
packet in the remote_state object.
E.g., in the case of the 'set remote breakpoint-commands-packet'
command, whether the feature is supported is recorded in the
'breakpoint_commands' field of the remote_state object.
Whether to bypass packet support auto-detection or not is controlled
by the 'detect' field of the corresponding packet's packet_config
structure. That field is the variable associated directly with the
"set remote foo-packet" command. Actual remote stub support for the
packet (or feature) is recorded in the 'support' field of the same
structure.
However, when the user toggles the command, the 'support' field is
also correspondingly updated to PACKET_ENABLE/DISABLE/SUPPORT_UNKNOWN,
discarding the knowledge of whether the target actually supports the
feature. If one toggles back to 'auto', it's no big issue for real
packets, as they'll just end up re-probed the next time they might be
necessary. But features whose support is only reported through
qSupported don't get their corresponding (manually added/maintained)
fields in remote_state objected updated. As we lost the actual status
of the target support for the feature, GDB would need to probe the
qSupported features again, which GDB doesn't do.
But we can avoid that extra traffic, and clean things up, IMO.
Instead of going in that direction, this patch completely decouples
struct packet_config's 'detect' and 'support' fields. E.g., when the
user does "set remote foo-packet off", instead of setting the packet
config's 'support' field to PACKET_DISABLE, the 'support' field is not
touched at all anymore. That is, we end up respecting this simple
table:
| packet_config->detect | packet_config->support | should use packet/feature? |
|-----------------------+------------------------+----------------------------|
| auto | PACKET_ENABLE | PACKET_ENABLE |
| auto | PACKET_DISABLE | PACKET_DISABLE |
| auto | PACKET_UNKNOWN | PACKET_UNKNOWN |
| yes | don't care | PACKET_ENABLE |
| no | don't care | PACKET_DISABLE |
This is implemented by the new packet_support function. With that, we
need to update this pattern throughout:
if (remote_protocol_packets[PACKET_foo].support == PACKET_DISABLE)
to do this instead:
if (packet_support (PACKET_qAttached) == PACKET_DISABLE)
where as mentioned, the packet_support function takes struct
packet_config's 'detect' field into account, like in the table above.
As when the packet is force-disabled or force-enabled, the 'support'
field is just ignored, if the command is set back to auto, we'll
resume respecting whatever the target said it supports. IOW, the end
result is that the 'support' field always represents whether the
target actually supports the packet or not.
After all that, the manually maintained breakpoint_commands and
equivalent fields of struct remote_state can then be eliminated, with
references replaced by checking the result of calling the
packet_support function on the corresponding packet or feature. This
required adding new PACKET_foo enum values for several features that
didn't have it yet. (The patch does not add corresponding "set remote
foo-packet" style commands though, focusing only on bug fixing and
laying the groundwork).
Tested on x86_64 Fedora 17, native GDBserver. The new tests all fail
without this patch.
gdb/
2014-04-25 Pedro Alves <palves@redhat.com>
* remote.c (struct remote_state): Remove multi_process_aware,
non_stop_aware, cond_tracepoints, cond_breakpoints,
breakpoint_commands, fast_tracepoints, static_tracepoints,
install_in_trace, disconnected_tracing,
enable_disable_tracepoints, string_tracing, and
augmented_libraries_svr4_read fields.
(remote_multi_process_p): Move further below in the file.
(struct packet_config): Add comments.
(update_packet_config): Delete function.
(show_packet_config_cmd): Use packet_config_support.
(add_packet_config_cmd): Use NULL as set callback.
(packet_ok): "set remote foo-packet"-style commands no longer
change config->supported -- adjust.
(PACKET_ConditionalTracepoints, PACKET_ConditionalBreakpoints)
(PACKET_BreakpointCommands, PACKET_FastTracepoints)
(PACKET_StaticTracepoints, PACKET_InstallInTrace): Add comments.
(PACKET_QNonStop, PACKET_multiprocess_feature)
(PACKET_EnableDisableTracepoints_feature, PACKET_tracenz_feature)
(PACKET_DisconnectedTracing_feature)
(PACKET_augmented_libraries_svr4_read_feature): New enum values.
(set_remote_protocol_packet_cmd): Delete function.
(packet_config_support, packet_support): New functions.
(set_remote_protocol_Z_packet_cmd): Don't call
update_packet_config.
(remote_query_attached, remote_pass_signals)
(remote_program_signals, remote_threads_info)
(remote_threads_extra_info, remote_start_remote): Use
packet_support.
(remote_start_remote): Use packet_config_support and
packet_support.
(init_all_packet_configs): Set all packets to unknown support,
instead of calling update_packet_config.
(remote_check_symbols): Use packet_support.
(remote_supported_packet): Unconditionally set the packet config's
support status.
(remote_multi_process_feature, remote_non_stop_feature)
(remote_cond_tracepoint_feature, remote_cond_breakpoint_feature)
(remote_breakpoint_commands_feature)
(remote_fast_tracepoint_feature, remote_static_tracepoint_feature)
(remote_install_in_trace_feature)
(remote_disconnected_tracing_feature)
(remote_enable_disable_tracepoint_feature)
(remote_string_tracing_feature)
(remote_augmented_libraries_svr4_read_feature): Delete functions.
(remote_protocol_features): Adjust to use remote_supported_packet
for "augmented-libraries-svr4-read", "multiprocess", "QNonStop",
"ConditionalTracepoints", "ConditionalBreakpoints",
"BreakpointCommands", "FastTracepoints", "StaticTracepoints",
"InstallInTrace", "DisconnectedTracing", "DisconnectedTracing",
"EnableDisableTracepoints", and "tracenz".
(remote_query_supported): Use packet_support.
(remote_open_1): Adjust.
(extended_remote_attach_1): Use packet_support. Switch on the
result of packet_ok instead of checking whether the packet ended
up disabled.
(remote_vcont_resume): Use packet_support.
(remote_resume, remote_stop_ns, fetch_register_using_p)
(remote_prepare_to_store, store_register_using_P)
(check_binary_download, remote_write_bytes): Use packet_support.
(remote_vkill): Use packet_support. Switch on the result of
packet_ok instead of checking whether the packet ended up
disabled.
(extended_remote_supports_disable_randomization): Use
packet_support.
(extended_remote_run): Switch on the result of packet_ok instead
of checking whether the packet ended up disabled.
(remote_insert_breakpoint, remote_remove_breakpoint)
(remote_insert_watchpoint, remote_remove_watchpoint)
(remote_insert_hw_breakpoint, remote_remove_hw_breakpoint): Use
packet_support.
(remote_search_memory): Use packet_config_support.
(remote_get_thread_local_address, remote_get_tib_address)
(remote_hostio_send_command, remote_can_execute_reverse): Use
packet_support.
(remote_supports_cond_tracepoints)
(remote_supports_cond_breakpoints)
(remote_supports_fast_tracepoints)
(remote_supports_static_tracepoints)
(remote_supports_install_in_trace)
(remote_supports_enable_disable_tracepoint)
(remote_supports_string_tracing)
(remote_can_run_breakpoint_commands): Rewrite, checking whether
the packet config says the feature is enabled or disabled.
(remote_download_tracepoint, remote_trace_set_readonly_regions)
(remote_get_trace_status): Use packet_support.
(remote_set_disconnected_tracing): Adjust to check whether the
feature is enabled with packet_support.
(remote_set_trace_buffer_size, remote_use_agent)
(remote_can_use_agent, remote_supports_btrace): Use
packet_support.
(remote_enable_btrace, remote_disable_btrace, remote_read_btrace):
Use packet_config_support.
(remote_augmented_libraries_svr4_read): Rewrite, checking whether
the packet config says the feature is enabled or disabled.
(set_range_stepping): Use packet_support.
gdb/testsuite/
2014-04-25 Pedro Alves <palves@redhat.com>
* gdb.base/cond-eval-mode.exp (warning): Move trailing \r\n to
user.
(top level): Test that "set remote conditional-breakpoints-packet
off" works as intended.
* gdb.base/dprintf.exp: Test that "set remote
breakpoint-commands-packet off" works as intended.
* gdb.trace/change-loc.exp (tracepoint_install_in_trace_disabled):
New function.
(top level): Call it.
* gdb.trace/ftrace.exp (test_fast_tracepoints): Test that "set
remote fast-tracepoints-packet off" works as intended.
* gdb.trace/qtro.exp (gdb_is_target_remote): Moved ...
* lib/gdb.exp (gdb_is_target_remote): ... here.
Pedro Alves
Joel Brobecker
Andy Wingo
Yao Qi
Markus Metzger
Simon Marchi
Simon Marchi
Maciej W. Rozycki
Mark Wielaard
Jan Kratochvil
Doug Evans
Kyle McMartin
Keith Seitz
Sergio Durigan Junior