Let gdb handle the control-c instead of killing winedbg.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51766
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Today, when gdbproxy is started with --no-start mode, GDB fails to
recognise the symbol file unless the `file` command or the
`sharedlibrary` command is explicitly issued.
Also, RHEL's downstream GDB complains with the following message:
Remote gdbserver does not support determining executable automatically.
RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection.
The following versions of gdbserver support it:
- Upstream version of gdbserver (unsupported) 7.10 or later
- Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64)
- RHEL-7.3 versions of gdbserver (on any architecture)
Fix this by implementing the qXfer object "exec-file".
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
GDB does not retrieve the result of a qXfer command at once; instead, it
issues a series of requests to obtain the result one "chunk" at a time,
and concatenates those chunks internally. Each request contains offset
and length variables that specify which portion of the result shall be
retrieved.
Today, Winedbg handles this by generating the entire result data each
time a request is received and slicing out the requested range for the
response. This is not only inefficient due to repeated computation,
but also prone to race condition since the result may change between
successive chunk requests due to the dynamic nature of some commands
such as "libraries" and "threads."
Fix this by cacheing the result into a buffer at the first request, and
use the buffer to serve successive chunk requests. The cache is
invalidated when the remote requests a different object, or the debugger
reaches the end of the result cache buffer.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Define a handler lookup table for qXfer commands and use it.
This facilitates implementing more qXfer commands and cacheing reply
data.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some dynamic strings (e.g. loaded image paths) may contain XML special
characters which breaks parsing.
Fix this by escaping all dynamic strings (i.e. character data and
attribute values) that go into the XML replies.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Today, gdbproxy reuses the same buffer for both the qXfer reply and the
actual GDB packet reply. This worked well, since each byte in the qXfer
reply buffer matched 1:1 to each byte in the actual GDB reply packet.
Since we escape special characters now, this property no longer holds
and a single byte in qXfer reply will take up to two bytes in the GDB
reply packet. This causes offsets to shift, preventing the
offset/length response slicing (part of GDB protocol) from working
correctly.
Fix this by writing the qXfer reply data in a separate buffer, and
performing slicing out of it.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is required for a subsequent patch that adds buffering for
GDB qXfer reply data.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There are four special characters in GDB's remote serial protocol:
- '$' (0x24): start of packet
- '}' (0x7D): escape
- '*' (0x2A): run-length encoding repeat count delimiter
- '#' (0x23): end of packet; start of checksum
In particular, the '#' and '}' characters are problematic since they
are often used in library filenames. A few examples:
- %SystemRoot%\assembly\NativeImages_v[.NET ver]\[module+hash]#\*\*.dll
- {CLSID or UUID}\*\.dll
To make GDB happy with those filenames, we scan for those characters and
escape them properly.
While we are at it, also remove the assert in the packet_reply function
that checks for '$' and '#' in the packet payload.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
packet_query uses sscanf format "%x" to parse out offset and length
values. Since %x corresponds to unsigned int in the C standard, adjust
the variable types appropriately.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
winedbg is now built with msvcrt, so just use realloc() directly
instead of Win32 heap functions.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This allows GDB to load symbols and resolve pending breakpoints for
dynamically loaded DLLs.
Signed-off-by: Anton Baskanov <baskanov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This will help expand later the cases to tell gdb about the cause of the
break.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Sometimes it's not there and now that we have qXfer:libraries:read
request support, we don't need to tell gdb to load it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
No real need for a context member for that as well, the mapping is
quite straightforward. It also simplifies handle_exception.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As in the previous patch, return TRUE if the debug event should be
ignored or FALSE is we should tell gdb. There's no need to have an
in_trap context member for that.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It was returning a mix of TRUE/FALSE and in some cases DBG_CONTINUE.
Let's return TRUE if the exception has been handled and should be
ignored, or FALSE if not and if we should notify gdb.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reports the full register sets to gdb, telling it about custom
offsets and sizes. It will make the gdb specific register length not
required anymore.
We also have to report architecture specific vector types and flags
that are normally builtin in gdb as it does not load them anymore when
custom register set is reported.
This makes gdb stop using its incorrect heuristics and actually request
the library list, it now correctly gets PE modules information and is
able to correctly use debug info from mixed modules.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As we don't report fork/vfork/exec events, this allows gdb to request
the list of known threads.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For now gdb does not request it as it still believes it's running a
normal application. It will however, as soon as we advertise support for
qXfer:features:read request and reply with a custom register set.
This also introduces packet_reply_open_xfer / packet_reply_close_xfer
function to allow partial replies. It always allocate the full reply
for simplicity and then truncates to the requested offset and size.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The vCont handler used some overcomplicated logic, we only need to
iterate over the actions and apply them on the matching threads that
didn't match yet.
Thanks to DBG_REPLY_LATER we can now continue/step any thread regardless
of whether it is the one that raised the debug event. Just suspend all
active threads after debug event is raised and resume them one by one,
according to the gdb request. If the thread that raised the debug event
should not be resumed, reply with DBG_REPLY_LATER.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Looking up the thread makes us loose track of any/all (0/-1) tids, we
need that for correct continue/step implementation.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is still some cleanup, and does not fix much wrt step / continue,
but it introduces dbg_thread_set_single_step that is going to be useful
for individual thread control and let us remove all remaining uses of
gdbctx->context.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This was using some conditional context read and dbg_curr_thread checks,
we can just read the context of the selected thread and write it back as
needed.
Also, packet_reply_register_hex_to was using gdbctx->context, which is
not always the context we want to read.
We still need to keep changes in sync with gdbctx->context as it may be
still be used for step / continue, but step / continue doesn't work well
and we will rewrite it later.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This doesn't compile anymore, let's get rid of it instead or pretending
it can still be useful.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's a special packet_last_f flag to indicate we should quit, use
that on kill packet instead of exiting abruptly.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We now always print a warning when packet_error is returned.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't have to validate and acknowledge the packets as long as this
mode is enabled, this will reduce verbosity especially when tracing.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Sometimes multiple packets are received and we were assuming it was
some repeated requests due to slow ack. We can ack packets first.
It was also dropping some perfectly valid packets and we should process
them all. For instance, lldb frontend sometimes send multiple packets
at a the same time and expects them to be handled.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Eric Pouech