This is a horrible hack, but without it all gdb computed symbols are wrong. There's probably a reason behind it, but it's not clear why. Also there's probably a better way to check if a module is PE. Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- I'm sending this horrible hack as well because without it gdbproxy is still not very usable. I didn't dig very deep into the reasons behind it, but I'm suspecting gdb wants to be told about the modules sections, and not really the files mappings. Then I couldn't find a simple way to iterate over modules sections from another process. Using VirtualQueryEx could help iterating over mapped modules but the function takes a void* as address, so that won't work if winedbg is 32bit and is debugging a 64bit process. programs/winedbg/gdbproxy.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c index c15a008c656a..79f9634aaeac 100644 --- a/programs/winedbg/gdbproxy.c +++ b/programs/winedbg/gdbproxy.c @@ -1476,6 +1476,7 @@ static BOOL CALLBACK packet_query_libraries_cb(PCSTR mod_name, DWORD64 base, PVO { struct gdb_context* gdbctx = ctx; IMAGEHLP_MODULE64 mod; + unsigned int len; DWORD64 addr; BOOL is_wow64; char* tmp; @@ -1513,6 +1514,17 @@ static BOOL CALLBACK packet_query_libraries_cb(PCSTR mod_name, DWORD64 base, PVO addr = mod.BaseOfImage; + /* FIXME: This is an ugly hack to make gdb correct about its debug + * info computations with PE files. There's probably a correct way + * to do it. */ + len = strlen(mod.LoadedImageName); + if (strcmp(mod.LoadedImageName + len - 4, ".dll") == 0 || + strcmp(mod.LoadedImageName + len - 4, ".exe") == 0) + { + FIXME("Offsetting %s base address by 0x1000\n", mod.LoadedImageName); + addr += 0x1000; + } + packet_reply_add(gdbctx, "\"><segment address=\"0x"); packet_reply_val(gdbctx, addr, sizeof(addr)); packet_reply_add(gdbctx, "\"/></library>"); -- 2.26.0.rc2