- If serial->write_prim returns EINTR, ser_bas_write returns it to the
caller. This just looks wrong to me -- part of the output may have
already been sent, and there's no way for the caller to know that,
and thus no way for a caller to handle a partial write correctly.
- While ser-unix.c:ser_unix_read_prim retries on EINTR,
ser-tcp.c:net_read_prim does not.
This commit moves EINTR handling to the ser_base_write and
ser_base_readchar level, so all serial backends (at least those that
use it) end up handling EINTR consistently.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* ser-base.c (fd_event): Retry read_prim on EINTR.
(do_ser_base_readchar): Retry read_prim on EINTR.
(ser_base_write): Retry write_prim on EINTR.
* ser-unix.c (ser_unix_read_prim): Don't retry on EINTR here.
(ser_unix_write_prim): Remove comment.
If the user presses Ctrl-C immediately before target_terminal_inferior
is called and the target is resumed, instead of after, the Ctrl-C ends
up pending in the quit flag until the target next stops.
remote.c has this bit to handle this:
if (!target_is_async_p ())
{
ofunc = signal (SIGINT, sync_remote_interrupt);
/* If the user hit C-c before this packet, or between packets,
pretend that it was hit right here. */
if (check_quit_flag ())
sync_remote_interrupt (SIGINT);
}
But that's only reachable if async is off, while async is on by
default nowadays. It's also obviously not reacheable on native
targets.
This patch generalizes that to all targets.
We can't remove that remote.c bit yet, until we get rid of the sync
SIGINT handler though. That'll be done later in the series.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* remote.c (remote_pass_ctrlc): New function.
(init_remote_ops): Install it.
* target.c (target_terminal_inferior): Pass pending Ctrl-C to the
target.
(target_pass_ctrlc, default_target_pass_ctrlc): New functions.
* target.h (struct target_ops) <to_pass_ctrlc>: New method.
(target_pass_ctrlc, default_target_pass_ctrlc): New declarations.
* target-delegates.c: Regenerate.
In non-stop mode, "interrupt" results in a "stop with no signal",
while in all-stop mode, it results in a remote interrupt request /
stop with SIGINT. This is currently implemented in both the Linux and
remote target backends. Move it to the core code instead, making
target_interrupt specifically always about "Interrupting as if with
Ctrl-C", just like it is documented.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* infcmd.c (interrupt_target_1): Call target_stop is in non-stop
mode.
* linux-nat.c (linux_nat_interrupt): Delete.
(linux_nat_add_target): Don't install linux_nat_interrupt.
* remote.c (remote_interrupt_ns): Change return type to void.
Throw error if interrupting the target is not supported.
(remote_interrupt): Don't call the remote_stop_ns/remote_stop_as.
This call seems pointless. For instance, a SIGINT handler is only
installed later on. And if wasn't, I can't see why we'd want to lose
a Ctrl-C request.
Getting rid of this allows getting rid of clear_quit_flag.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* main.c (captured_main): Don't clear the quit flag.
I think this is reminiscent of the time when a longjmp would always
jump to the top level. Nowaways code that throw exceptions other than
a quit, which may even be caught and handled without reaching the top
level. Certainly such exceptions shouldn't clear an interrupt
request...
(We also need to get rid of prepare_to_throw_exception in order to be
able to just do "throw ex;" in C++.)
One could argue that we should clear the quit flag when we throw a
quit from the SIGINT handler, when immediate_quit is in effect, to
handle a race, here:
immediate_quit++;
QUIT;
... that's the usual pattern code must use when enabling
immediate_quit. The QUIT is there to catch the case of Ctrl-C having
already been pressed before immediate_quit was enabled. However, this
can happen:
immediate_quit++;
<< Ctrl-C pressed here too.
QUIT;
And in that case, if the quit flag was already set, it'll stay set
even after throwing a quit from the SIGINT handler. The end result is
a double quit. But OTOH, the user did press Ctrl-C two times. Since
I'm getting rid of immediate_quit, I'm not bothering with this.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* exceptions.c (prepare_to_throw_exception): Don't clear the quit
flag.
This just looks totally wrong to me, for completetly discarding a
user-requested Ctrl-C. I can't think of why we'd want do this here.
Actually, I digged the history, and found out that this has been here
since at least 7b4ac7e1ed (gdb-2.4, the initial revision, 1988), at
a time were we had a top level setjmp/longjmp, long before that got
wrapped in throw_exception and friends, and this code was in an
explicit loop, with the quit_flag cleared on every iteration, before
executing a command...
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* event-top.c (command_handler): Don't call clear_quit_flag.
Obviously not necessary since check_quit_flag clears the flag as side
effect.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* remote-sim.c (gdb_os_poll_quit): Don't call clear_quit_flag.
* remote.c (remote_wait_as): Don't call clear_quit_flag.
Now that we have an abstract for wakeable events, use it instead of a
(heavier) serial pipe.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* python/python.c: Include "ser-event.h".
(gdbpy_event_fds): Delete.
(gdbpy_serial_event): New.
(gdbpy_run_events): Change prototype. Use serial_event_clear
instead of serial_readchar.
(gdbpy_post_event): Use serial_event_set instead of serial_write.
(gdbpy_initialize_events): Use make_serial_event instead of
serial_pipe.
We have places where we call a blocking gdb_select expecting that a
Ctrl-C will unblock it. However, if the Ctrl-C is pressed just before
gdb_select, the SIGINT handler runs before gdb_select, and thus
gdb_select won't return.
For example gdb_readline_no_editing:
QUIT;
/* Wait until at least one byte of data is available. Control-C
can interrupt gdb_select, but not fgetc. */
FD_ZERO (&readfds);
FD_SET (fd, &readfds);
if (gdb_select (fd + 1, &readfds, NULL, NULL, NULL) == -1)
and stdio_file_read:
/* For the benefit of Windows, call gdb_select before reading from
the file. Wait until at least one byte of data is available.
Control-C can interrupt gdb_select, but not read. */
{
fd_set readfds;
FD_ZERO (&readfds);
FD_SET (stdio->fd, &readfds);
if (gdb_select (stdio->fd + 1, &readfds, NULL, NULL, NULL) == -1)
return -1;
}
return read (stdio->fd, buf, length_buf);
This is a race classically fixed with either the self-pipe trick, or
by blocking SIGINT and then using pselect instead of select.
Blocking SIGINT most of the time would mean that check_quit_flag (and
thus QUIT) would need to do a syscall every time it is called, which
sounds best avoided, since QUIT is called in many loops. Thus we take
the self-pipe trick route (wrapped in a serial event).
Instead of having all places that need this manually add an extra file
descriptor to the set of gdb_select's watched file descriptors, we
introduce a wrapper, interruptible_select, that does that.
The Windows version of gdb_select actually does not suffer from this,
because mingw-hdep.c:gdb_call_async_signal_handler sets a Windows
event that gdb_select always waits on. So this patch can be seen as
generalization of that technique. We can't remove that extra event
from mingw-hdep.c until we get rid of immediate_quit though.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* defs.h: Extend QUIT-related comments to mention
interruptible_select.
(quit_serial_event_set, quit_serial_event_clear): Declare.
* event-top.c: Include "ser-event.h" and "gdb_select.h".
(quit_serial_event): New global.
(async_init_signals): Make quit_serial_event.
(quit_serial_event_set, quit_serial_event_clear)
(quit_serial_event_fd, interruptible_select): New functions.
* extension.c (set_quit_flag): Set the quit serial event.
(check_quit_flag): Clear the quit serial event.
* gdb_select.h (interruptible_select): New declaration.
* guile/scm-ports.c (ioscm_input_waiting): Use
interruptible_select instead of gdb_select.
* top.c (gdb_readline_no_editing): Likewise.
* ui-file.c (stdio_file_read): Likewise.
GDB's core signal handling suffers from a classical signal handler /
mainline code race:
int
gdb_do_one_event (void)
{
...
/* First let's see if there are any asynchronous signal handlers
that are ready. These would be the result of invoking any of the
signal handlers. */
if (invoke_async_signal_handlers ())
return 1;
...
/* Block waiting for a new event. (...). */
if (gdb_wait_for_event (1) < 0)
return -1;
...
}
If a signal is delivered while gdb is blocked in the poll/select
inside gdb_wait_for_event, then the select/poll breaks with EINTR,
we'll loop back around and call invoke_async_signal_handlers.
However, if the signal handler runs between
invoke_async_signal_handlers and gdb_wait_for_event,
gdb_wait_for_event will block, until the next unrelated event...
The fix is to a struct serial_event, and register it in the set of
files that select/poll in gdb_wait_for_event waits on. The signal
handlers that defer work to invoke_async_signal_handlers call
mark_async_signal_handler, which is adjusted to also set the new
serial event in addition to setting a flag, and is thus now is
garanteed to immediately unblock the next gdb_select/poll call, up
until invoke_async_signal_handlers is called and the event is cleared.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* event-loop.c: Include "ser-event.h".
(async_signal_handlers_serial_event): New global.
(async_signals_handler, initialize_async_signal_handlers): New
functions.
(mark_async_signal_handler): Set
async_signal_handlers_serial_event.
(invoke_async_signal_handlers): Clear
async_signal_handlers_serial_event.
* event-top.c (async_init_signals): Call
initialize_async_signal_handlers.
This patch adds a new "event" struct serial type, that is an
abstraction specifically for waking up blocking waits/selects,
implemented on top of a pipe on POSIX, and on top of a native Windows
event (CreateEvent, etc.) on Windows.
This will be used to plug signal handler / mainline code races.
For example, GDB can indefinitely delay handling a quit request if the
user presses Ctrl-C between the last QUIT call and the next (blocking)
gdb_select call in the event loop:
QUIT;
<<< press ctrl-c here and end up blocked in gdb_select
indefinitely.
gdb_select (...); // whoops, SIGINT was already handled, no EINTR.
A global alone (either the quit flag, or the "ready" flag of the async
signal handlers in the event loop) is not sufficient.
To plug races such as these on POSIX systems, we have to register some
waitable file descriptor in the set of files gdb_select waits on, and
write to it from the signal handler. This is classically a pipe, and
the pattern called the self-pipe trick. On Linux, it could be a more
efficient eventfd instead, but I'm sticking with a pipe for
simplifity, as we need it for portability anyway.
(Alternatively, we could use pselect/ppoll, and block signals until
the pselect. The latter is not a design I think GDB could use,
because we want the QUIT macro to be super cheap, as it is used in
loops. Plus, Windows.)
This is a "struct serial" because Windows's gdb_select relies on that.
Windows's gdb_select, our "select" replacement, knows how to wait on
all kinds of handles (regular files, pipes, sockets, console, etc.)
unlike the native Windows "select" function, which can only wait on
sockets. Each file descriptor for a "serial" type that is not
normally waitable with WaitForMultipleObjects must have a
corresponding struct serial instance. gdb_select then internally
looks up the struct serial instance that wraps each file descriptor,
and asks it for the corresponding Windows waitable handle.
We could use serial_pipe() to create a "struct serial"-wrapped pipe
that is usable everywhere, including Windows. That's what currently
python/python.c uses for cross-thread posting of events.
However, serial_write and serial_readchar are not designed to be
async-signal-safe on POSIX hosts. It's easier to bypass those when
setting/clearing the event source.
And writing and a serial pipe is a bit heavy weight on Windows.
gdb_select requires an extra thread to wait on the pipe and several
Windows events, when a single manual-reset Windows event, with no
extra thread is sufficient.
The intended usage is simply:
- Call make_serial_event to create a serial event object.
- From the signal handler call serial_event_set to set the event.
- From mainline code, have select/poll wait for serial_event_fd(), in
addition to whatever other files you're about to wait for.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* Makefile.in (SFILES): Add ser-event.c.
(HFILES_NO_SRCDIR): Add ser-event.h.
(COMMON_OBS): Add ser-event.o.
* ser-event.c, ser-event.h: New files.
* serial.c (new_serial): New function, factored out from
(serial_fdopen_ops): ... this.
(serial_open_ops_1): New function, factored out from
(serial_open): ... this.
(serial_open_ops): New function.
* serial.h (struct serial): Forware declare.
(serial_open_ops): New declaration.
Not used by anything.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* serial.c (serial_open, serial_fdopen_ops, do_serial_close):
Remove references to name.
* serial.h (struct serial) <name>: Delete.
This code installs a custom signal handler that throws a quit
exception if remote_fio_no_longjmp is not set.
AFAICS, the only real reason for this might have been to unblock the
ui_file_read call, in remote_fileio_func_read. But ever since:
2009-11-13 Daniel Jacobowitz <dan@codesourcery.com>
* ui-file.c (stdio_file_read): Call gdb_select before read.
at:
https://sourceware.org/ml/gdb-patches/2009-11/msg00321.html
that call is interruptible.
This is not only useful for switching to native C++ exceptions, but
AFAICS, also fixes a potential mess up of the remote protocol
connection, since there are target_read_memory calls done while
remote_fio_no_longjmp is clear. If the user presses ctrl-c while GDB
is sending or receiving a packet, we'll stop the communication
immediately, at a point where it isn't safe.
gdbserver doesn't support the File I/O remote protocol extension so I
can't test this.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* remote-fileio.c (sigint_fileio_token, remote_fio_no_longjmp):
Delete.
(async_remote_fileio_interrupt): Delete.
(remote_fileio_ctrl_c_signal_handler): Don't call the async signal
handler. Instead just always set the ctrl_c flag.
(remote_fileio_reply): Clear remote_fio_ctrl_c_flag before
re-enabling the SIGINT handler.
(remote_fileio_func_open, remote_fileio_func_close)
(remote_fileio_func_read, remote_fileio_func_write)
(remote_fileio_func_lseek, remote_fileio_func_rename)
(remote_fileio_func_unlink, remote_fileio_func_stat)
(remote_fileio_func_fstat, remote_fileio_func_gettimeofday)
(remote_fileio_func_isatty, remote_fileio_func_system)
(remote_fileio_request): Remove references to
remote_fio_no_longjmp.
(initialize_remote_fileio): Don't create an async signal handler.
immediate_quit used to be necessary back when prompt_for_continue used
blocking fread, but nowadays it uses gdb_readline_wrapper, which is
implemented in terms of a nested event loop, which already knows how
to react to SIGINT:
#0 throw_it (reason=RETURN_QUIT, error=GDB_NO_ERROR, fmt=0x9d6d7e "Quit", ap=0x7fffffffcb88)
at .../src/gdb/common/common-exceptions.c:324
#1 0x00000000007bab5d in throw_vquit (fmt=0x9d6d7e "Quit", ap=0x7fffffffcb88) at .../src/gdb/common/common-exceptions.c:366
#2 0x00000000007bac9f in throw_quit (fmt=0x9d6d7e "Quit") at .../src/gdb/common/common-exceptions.c:385
#3 0x0000000000773a2d in quit () at .../src/gdb/utils.c:1039
#4 0x000000000065d81b in async_request_quit (arg=0x0) at .../src/gdb/event-top.c:893
#5 0x000000000065c27b in invoke_async_signal_handlers () at .../src/gdb/event-loop.c:949
#6 0x000000000065aeef in gdb_do_one_event () at .../src/gdb/event-loop.c:280
#7 0x0000000000770838 in gdb_readline_wrapper (prompt=0x7fffffffcd40 "---Type <return> to continue, or q <return> to quit---")
at .../src/gdb/top.c:873
The need for the QUIT in stdin_event_handler is then exposed by the
gdb.base/double-prompt-target-event-error.exp test, which has:
# We're now stopped in a pagination query while handling a
# target event (printing where the program stopped). Quitting
# the pagination should result in only one prompt being
# output.
send_gdb "\003p 1\n"
Without that change we'd get:
Continuing.
---Type <return> to continue, or q <return> to quit---PASS: gdb.base/double-prompt-target-event-error.exp: ctrlc target event: continue: continue to pagination
^CpQuit
(gdb) 1
Undefined command: "1". Try "help".
(gdb) PASS: gdb.base/double-prompt-target-event-error.exp: ctrlc target event: continue: first prompt
ERROR: Undefined command "".
UNRESOLVED: gdb.base/double-prompt-target-event-error.exp: ctrlc target event: continue: no double prompt
Vs:
Continuing.
---Type <return> to continue, or q <return> to quit---PASS: gdb.base/double-prompt-target-event-error.exp: ctrlc target event: continue: continue to pagination
^CQuit
(gdb) p 1
$1 = 1
(gdb) PASS: gdb.base/double-prompt-target-event-error.exp: ctrlc target event: continue: first prompt
PASS: gdb.base/double-prompt-target-event-error.exp: ctrlc target event: continue: no double prompt
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* event-top.c (stdin_event_handler): Call QUIT;
(prompt_for_continue): Don't run with immediate_quit set.
As can be seen in the tui_redisplay_readline comment:
"The command could call prompt_for_continue and we must not restore
SingleKey so that the prompt and normal keymap are used."
immediate_quit is being used as proxy for "secondary prompt".
We have a better predicate nowadays, so use it.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* tui/tui-io.c (tui_redisplay_readline): Check
gdb_in_secondary_prompt_p instead of immediate_quit.
* tui/tui.c: Include top.h.
(tui_rl_startup_hook): Check gdb_in_secondary_prompt_p instead of
immediate_quit.
read_command_line is the only caller, and here we can assume we're
reading a regular file, not stdin.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* top.c (read_command_file): Inline command_loop here.
(command_loop): Delete.
AFAICS, immediate_quit was only needed here nowdays to be able to
interrupt gdb_readline_no_editing.
command_line_input can also take the gdb_readline_wrapper path, but
since that is built on top of the event loop (gdb_select / poll and
asynchronous signal handlers), it can be interrupted.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* top.c: Include "gdb_select.h".
(gdb_readline_no_editing): Wait for input with gdb_select instead
of blocking in fgetc.
(command_line_input): Don't set immediate_quit.
There are a few small changes needed to make it work with a real remote
target.
- Remove the [is_remote target] check.
- Remove soname setting when building the lib, it's done by default now
anyway.
- In the compilation of the executable, pass the shared lib using the
shlib option, so that RPATH is set.
- Download the program to the target using gdb_remote_download, and
record the remote path. Remove loading of the program using
gdb_load_shlibs, which was not really appropriate anyway.
- Run the remote path through readlink (see comment in the code).
- Start gdbserver with the remote path.
Also, don't set executable and objfile variables, as they are unused.
Tested with native, native-gdbserver, native-extended-gdbserver, and a
remote gdbserver.
gdb/testsuite/ChangeLog:
* gdb.server/solib-list.exp: Remove is_remote check.
Pass shlib= to gdb_compile. Don't link shared library with
-soname. Call gdb_remote_download instead of gdb_load_shlibs.
Run binary filename through "readlink -f" on the target.
Commit 7817ea4614 (Improve gdb_remote_download, remove gdb_download)
caused:
FAIL: gdb.server/solib-list.exp: non-stop 0: target extended-remote (timeout)
FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program is no longer running)
FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar
FAIL: gdb.server/solib-list.exp: non-stop 1: target extended-remote (timeout)
FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program is no longer running)
FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar
gdb.log shows:
system interpreter is: /lib64/ld-linux-x86-64.so.2
...
spawn ../gdbserver/gdbserver --once :2347 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
Process /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 created; pid = 18637
Cannot exec /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2: No such file or directory.
...
The test copied the interpreter to the outputs directory, however
ld-linux-x86-64.so.2 is a relative symlink that when copied points
nowhere:
$ ls -l testsuite/outputs/gdb.server/solib-list/
total 52
-rwxrwxr-x. 1 pedro pedro 13450 Apr 7 10:52 gdb.log
-rw-rw-r--. 1 pedro pedro 1512 Apr 7 10:52 gdb.sum
lrwxrwxrwx. 1 pedro pedro 10 Apr 7 11:39 ld-linux-x86-64.so.2 -> ld-2.22.so
-rwxrwxr-x. 1 pedro pedro 9464 Apr 7 11:39 solib-list
-rw-rw-r--. 1 pedro pedro 3472 Apr 7 11:39 solib-list-lib.c.o
-rw-rw-r--. 1 pedro pedro 2760 Apr 7 11:39 solib-list.o
-rwxrwxr-x. 1 pedro pedro 9232 Apr 7 11:39 solib-list.so
The copying comes from gdbserver_spawn ->
gdbserver_download_current_prog -> gdb_remote_download.
There's actually no need to download the interpreter to the target -
it's part of the target system/environment. So fix this by making the
test just not use gdb_load (and gdb_file_cmd as consequence) at all,
and instead pass the interpreter filename to gdbserver as an argument.
gdb/testsuite/ChangeLog:
2016-04-08 Pedro Alves <palves@redhat.com>
* gdb.server/solib-list.exp: Don't use gdb_load. Instead pass the
interpreter filename as argument to gdbserver_spawn.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Return empty if $last_loaded_file does not exist.
I did a quick pass over value.c and value.h and made some of the accessor methods'
pass-by-reference parameters const-correct. Besides the obvious benefits, this is
required if we want to use them on values that are already declared as const
(such as the parameters to lval_funcs).
There's probably a lot more stuff that can be made const, here and elsewhere.
gdb/ChangeLog:
2016-04-08 Martin Galvan <martin.galvan@tallertechnologies.com>
* value.c (value_next): Make pass-by-reference parameters const-correct.
(value_parent): Likewise.
(value_enclosing_type): Likewise.
(value_lazy): Likewise.
(value_stack): Likewise.
(value_embedded_offset): Likewise.
(value_pointed_to_offset): Likewise.
(value_raw_address): Likewise.
(deprecated_value_modifiable): Likewise.
(value_free_to_mark): Likewise.
(value_release_to_mark): Likewise.
(internalvar_name): Likewise.
(readjust_indirect_value_type): Likewise.
(value_initialized): Likewise.
* value.h (value_next): Likewise.
(value_parent): Likewise.
(value_enclosing_type): Likewise.
(value_lazy): Likewise.
(value_stack): Likewise.
(value_embedded_offset): Likewise.
(value_pointed_to_offset): Likewise.
(value_raw_address): Likewise.
(deprecated_value_modifiable): Likewise.
(value_free_to_mark): Likewise.
(value_release_to_mark): Likewise.
(internalvar_name): Likewise.
(readjust_indirect_value_type): Likewise.
(value_initialized): Likewise.
on CentOS-7.2 I get
Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit.exp ...
FAIL: gdb.base/jit.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 1
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: detach (the program is no longer running)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: attach
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 0
FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit-so.exp ...
FAIL: gdb.base/jit-so.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit-so.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
since:
85af34ee0211eedf8d30a5c44dfc59dddf8b512a is the first bad commit
commit 85af34ee0211eedf8d30a5c44dfc59dddf8b512a
Author: Pedro Alves <palves@redhat.com>
Date: Thu Mar 31 19:28:47 2016 +0100
Add regression test for PR gdb/19858 (JIT code registration on attach)
The compiled code's .debug_line is wrong (for the simplistic approach of GDB
to put a breakpoint on the first address belonging to that source line) and so
GDB misses the breakpoint at the last line:
WAIT_FOR_GDB; return 0; /* gdb break here 2 */
Most of the patch is just about reindentation, no changes there.
gdb/testsuite/ChangeLog
2016-04-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix compatibility with gcc-4.8.5-4.el7.x86_64.
* gdb.base/jit-main.c: Use exit after usage.
$ GDBHISTFILE=/tmp/gdbhistfile runtest gdb.base/gdbhistsize-history.exp gdb.base/gdbinit-history.exp
Running ./gdb.base/gdbinit-history.exp ...
FAIL: gdb.base/gdbinit-history.exp: home=gdbinit-history/unlimited gdbhistsize=1000: show commands
FAIL: gdb.base/gdbinit-history.exp: home=gdbinit-history/unlimited gdbhistsize=foo: show commands
Running ./gdb.base/gdbhistsize-history.exp ...
FAIL: gdb.base/gdbhistsize-history.exp: histsize=: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=20: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize= 20 : show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=-5: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=not_an_integer: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=10zab: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=-5ab: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=99999999999999999999999999999999999: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=50: show commands
This happens for my setup due to my:
$ grep GDB ~/.bashrc
export GDBHISTFILE="$HOME/.gdb_history"
gdb/testsuite/ChangeLog
2016-04-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/gdbhistsize-history.exp: Save and unset GDBHISTFILE and
GDBHISTSIZE prior to the tests.
* gdb.base/gdbinit-history.exp: Likewise.
Commit 6e774b13c3 (Make ftrace tests work with remote targets) made
a few gdb.compile/compile.exp tests disappear:
-PASS: gdb.compile/compile.exp: call shared library function
-PASS: gdb.compile/compile.exp: expect 1
-PASS: gdb.compile/compile.exp: modify shared library variable
-PASS: gdb.compile/compile.exp: expect 15
This is because the test uses ldflags instead of using the shlib
option, so it misses linking with -rpath, resulting in:
(gdb) run
Starting program: .../compile/compile-shlib
.../compile/compile-shlib: error while loading shared libraries: compile-shlib.so: cannot open shared object file: No such file or directory
[Inferior 1 (process 18014) exited with code 0177]
We were missing a gdb_load_shlibs call, which is needed for remote
testing.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.compile/compile.exp: Use gdb_compile with "shlib=" option
instead of build_executable. Use gdb_load_shlibs.
I see the following fail on aarch64-linux
break void_func
Breakpoint 2 at 0x4007a0: file gdb/testsuite/gdb.reverse/finish-reverse.c, line 44.
(gdb) PASS: gdb.reverse/finish-reverse-bkpt.exp: set breakpoint on void_func
continue
Continuing.
Breakpoint 2, void_func () at gdb/testsuite/gdb.reverse/finish-reverse.c:44^M
44 void_test = 1; /* VOID FUNC */^M
(gdb) PASS: gdb.reverse/finish-reverse-bkpt.exp: continue to breakpoint: void_func
break *void_func^M
Note: breakpoint 2 also set at pc 0x4007a0.^M
Breakpoint 3 at 0x4007a0: file gdb/testsuite/gdb.reverse/finish-reverse.c, line 44.
(gdb) PASS: gdb.reverse/finish-reverse-bkpt.exp: set breakpoint at void_func's entry
reverse-finish^M
Run back to call of #0 void_func () at gdb/testsuite/gdb.reverse/finish-reverse.c:44
main (argc=1, argv=0x7ffffffb78) at gdb/testsuite/gdb.reverse/finish-reverse.c:98
98 void_func (); /* call to void_func */^M
(gdb) FAIL: gdb.reverse/finish-reverse-bkpt.exp: reverse-finish from void_func trips breakpoint at entry
The test assumes that brekapoints on "void_func" and "*void_func" are
set on different places because of function prologue. However, on
aarch64-linux, there is no prologue in void_func, so two breakpoints
are set at the same place (0x4007a0).
(gdb) disassemble void_func
Dump of assembler code for function void_func:
0x00000000004007a0 <+0>: adrp x0, 0x410000
0x00000000004007a4 <+4>: add x0, x0, #0xc14
0x00000000004007a8 <+8>: mov w1, #0x1
0x00000000004007ac <+12>: str w1, [x0]
0x00000000004007b0 <+16>: ret
The fix to this problem is to single step forward before setting
breakpoint on *void_func.
gdb/testsuite:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/finish-reverse-bkpt.exp: Use temporary breakpoint.
Execute "si" command.
I see the fail on aarch64-linux,
(gdb) reverse-next
Breakpoint 2, callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:26^M
26 myglob++; return 0; /* ARRIVED IN CALLEE */
(gdb) FAIL: gdb.reverse/next-reverse-bkpt-over-sr.exp: reverse-next over call trips user breakpoint at function entry
The test expects program stops at line 25, but program stops at line 26.
(gdb) maintenance info line-table
objfile: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.reverse/next-reverse-bkpt-over-sr/next-reverse-bkpt-over-sr ((struct objfile *) 0x613000002880)
compunit_symtab: ((struct compunit_symtab *) 0x621000121760)
symtab: /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c ((struct symtab *) 0x6210001217e0)
linetable: ((struct linetable *) 0x6210001520d0):
INDEX LINE ADDRESS
0 25 0x0000000000400890
1 26 0x0000000000400890
2 27 0x00000000004008b0
(gdb) disassemble callee
Dump of assembler code for function callee:
0x0000000000400890 <+0>: adrp x0, 0x410000
0x0000000000400894 <+4>: add x0, x0, #0xcac
the line-table show that the first instruction of function callee is
mapped line 25 and 26. I am not sure the line-table is correct, but
it is not the point of this test. The goal of this test is to test
program hits the breakpoint on the first instruction of function after
'reverse-next', so I change this test to expect the breakpoint number
the program hits.
gdb/testsuite:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/next-reverse-bkpt-over-sr.exp: Match the breakpoint
number instead of the comments on some line.
Some test fails in gdb.reverse/break-reverse.exp on arm-linux lead me
seeing the following error message,
continue^M
Continuing.^M
Cannot remove breakpoints because program is no longer writable.^M
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Further execution is probably impossible.^M
^M
Breakpoint 3, bar () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/break-reverse.c:22^M
22 xyz = 2; /* break in bar */^M
(gdb) PASS: gdb.reverse/break-reverse.exp: continue to breakpoint: bar backward
this is caused by two entries in record_full_breakpoints, and their addr
is the same, but in_target_beneath is different.
during the record, we do continue,
Continuing.
infrun: clear_proceed_status_thread (Thread 13772.13772)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 13772.13772] for step-over
infrun: skipping breakpoint: stepping past insn at: 0x8620
Sending packet: $Z0,85f4,4#1d...Packet received: OK <----
.....
Sending packet: $vCont;c#a8...infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
Packet received: T05swbreak:;0b:9cf5ffbe;0d:9cf5ffbe;0f:f4850000;thread:p35cc.35cc;core:1;
Sending packet: $Z0,85f4,4#1d...Packet received: OK <-----
....
Sending packet: $z0,85f4,4#3d...Packet received: OK <-----
we can see breakpoint on 0x85f4 are inserted *twice*, but only removed
once. That is fine to remote target, because Z/z packets are
idempotent, but there is a leftover in record_full_breakpoints
in record-full target. The flow can be described as below,
record_full_breakpoints remote target
-----------------------------------------------------------------------
forward execution, continue, in_target_beneath 1 breakpoint inserted
insert breakpoints on 0x85f4 in_target_beneath 1
twice
program stops,
remove breakpoint on 0x85f4 in_target_beneath 1 breakpoint removed
reverse execution, continue, in_target_beneath 1 none is requested
insert breakpoints on 0x85f4, in_target_beneath 0
program stops,
remote breakpoint on 0x85f4, in_target_beneath 0 request to remove,
but GDBserver
doesn't know
now, the question is why breakoint on 0x85f4 is inserted twice? One
is the normal breakpoint, and the other is the single step breakpoint.
GDB inserts single step breakpoint to do single step. When program
stops at 0x85f4, both of them are set on 0x85f4, and GDB deletes
single step breakpoint, so in update_global_location_list, this
breakpoint location is no longer found, GDB call
force_breakpoint_reinsertion to mark it condition_updated, and insert
it again.
The reason force_breakpoint_reinsertion is called to update the
conditions in the target side, because the conditions may be
changed. My original fix is to not call force_breakpoint_reinsertion
if OLD_LOC->cond is NULL, but it is not correct if another location
on the same address has condition, GDB doesn't produce condition for
target side, but GDB should do.
Then, I change my mind back to make record-full handling breakpoint
idempotent, to align with remote target. Before insert a new entry
into record_full_breakpoints, look for existing one on the same
address first. I also add an assert on
"bp->in_target_beneath == in_target_beneath", to be safer.
gdb:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* record-full.c (record_full_insert_breakpoint): Return
early if entry on the address is found in
record_full_breakpoints.
I notice that bp_tgt won't be fully initialized if to_insert_breakpoint
isn't called in record_full_insert_breakpoint, and bp_tgt->reqstd_address
is zero, so an entry is added to record_full_breakpoints, but its address
is zero, which is wrong. This patch is to call gdbarch_breakpoint_from_pc
in the else branch to set bp_tgt->reqstd_address and bp_tgt->placed_size.
gdb:
2016-04-07 Yao Qi <yao.qi@linaro.org>
* record-full.c (record_full_insert_breakpoint): Set
bp_tgt->reqstd_address and bp_tgt->placed_size.
This patch eliminates an error thrown when accessing the value of a
pointer to a structure where the pointer has been optimized out and
'set print object' is 'on'. The error shows up as the rather ugly
value of the pointer variable in Eclipse.
If 'set print object' is 'on', GDB tries to determine the actual
(derived) type of the object rather than the declared type, which
requires dereferencing the pointer, which in this cases throws an
error because the pointer has been optimized out.
The fix is to simply ignore the 'print object on' setting for
pointers or references to structures when they have been optimized
out. This means we just get the declared type instead of the actual
type, because in this case that's the best that we can do.
To implement the fix, value_optimized_out was modified so that it
no longer throws an error when it fails to fetch the specified
value. Instead, it just checks value->optimized_out. If we can't
definitively say that the value is optimized out, then we assume
it is not.
gdb/ChangeLog:
2016-04-06 Don Breazeal <donb@codesourcery.com>
* value.c (value_actual_type): Don't try to get rtti type
of the value if it has been optimized out.
(value_optimized_out): If a memory access error occurs,
just check vaue->optimized_out.
This patch implements a test that ensures that with "set print object
on", -var-create returns "<optimized out>" for an optimized out pointer
to structure, rather than throwing an error, while also ensuring that
any attempt to dereference the pointer *will* throw an error.
It uses the dwarf assembler to construct the appropriate debug info
to represent a pointer-to-struct in the program as optimized out,
and then accesses that pointer in various ways. The test uses both
the console interpreter and the MI interpreter.
gdb/testsuite/ChangeLog:
2016-04-06 Don Breazeal <donb@codesourcery.com>
* gdb.dwarf2/dw2-opt-structptr.c: New test program.
* gdb.dwarf2/dw2-opt-structptr.exp: New test script.
Following, commit
6e774b13c3 Make ftrace tests work with remote targets
the test gdb.threads/dlopen-libpthread.exp started to fail with:
ERROR: error copying "/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.threads/dlopen-libpthread.so": no such file or directory
This is because the library path is not computed using
standard_output_file, so we try to gdb_load_shlibs an unexisting file.
gdb/testsuite/ChangeLog:
* gdb.threads/dlopen-libpthread.exp: Set binfile_lib using
standard_output_file. Remove unused binfile variable.
It broke the compatibility with gdbserver-7.6 due to:
warning: remote target does not support file transfer, attempting to access files from local filesystem.
gdb/ChangeLog
2016-04-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Revert the previous commit adding unknown_v_replies_ok.
With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is supported
...
Sending packet: $vFile:setfs:104#24...Packet received: OK
"target:/root/redhat/threadit": could not open as an executable file: Invalid argument
GDB documentation says:
The valid responses to Host I/O packets are:
An empty response indicates that this operation is not recognized.
This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by:
commit e7f0d979dd
Author: Yao Qi <yao@codesourcery.com>
Date: Tue Dec 10 21:59:20 2013 +0800
Fix a bug in matching notifications.
Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
2013-12-10 Yao Qi <yao@codesourcery.com>
* notif.c (handle_notif_ack): Return 0 if no notification
matches.
with unpatched old FSF gdbserver and patched FSF GDB HEAD:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is NOT supported
...
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0
gdb/ChangeLog
2016-04-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (struct remote_state): New field unknown_v_replies_ok.
(packet_config_support): Read it.
(remote_start_remote): Set it.
currently:
$ gdbserver-7.9 :1234 true &
$ gdb -q -ex 'target remote :1234' # that -q is not relevant here
Remote debugging using :1234
warning: Could not load vsyscall page because no executable was specified
try using the "file" command first.
0x00007ffff7ddcc80 in ?? ()
(gdb) b main
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) _
Provide more suggestive message to use the "file" command.
gdb/ChangeLog
2016-04-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* exec.c (exec_file_locate_attach): Print warning for unsupported
target_pid_to_exec_file.
* symfile-mem.c (add_vsyscall_page): Remove the "file" command
message part.
Starting with this commit:
commit e7ea3ec7c6
Author: Catalin Udma <catalin.udma@freescale.com>
Date: Mon Feb 29 16:16:19 2016 +0200
python: Use console format for output of gdb.execute command
the python script would use console format for gdb.execute output.
This patch fixes py-mi-objfile to expect the console format when is
checking for gdb.execute printing.
gdb/testsuite/ChangeLog:
2016-04-05 Catalin Udma <catalin.udma@freescale.com>
* gdb.python/py-mi-objfile-gdb.py: Use "list main" command.
* gdb.python/py-mi-objfile.exp: Match "list main" output
in console format.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
In commit 6e774b13c3, I forgot to update this test.
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Check for IPA basename instead of
absolute.
When we build a shared library for testing, it is built differently
whether it is meant for the local system or a remote one. When it is
for the local system, the library is built with no SONAME. So when the
executable is built, roughly in this way:
$ gcc testfile.c /path/to/library.so
the executable will contain an absolute reference to the library. For
example:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.python/py-shared-sl.sl]
When testing is done remotely, the absolute path obviously doesn't work.
Therefore, we build the library with an SONAME:
$ readelf -a testsuite/gdb.python/py-shared-sl.sl | grep SONAME
0x000000000000000e (SONAME) Library soname: [py-shared-sl.sl]
which ends up in the executable's NEEDED field:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [py-shared-sl.sl]
The executable and the library are then uploaded side-by-side on the
remote system. To allow the dynamic linker to find the shared library,
we have to add the special RPATH value $ORIGIN, which tells it to search
in the executable's directory:
$ readelf -a testsuite/gdb.python/py-shared | grep ORIGIN
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
The problem with the IPA library is that it doesn't have an SONAME,
making it very difficult to do testing on a remote board. When a
test executable is linked with it, it contains an absolute reference to
the library path. Therefore, unless the paths on the target are the
same as on the build system, it won't work.
To make it possible for tests using the IPA library to run test on
remote boards, I suggest adding an SONAME to libinproctrace.so. I don't
think it should be a big problem for users. All the libraries installed
on my system have an SONAME, so it should be fine if libinproctrace.so
does too.
As a consequence, native testing does not work anymore, since
executables do not contain the absolute path to the library anymore. To
keep them working, we can have gdb_load_shlibs copy the library to the
test directory when testing natively. That's done by modifying
gdb_load_shlibs. We also have to add RPATH=$ORIGIN to executables, even
when testing natively.
I think it's a good change in general, as it reduces the differences
between testing a native and a remote target. To further reduce those
differences, we can also always build test shared libraries with an
SONAME.
ftrace.exp and ftrace-lock.exp need to be modified slightly. The code
checks that the IPA library is loaded using the absolute path on the
build machine. That obviously doesn't work if the test is done
remotely, as the path will be different. I changed the tests to only
search for the library basename (e.g. libinproctrace.so).
gdb/gdbserver/ChangeLog:
* Makefile.in ($(IPA_LIB)): Set SONAME of the IPA lib.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace-lock.exp: Check for IPA basename instead of
absolute.
* gdb.trace/ftrace.exp: Likewise.
* lib/gdb.exp (gdb_compile): Set rpath $ORIGIN for non-remote
targets as well.
(gdb_compile_shlib): Set SONAME for non-remote targets as well.
(gdb_load_shlibs): Copy libraries to test directory when testing
natively. Only set solib-search-path if testing remotely.
* lib/mi-support.exp (mi_load_shlibs): Likewise.
This patch removes gdb_download in favor of gdb_remote_download, since
they are very close in functionality. Also, in preparation for the
following patch about shared library handling during tests, it improves
gdb_remote_download so that it uses standard_output_file for any
destination board that is local, not only host.
If the destination board is remote, gdb_remote_download will use the
standard remote_download from DejaGnu, resulting in the file being
transferred on the remote system.
If the destination is local, gdb_remote_download will copy the file to
the standard test directory (found using standard_output_file). Tcl's
file copy seems to handle gracefully cases where the source file is the
same as the destination, so I don't think it's necessary to check for
that case ourselves, as a previous version of the patch did.
I'd prefer to keep the name gdb_download instead of gdb_remote_download,
since I don't like the fact that gdb_remote_download implies that the
destination is remote, when it's not always the case. However,
gdb_remote_download is used at many more places than gdb_download, so
it's easier to reuse that. Also, since it's a wrapper around DejaGnu's
remote_download, it might be better to keep that name. I don't know.
I ran the testsuite native, with native-gdbserver and with a
remote gdbserver, and didn't see any related failure.
gdb/testsuite/ChangeLog:
* gdb.base/jit-so.exp: Use gdb_remote_download instead of
gdb_download. Use it even if the target is not remote.
* gdb.base/jit.exp (compile_jit_test): Likewise.
* lib/gdb.exp (gdb_remote_download): Copy files to the standard
output directory if the destination board is local, otherwise use
the standard remote_download from DejaGnu.
(gdb_download): Remove.
(gdb_load_shlibs): Use gdb_remote_download instead of
gdb_download.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Use gdb_remote_download instead of gdb_download. Use it even if
the target is not remote.
* lib/mi-support.exp (mi_load_shlibs): Use gdb_remote_download
instead of gdb_download.
The getauxval code was wrongly included in code area only compiled for
gdbserver. Move it to a #ifdef IN_PROCESS_AGENT area that already
contains lots of IPA-only code.
gdb/gdbserver/ChangeLog:
* tracepoint.c (getauxval): Move to #ifdef IN_PROCESS_AGENT.
The libraries are never downloaded to the target for the first test
(test_insert_delete_modify), so the executable can't run properly.
I also added some with_test_prefix to help differentiate between the
different test case phases.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-breakpoint-changed.exp: Add some with_test_prefix.
(test_insert_delete_modify): Call mi_load_shlibs before trying to
run.
These files need AT_PHDR, which is defined in elf.h. If HAVE_GETAUXVAL
is set, it's implicitely included by sys/auxv.h. Include it manually
for the opposite case.
gdb/gdbserver/ChangeLog:
* linux-aarch64-ipa.c: Add <elf.h> include.
* linux-ppc-ipa.c: Add <elf.h> include.
* linux-s390-ipa.c: Add <elf.h> include.
This patch adds support for TYPE_CODE_ENUM values to be supplied
as right-hand side operand of the BINOP_REPEAT (@) operator. The
following should now work:
enum {
sz = 17
};
int
main ()
{
int arr[sz + 1] = { 0 };
return 0; /* line 9 here */
}
(gdb) b 9
(gdb) r
(gdb) p arr@sz
$1 = {0 <repeats 17 times>}
(gdb)
A couple of tests is also included in this patch to demonstrate that it is
working as intended.
gdb/Changelog:
2016-04-01 Artemiy Volkov <artemiyv@acm.org>
PR gdb/19820
* eval.c (evaluate_subexp_standard): Allow TYPE_CODE_ENUM to be
the type of BINOP_REPEAT's second operand.
gdb/testsuite/Changelog:
2016-04-01 Artemiy Volkov <artemiyv@acm.org>
PR gdb/19820
* gdb.base/printcmds.exp: Add artificial arrays tests.
These were introduced by 1cda151268
and a13c46966d . One is a simple
missing cast, the other is const usage on global function pointers
exported from IPA: in C++, consts are static, and thus won't be
exported from the DSO (the build error was because of non-applicable
visibility("default")).
gdb/gdbserver/ChangeLog:
* tracepoint.c (gdb_collect_ptr): Remove const qualifier.
(get_raw_reg_ptr): Likewise.
(get_trace_state_variable_value_ptr): Likewise.
(set_trace_state_variable_value_ptr): Likewise.
(initialize_tracepoint): Cast alloc_jump_pad_buffer result to
char *.
This test would fail without the previous gdb/jit.c fix:
(gdb) attach 23031
Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031
[...]
207 WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach
set var wait_for_gdb = 0
(gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0
info function ^jit_function
All functions matching regular expression "^jit_function":
(gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function
gdb/testsuite/ChangeLog:
2016-03-31 Pedro Alves <palves@redhat.com>
PR gdb/19858
* gdb.base/jit-main.c: Include unistd.h.
(ATTACH): Define to 0 if not already defined.
(wait_for_gdb, mypid): New globals.
(WAIT_FOR_GDB): New macro.
(MAIN): Set an alarm. Store the process's pid. Wait for GDB at
some breakpoint locations.
* gdb.base/jit.exp (clean_reattach, continue_to_test_location):
New procedures.
(one_jit_test): Add REATTACH parameter, and handle it. Use
continue_to_test_location.
(top level): Test attach, and adjusts calls to one_jit_test.
This testcase compiles the same program and library differently
multiple times using the same file names. Make them unique, to make
it easier to debug test problems.
gdb/testsuite/ChangeLog:
2016-03-31 Pedro Alves <palves@redhat.com>
PR gdb/19858
* gdb.base/jit.exp (compile_jit_test): Add intro comment. Add
BINSUFFIX parameter, and handle it.
(top level): Adjust calls compile_jit_test.
Ref: https://sourceware.org/ml/gdb/2016-03/msg00023.html
GDB currently fails to fetch the list of already-registered JIT
modules on attach.
Nothing is calling jit_inferior_init, which is what is responsible for
walking the JIT object list at init time.
Despite the misleading naming, jit_inferior_created_hook ->
jit_inferior_init is only called when the inferior execs.
This regressed with the fix for PR gdb/13431 (03bef283c2):
https://sourceware.org/ml/gdb-patches/2012-02/msg00023.html which
removed the inferior_created (jit_inferior_created_observer)
observer.
Adding an inferior_created observer back fixes the issue.
In turn, this exposes a bug in jit_breakpoint_re_set_internal as well,
which is returning the wrong result when we already have the
breakpoint at the right address.
gdb/ChangeLog:
2016-03-31 Yichao Yu <yyc1992@gmail.com>
PR gdb/19858
* jit.c (jit_breakpoint_re_set_internal): Return 0 if we already
got the breakpoint at the right address.
(jit_inferior_created): New function.
(_initialize_jit): Install jit_inferior_created as
inferior_created observer.
Signed-off-by: Pedro Alves <palves@redhat.com>
