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 --- programs/winedbg/gdbproxy.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c index 3903f113470e..b3c4002b3b35 100644 --- a/programs/winedbg/gdbproxy.c +++ b/programs/winedbg/gdbproxy.c @@ -2094,7 +2094,7 @@ static int fetch_data(struct gdb_context* gdbctx) #define FLAG_NO_START 1 #define FLAG_WITH_XTERM 2
-static BOOL gdb_exec(const char* wine_path, unsigned port, unsigned flags) +static BOOL gdb_exec(unsigned port, unsigned flags) { char buf[MAX_PATH]; int fd; @@ -2108,7 +2108,6 @@ static BOOL gdb_exec(const char* wine_path, unsigned port, unsigned flags) fd = mkstemps(buf, 0); if (fd == -1) return FALSE; if ((f = fdopen(fd, "w+")) == NULL) return FALSE; - fprintf(f, "file "%s"\n", wine_path); fprintf(f, "target remote localhost:%d\n", ntohs(port)); fprintf(f, "set prompt Wine-gdb>\ \n"); /* gdb 5.1 seems to require it, won't hurt anyway */ @@ -2138,7 +2137,6 @@ static BOOL gdb_startup(struct gdb_context* gdbctx, unsigned flags, unsigned por struct sockaddr_in s_addrs = {0}; socklen_t s_len = sizeof(s_addrs); struct pollfd pollfd; - IMAGEHLP_MODULE64 imh_mod; BOOL ret = FALSE;
/* step 1: create socket for gdb connection request */ @@ -2160,11 +2158,7 @@ static BOOL gdb_startup(struct gdb_context* gdbctx, unsigned flags, unsigned por /* step 2: do the process internal creation */ handle_debug_event(gdbctx);
- /* step3: get the wine loader name */ - if (!dbg_get_debuggee_info(gdbctx->process->handle, &imh_mod)) - goto cleanup; - - /* step 4: fire up gdb (if requested) */ + /* step 3: fire up gdb (if requested) */ if (flags & FLAG_NO_START) fprintf(stderr, "target remote localhost:%d\n", ntohs(s_addrs.sin_port)); else @@ -2177,12 +2171,12 @@ static BOOL gdb_startup(struct gdb_context* gdbctx, unsigned flags, unsigned por signal(SIGINT, SIG_IGN); break; case 0: /* in child... and alive */ - gdb_exec(imh_mod.LoadedImageName, s_addrs.sin_port, flags); + gdb_exec(s_addrs.sin_port, flags); /* if we're here, exec failed, so report failure */ goto cleanup; }
- /* step 5: wait for gdb to connect actually */ + /* step 4: wait for gdb to connect actually */ pollfd.fd = sock; pollfd.events = POLLIN; pollfd.revents = 0;
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 --- programs/winedbg/gdbproxy.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c index b3c4002b3b35..332fb0c9d3b6 100644 --- a/programs/winedbg/gdbproxy.c +++ b/programs/winedbg/gdbproxy.c @@ -874,10 +874,11 @@ static enum packet_return packet_reply_status(struct gdb_context* gdbctx) dbg_ctx_t ctx; size_t i;
- if (process != NULL) + switch (gdbctx->de.dwDebugEventCode) { + default: + if (!process) return packet_error; if (!(backend = process->be_cpu)) return packet_error; - if (!(thread = dbg_get_thread(process, gdbctx->de.dwThreadId)) || !backend->get_context(thread->handle, &ctx)) return packet_error; @@ -900,13 +901,13 @@ static enum packet_return packet_reply_status(struct gdb_context* gdbctx)
packet_reply_close(gdbctx); return packet_done; - } - else - { - /* Try to put an exit code - * Cannot use GetExitCodeProcess, wouldn't fit in a 8 bit value, so - * just indicate the end of process and exit */ - return packet_reply(gdbctx, "W00") | packet_last_f; + + case EXIT_PROCESS_DEBUG_EVENT: + packet_reply_open(gdbctx); + packet_reply_add(gdbctx, "W"); + packet_reply_val(gdbctx, gdbctx->de.u.ExitProcess.dwExitCode, 4); + packet_reply_close(gdbctx); + return packet_done | packet_last_f; } }
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45070 Signed-off-by: Rémi Bernon rbernon@codeweavers.com ---
The bug was probably already fixed by previous commits. I believe gdb stopped using its default hooks to detect thread start/stop since we started advertising a custom target
As this patch is specifically about thread start/stop events, let's say it fixes the issue.
programs/winedbg/gdbproxy.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c index 332fb0c9d3b6..72e90e8db19e 100644 --- a/programs/winedbg/gdbproxy.c +++ b/programs/winedbg/gdbproxy.c @@ -106,6 +106,7 @@ struct gdb_context /* Unix environment */ unsigned long wine_segs[3]; /* load addresses of the ELF wine exec segments (text, bss and data) */ BOOL no_ack_mode; + BOOL thread_events; };
static void gdbctx_delete_xpoint(struct gdb_context *gdbctx, struct dbg_thread *thread, @@ -480,14 +481,18 @@ static BOOL handle_debug_event(struct gdb_context* gdbctx) de->dwThreadId, de->u.CreateThread.hThread, de->u.CreateThread.lpThreadLocalBase); - return TRUE; + if (!gdbctx->thread_events) + return TRUE; + break;
case EXIT_THREAD_DEBUG_EVENT: fprintf(stderr, "%08x:%08x: exit thread (%u)\n", de->dwProcessId, de->dwThreadId, de->u.ExitThread.dwExitCode); if ((thread = dbg_get_thread(gdbctx->process, de->dwThreadId))) dbg_del_thread(thread); - return TRUE; + if (!gdbctx->thread_events) + return TRUE; + break;
case EXIT_PROCESS_DEBUG_EVENT: fprintf(stderr, "%08x:%08x: exit process (%u)\n", @@ -886,6 +891,8 @@ static enum packet_return packet_reply_status(struct gdb_context* gdbctx) packet_reply_open(gdbctx); packet_reply_add(gdbctx, "T"); packet_reply_val(gdbctx, signal_from_debug_event(&gdbctx->de), 1); + if (gdbctx->de.dwDebugEventCode == CREATE_THREAD_DEBUG_EVENT) + packet_reply_add(gdbctx, "create:"); packet_reply_add(gdbctx, "thread:"); packet_reply_val(gdbctx, gdbctx->de.dwThreadId, 4); packet_reply_add(gdbctx, ";"); @@ -902,6 +909,15 @@ static enum packet_return packet_reply_status(struct gdb_context* gdbctx) packet_reply_close(gdbctx); return packet_done;
+ case EXIT_THREAD_DEBUG_EVENT: + packet_reply_open(gdbctx); + packet_reply_add(gdbctx, "w"); + packet_reply_val(gdbctx, gdbctx->de.u.ExitThread.dwExitCode, 4); + packet_reply_add(gdbctx, ";"); + packet_reply_val(gdbctx, gdbctx->de.dwThreadId, 4); + packet_reply_close(gdbctx); + return packet_done; + case EXIT_PROCESS_DEBUG_EVENT: packet_reply_open(gdbctx); packet_reply_add(gdbctx, "W"); @@ -1843,6 +1859,7 @@ static enum packet_return packet_query(struct gdb_context* gdbctx) { packet_reply_open(gdbctx); packet_reply_add(gdbctx, "QStartNoAckMode+;"); + packet_reply_add(gdbctx, "QThreadEvents+;"); packet_reply_add(gdbctx, "qXfer:libraries:read+;"); packet_reply_add(gdbctx, "qXfer:threads:read+;"); packet_reply_add(gdbctx, "qXfer:features:read+;"); @@ -1920,6 +1937,13 @@ static enum packet_return packet_set(struct gdb_context* gdbctx) return packet_ok; }
+ if (strncmp(gdbctx->in_packet, "ThreadEvents:", 13) == 0) + { + if (sscanf(gdbctx->in_packet, "ThreadEvents:%d", &gdbctx->thread_events) != 1) + return packet_error; + return packet_ok; + } + return packet_error; }
On 4/7/20 7:34 PM, Rémi Bernon wrote:
@@ -886,6 +891,8 @@ static enum packet_return packet_reply_status(struct gdb_context* gdbctx) packet_reply_open(gdbctx); packet_reply_add(gdbctx, "T"); packet_reply_val(gdbctx, signal_from_debug_event(&gdbctx->de), 1);
if (gdbctx->de.dwDebugEventCode == CREATE_THREAD_DEBUG_EVENT)packet_reply_add(gdbctx, "create:");
This should actually be "create:;", to fit in the semicolon-separated list. I'll update and resend this one.
On 4/7/20 10:01 PM, Rémi Bernon wrote:
On 4/7/20 7:34 PM, Rémi Bernon wrote:
@@ -886,6 +891,8 @@ static enum packet_return packet_reply_status(struct gdb_context* gdbctx) packet_reply_open(gdbctx); packet_reply_add(gdbctx, "T"); packet_reply_val(gdbctx, signal_from_debug_event(&gdbctx->de), 1); + if (gdbctx->de.dwDebugEventCode == CREATE_THREAD_DEBUG_EVENT) + packet_reply_add(gdbctx, "create:");
This should actually be "create:;", to fit in the semicolon-separated list. I'll update and resend this one.
On second thought this is not really useful after all, gdb doesn't even send that request by default, I think I added it for lldb. Please, just ignore this patch.
I believe the referenced bug is still already fixed by the previous patches, though.
-
Rémi Bernon