| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On async targets, a synchronous attach is done like this:
#1 - target_attach is called (PTRACE_ATTACH is issued)
#2 - a continuation is installed
#3 - we go back to the event loop
#4 - target reports stop (SIGSTOP), event loop wakes up, and
attach continuation is called
#5 - among other things, the continuation calls
target_terminal_inferior, which removes stdin from the event
loop
Note that in #3, GDB is still processing user input. If the user is
fast enough, e.g., with something like:
echo -e "attach PID\nset xxx=1" | gdb
... then the "set" command is processed before the attach completes.
We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:
(gdb) attach PID\nset xxx=1
we then crash readline/gdb, with:
Attaching to program: attach-wait-input, process 14537
readline: readline_callback_read_char() called with no handler!
Aborted
$
Fix this by calling target_terminal_inferior before #3 above.
The test covers both scenarios by running with editing/readline forced
to both on and off.
gdb/
2014-07-09 Pedro Alves <palves@redhat.com>
* infcmd.c (attach_command_post_wait): Don't call
target_terminal_inferior here.
(attach_command): Call it here instead.
gdb/testsuite/
2014-07-09 Pedro Alves <palves@redhat.com>
* gdb.base/attach-wait-input.exp: New file.
* gdb.base/attach-wait-input.c: New file.
|
|
|
|
|
|
On Windows, with "maint set target-async on" (the default since
a09dd441), Ctrl-C fails to stop a remote target.
With maint target-async on, the SIGINT signal handler doesn't send the
remote interrupt request immediately. Instead, it marks an async
handler as ready, and then the main event loop wakes up and notices
that the SIGINT async signal handler token was set, and calls the
corresponding event handler, which sends the remote interrupt request.
On POSIX-like systems, the SIGINT signal makes the select/poll in the
main event loop wake up / return with EINTR. However, on Windows,
signal handlers run on a separate thread, and Windows doesn't really
have a concept of EINTR. So, just marking the async handler
(effectively just setting a flag) does not wake up gdb_select.
Instead, we need to call gdb_call_async_signal_handler from the signal
handler. The Windows version (in mingw-hdep.c) sets a Windows event
that gdb_select's WaitForMultipleObjects is waiting for.
Confirmed that with this, Ctrl-C interrupts the remote target on
Windows. Also regression tested on x86_64 Fedora 20 against
GDBserver.
gdb/
2014-07-07 Pedro Alves <palves@redhat.com>
gdb/17096
* remote.c (async_handle_remote_sigint)
(async_handle_remote_sigint_twice): Call
gdb_call_async_signal_handler instead of
mark_async_signal_handler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes a regression that Jan pointed out.
The bug is that some names were allocated by dwarf2read on the objfile
obstack, but then passed to SYMBOL_SET_NAMES with copy_name=0. This
violates the invariant that the names must have a lifetime tied to the
lifetime of the BFD.
The fix is to allocate names on the per-BFD obstack.
I looked at all callers, direct or indirect, of SYMBOL_SET_NAMES that
pass copy_name=0. Note that only the ELF and DWARF readers do this;
other symbol readers were never updated (and perhaps cannot be,
depending on the details of the formats). This is why the patch is
relatively small.
Built and regtested on x86-64 Fedora 20.
2014-06-26 Tom Tromey <tromey@redhat.com>
PR symtab/16902:
* dwarf2read.c (fixup_go_packaging, dwarf2_compute_name)
(dwarf2_physname, read_partial_die)
(guess_partial_die_structure_name, fixup_partial_die)
(guess_full_die_structure_name, anonymous_struct_prefix)
(dwarf2_name): Use per-BFD obstack.
|
|
|
|
|
|
* doc/gdb.texinfo (Screen Size): Add more index entries.
(cherry picked from commit f179cf97a071940bfce6879aa59dbac66ffca391)
|
|
bfd/ChangeLog:
* targets.c (_bfd_target_vector): Add missing #ifdef BFD64 for
a number of targets.
|
|
Currently, the xmethod commands lookup xmethod matchers in the current
progspace even if the locus regular expression matches the progspace's
filename. Pretty printer commands do not match the current progspace's
filename.
gdb/
* python/lib/gdb/command/xmethods.py
(get_method_matchers_in_loci): Lookup xmethod matchers in the
current progspace only if the string "progspace" matches LOCUS_RE.
gdb/testsuite
* gdb.python/py-xmethods.exp: Use "progspace" instead of the
progspace's filename in 'info', 'enable' and 'disable' command
tests.
|
|
|
|
This patch fixes this on x86 Linux:
(gdb) watch *buf@2
Hardware watchpoint 8: *buf@2
(gdb) si
0x00000000004005a7 34 for (i = 0; i < 100000; i++); /* stepi line */
(gdb) del
Delete all breakpoints? (y or n) y
(gdb) watch *(buf+1)@1
Hardware watchpoint 9: *(buf+1)@1
(gdb) si
0x00000000004005a7 in main () at ../../../src/gdb/testsuite/gdb.base/watchpoint-reuse-slot.c:34
34 for (i = 0; i < 100000; i++); /* stepi line */
Couldn't write debug register: Invalid argument.
(gdb)
In the example above the debug registers are being switched from this
state:
CONTROL (DR7): 0000000000050101 STATUS (DR6): 0000000000000000
DR0: addr=0x0000000000601040, ref.count=1 DR1: addr=0x0000000000000000, ref.count=0
DR2: addr=0x0000000000000000, ref.count=0 DR3: addr=0x0000000000000000, ref.count=0
to this:
CONTROL (DR7): 0000000000010101 STATUS (DR6): 0000000000000000
DR0: addr=0x0000000000601041, ref.count=1 DR1: addr=0x0000000000000000, ref.count=0
DR2: addr=0x0000000000000000, ref.count=0 DR3: addr=0x0000000000000000, ref.count=0
That is, before, DR7 was setup for watching a 2 byte region starting
at what's in DR0 (0x601040).
And after, DR7 is setup for watching a 1 byte region starting at
what's in DR0 (0x601041).
We always write DR0..DR3 before DR7, because if we enable a slot's
bits in DR7, you need to have already written the corresponding
DR0..DR3 registers -- the kernel rejects the DR7 write with EINVAL
otherwise.
The error shown above is the opposite scenario. When we try to write
0x601041 to DR0, DR7's bits still indicate intent of watching a 2-byte
region. That DR0/DR7 combination is invalid, because 0x601041 is
unaligned. To watch two bytes, we'd have to use two slots. So the
kernel errors out with EINVAL.
Fix this by always first clearing DR7, then writing DR0..DR3, and then
setting DR7's bits.
A little optimization -- if we're disabling the last watchpoint, then
we can clear DR7 just once. The changes to nat/i386-dregs.c make that
easier to detect, and as bonus, they make it a little easier to make
sense of DR7 in the debug logs, as we no longer need to remember we're
seeing stale bits.
Tested on x86_64 Fedora 20, native and GDBserver.
This adds an exhaustive test that switches between many different
combinations of watchpoint types and addresses and widths.
gdb/
2014-06-23 Pedro Alves <palves@redhat.com>
* amd64-linux-nat.c (amd64_linux_prepare_to_resume): Clear
DR_CONTROL before setting DR0..DR3.
* i386-linux-nat.c (i386_linux_prepare_to_resume): Likewise.
* i386-nat.c (i386_remove_aligned_watchpoint): Clear all bits of
DR_CONTROL related to the debug register slot being disabled. If
all slots are vacant, clear local slowdown as well, and assert
DR_CONTROL is 0.
gdb/gdbserver/
2014-06-23 Pedro Alves <palves@redhat.com>
* linux-x86-low.c (x86_linux_prepare_to_resume): Clear DR_CONTROL
before setting DR0..DR3.
* i386-low.c (i386_remove_aligned_watchpoint): Clear all bits of
DR_CONTROL related to the debug register slot being disabled. If
all slots are vacant, clear local slowdown as well, and assert
DR_CONTROL is 0.
gdb/testsuite/
2014-06-23 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-reuse-slot.c: New file.
* gdb.base/watchpoint-reuse-slot.exp: New file.
|
|
On x86_64 with -m32 or on i686 it will:
Running ./gdb.arch/amd64-stap-special-operands.exp ...
gdb compile failed, amd64-stap-triplet.c: Assembler messages:
amd64-stap-triplet.c:35: Error: bad register name `%rbp'
amd64-stap-triplet.c:38: Error: bad register name `%rsp'
amd64-stap-triplet.c:40: Error: bad register name `%rbp)'
amd64-stap-triplet.c:41: Error: bad register name `%rsi'
amd64-stap-triplet.c:42: Error: bad register name `%rbp)'
/tmp/ccjOdmpl.s:63: Error: bad register name `%rbp'
2014-06-23 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-stap-special-operands.exp: Use is_lp64_target.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
* gdb.dwarf2/dw2-error.exp: Use istarget and is_lp64_target.
Message-ID: <20140622211401.GA3716@host2.jankratochvil.net>
|
|
|
|
|
|
|
|
|
|
Running gdb.threads/thread-execl.exp with scheduler-locking set to
"step" reveals a problem:
(gdb) next^M
[Thread 0x7ffff7fda700 (LWP 27168) exited]^M
[New LWP 27168]^M
[Thread 0x7ffff74ee700 (LWP 27174) exited]^M
process 27168 is executing new program: /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.threads/thread-execl^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
infrun.c:5225: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.threads/thread-execl.exp: schedlock step: get to main in new image (GDB internal error)
The assertion is correct. The issue is that GDB is mistakenly trying
to switch back to an exited thread, that was previously stepping when
it exited. This is exactly the sort of thing the test wants to make
sure doesn't happen:
# Now set a breakpoint at `main', and step over the execl call. The
# breakpoint at main should be reached. GDB should not try to revert
# back to the old thread from the old image and resume stepping it
We don't see this bug with schedlock off only because a different
sequence of events makes GDB manage to delete the thread instead of
marking it exited.
This particular internal error can be fixed by making the loop over
all threads in switch_back_to_stepped_thread skip exited threads.
But, looking over other ALL_THREADS users, all either can or should be
skipping exited threads too. So for simplicity, this patch replaces
ALL_THREADS with a new macro that skips exited threads itself, and
updates everything to use it.
Tested on x86_64 Fedora 20.
gdb/
2014-06-19 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_THREADS): Delete.
(ALL_NON_EXITED_THREADS): New macro.
* btrace.c (btrace_free_objfile): Use ALL_NON_EXITED_THREADS
instead of ALL_THREADS.
* infrun.c (find_thread_needs_step_over)
(switch_back_to_stepped_thread): Use ALL_NON_EXITED_THREADS
instead of ALL_THREADS.
* record-btrace.c (record_btrace_open)
(record_btrace_stop_recording, record_btrace_close)
(record_btrace_is_replaying, record_btrace_resume)
(record_btrace_find_thread_to_move, record_btrace_wait): Likewise.
* remote.c (append_pending_thread_resumptions): Likewise.
* thread.c (thread_apply_all_command): Likewise.
gdb/testsuite/
2014-06-19 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): New procedure, factored
out from ...
(top level): ... here. Iterate running tests under different
scheduler-locking settings.
|
|
|
|
|
|
|
|
remove breakpoint.
Turns out there's a difference between loading the program with "gdb
PROGRAM", vs loading it with "(gdb) file PROGRAM". The latter results
in the objfile ending up with OBJF_USERLOADED set, while not with the
former. (That difference seems bogus, but still that's not the point
of this patch. We can revisit that afterwards.)
The new code that suppresses breakpoint removal errors for
add-symbol-file objects ends up being too greedy:
/* In some cases, we might not be able to remove a breakpoint in
a shared library that has already been removed, but we have
not yet processed the shlib unload event. Similarly for an
unloaded add-symbol-file object - the user might not yet have
had the chance to remove-symbol-file it. shlib_disabled will
be set if the library/object has already been removed, but
the breakpoint hasn't been uninserted yet, e.g., after
"nosharedlibrary" or "remove-symbol-file" with breakpoints
always-inserted mode. */
if (val
&& (bl->loc_type == bp_loc_software_breakpoint
&& (bl->shlib_disabled
|| solib_name_from_address (bl->pspace, bl->address)
|| userloaded_objfile_contains_address_p (bl->pspace,
bl->address))))
val = 0;
as it turns out that OBJF_USERLOADED can be set for objfiles loaded by
some other means not add-symbol-file. In this case, symbol-file (or
"file", which is really just "exec-file"+"symbol-file").
Recall that add-symbol-file is documented as:
(gdb) help add-symbol-file
Load symbols from FILE, assuming FILE has been dynamically loaded.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And it's the "dynamically loaded" aspect that the breakpoint.c code
cares about. So make add-symbol-file set OBJF_SHARED on its objfiles
too, and tweak the breakpoint.c code to look for OBJF_SHARED instead
of OBJF_USERLOADED.
This restores back the missing breakpoint removal warning when we let
sss-bp-on-user-bp-2.exp run on native GNU/Linux
(https://sourceware.org/ml/gdb-patches/2014-06/msg00335.html):
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
warning: Error removing breakpoint 3
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: stepi_del_break
I say "restores" because this was GDB's behavior in 7.7 and earlier.
And, likewise, "file" with no arguments only started turning
breakpoints set in the main executable to "<pending>" with the
remote-symbol-file patch (63644780). The old behavior is now
restored, and we break-unload-file.exp test now exercizes both "gdb;
file PROGRAM" and "gdb PROGRAM".
gdb/
2014-06-16 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location, remove_breakpoint_1): Adjust.
(disable_breakpoints_in_freed_objfile): Skip objfiles that don't
have OBJF_SHARED set.
* objfiles.c (userloaded_objfile_contains_address_p): Rename to...
(shared_objfile_contains_address_p): ... this. Check OBJF_SHARED
instead of OBJF_USERLOADED.
* objfiles.h (OBJF_SHARED): Update comment.
(userloaded_objfile_contains_address_p): Rename to ...
(shared_objfile_contains_address_p): ... this, and update
comments.
* symfile.c (add_symbol_file_command): Also set OBJF_SHARED in the
new objfile.
(remove_symbol_file_command): Skip objfiles that don't have
OBJF_SHARED set.
gdb/testsuite/
2014-06-16 Pedro Alves <palves@redhat.com>
* gdb.base/break-main-file-remove-fail.c: New file.
* gdb.base/break-main-file-remove-fail.exp: New file.
* gdb.base/break-unload-file.exp: Use build_executable instead of
prepare_for_testing.
(test_break): New parameter "initial_load". Handle it.
(top level): Add initial_load cmdline/file axis.
|
|
|
|
|
|
* top.c (print_gdb_configuration) [HAVE_GUILE]: Print --with-guile
or --without-guile, according to how GDB was built.
(cherry picked from commit 97d66cc602ec5abfcb6fc6baaf3d6edbde4fcbfb)
|
|
|
|
|
|
gdb/
2014-06-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_child_follow_fork): Initialize status with
W_STOPCODE (0) instead of 0. Remove shodowing 'status' local from
inner block. Only pass the signal to PTRACE_DETACH if in pass
state.
|
|
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 7.7.90.DATE-cvs.
|
|
gdb/ChangeLog:
GDB 7.7.90 released.
|
|
gdb/ChangeLog:
* version.in: Set GDB version number to 7.7.90.
|
|
bfd/ChangeLog:
* development.sh (development): Set to false.
|
|
Now that the GDB 7.8 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 7.8 branch created (173373c6f6388171d1d62a217fae90a052395be2):
* version.in: Bump version to 7.7.90.DATE-cvs.
|
|
A call to demangle_template might allocate storage within a temporary
string even if the call to demangle_template eventually returns
failure.
This will never cause the demangler to crash, but does leak memory, as
a result I've not added any tests for this.
Calling string_delete is safe, even if nothing is allocated into the
string, the string is initialised with string_init, so we know the
internal pointers are NULL.
libiberty/ChangeLog
* cplus-dem.c (do_type): Call string_delete even if the call to
demangle_template fails.
|
|
Since target-async was turned on by default, debugging on Windows
using GDB+GDBserver sometimes hangs while waiting for a RSP reply.
The problem is a race in the gdb_select machinery.
This is what we see for a faulty next on the GDB side:
(gdb) n
infrun: clear_proceed_status_thread (Thread 4424)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
(...)
infrun: resume (step=1, signal=GDB_SIGNAL_0), ...
Sending packet: $vCont;s:1148;c#5e...
*hang*
At this point, attaching a debugger to the hanging GDB confirms that
it is blocked, waiting for a socket event:
#6 0x757841d8 in WaitForMultipleObjects ()
from C:\Windows\syswow64\kernel32.dll
#7 0x004708e7 in gdb_select (n=469, readfds=0x88ca50 <gdb_notifier+784>,
writefds=0x88cb54 <gdb_notifier+1044>,
exceptfds=0x88cc58 <gdb_notifier+1304>, timeout=0x0)
at /[...]/gdb/mingw-hdep.c:172
#8 0x00527926 in gdb_wait_for_event (block=1)
at /[...]/gdb/event-loop.c:831
#9 0x00526ff1 in gdb_do_one_event ()
at /[...]/gdb/event-loop.c:403
However, on the GDBserver side, we see that GDBserver already sent a
T05 packet reply:
gdbserver: kernel event EXCEPTION_DEBUG_EVENT for pid=4968 tid=1148
EXCEPTION_SINGLE_STEP
Child Stopped with signal = 5
Writing resume reply for LWP 4968.4424:1
DEBUG: write_prim ($T0505:c8fe2800;04:a0fe2800;08:38164000;thread:1148;#f0)
-> 55
To recap, on Windows, 'select' only works with sockets, so we have a
wrapper, gdb_select, that uses the GDB serial abstraction to handle
sockets, consoles, pipes, and serial ports. Each serial descriptor
has a thread associated (we call those the select threads), and those
threads communicate with the main thread by means of standard Windows
events.
It basically goes like this: gdb_select first loops through all fds of
interest, calling their wait_handle hooks, which returns an event that
WaitForMultipleObjects can wait on. gdb_select then blocks in
WaitForMultipleObjects with all those event handles. The wait_handle
hook is responsible for arranging for the returned event to become set
once data is available. This is done by setting the descriptor's
helper thread running, which itself knows how to wait for data from
the type of handle it manages (sockets, pipes, consoles, files, etc.).
Once data arrives, the select thread sets the corresponding event
which unblocks WaitForMultipleObjects within gdb_select. However, the
wait_handle hook can also apply an optimization: if data is already
pending, then there's no need to set the thread running, and the
descriptors event can be set immediately. It's around this latter
aspect that lies the bug/race.
Adding some ad hoc debug logs to ser-mingw.c and mingw-hdep.c, we see
the following sequence of events, right after sending
"$vCont;s:1148;c#5e". Thread 1 is the main thread, and thread 2 is
the socket's helper/select thread. gdb_select was only passed one
descriptor to wait on, the remote target's socket.
net_windows_select_thread is the entry point of the select threads for
sockets.
#1 - thread 1: gdb_select: enter
#2 - thread 2: net_windows_select_thread: WaitForMultipleObjects blocking
gdb_select walked over the wait_handle hooks, and woke up the socket's
helper thread. The helper thread is now blocked waiting for socket
events.
#3 - thread 1: gdb_select: WaitForMultipleObjects polling (timeout=0ms)
#4 - thread 1: gdb_select: WaitForMultipleObjects returned 102 (WAIT_TIMEOUT)
There was no pending data available yet, and gdb_select was passed
timeout==0ms, and so WaitForMultipleObjects times out immediately.
#5 - thread 2: net_windows_select_thread: WaitForMultipleObjects returned 1
Just afterwards, socket data arrives, and thread 2 wakes up. Thread 2
calls WSAEnumNetworkEvents, which clears state->sock_event, and marks
the serial's read_event event, telling the main thread that data is
available.
#6 - thread 1: gdb_select: call serial_done_wait_handle on each serial
gdb_select stops all the helper/select threads.
#7 - thread 1: gdb_select: return 0 (WAIT_TIMEOUT)
gdb_select in the main thread returns to the caller.
Note that at this point, data is pending on the socket, the serial's
read_event is set, but the socket's sock_event event is not set, until
_further_ data arrives.
Now GDB does its thing and goes back to the event loop. That calls
gdb_select, but with timeout==INFINITE.
Again, gdb_select calls the socket serial's wait_handle hook. It
first clears its events, starting from a clean slate:
ResetEvent (state->base.read_event);
ResetEvent (state->base.except_event);
ResetEvent (state->base.stop_select);
That cleared read_event, which was previously set in #5 above. And
then it checks for pending events, in the sock_event event:
/* Check any pending events. This both avoids starting the thread
unnecessarily, and handles stray FD_READ events (see below). */
if (WaitForSingleObject (state->sock_event, 0) == WAIT_OBJECT_0)
{
That also fails because state->sock_event was cleared in #5 too...
So the wait_handle hook erroneously decides that it needs to start the
helper thread to wait for input:
#8 - thread 2: net_windows_select_thread: WaitForMultipleObjects blocking
#9 - thread 1: gdb_select: WaitForMultipleObjects blocking (INFINITE)
But, GDBserver already sent all it had to send, so both threads waits
forever...
At first I thought that net_windows_wait_handle shouldn't be resetting
state->base.read_event or state->base.except_event, but looking
deeper, the pipe and console wait_handle hooks reset all events too.
It actually makes sense that way -- consuming an event from different
threads is bad practice, and, we should always be able to query
pending state without looking at the state->sock_event from within
net_windows_wait_handle. The end result is much simpler, and makes
net_windows_select_thread look a lot like console_select_thread,
actually.
gdb/
2014-06-11 Pedro Alves <palves@redhat.com>
PR remote/17028
* ser-mingw.c (net_windows_socket_check_pending): New function.
(net_windows_select_thread): Ignore spurious wakeups. Use
net_windows_socket_check_pending.
(net_windows_wait_handle): Check for pending events with
ioctlsocket, through net_windows_socket_check_pending, instead of
checking the socket's event.
|
|
* linker.c (unwrap_hash_lookup): Add missing parens.
|
|
* libcoff.h: Regenerated.
|
|
* libcoff.h: Regenerated.
|
