From: Roland Schwingel <roland@onevision.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v2] Add dll trampoline code handling for windows 64bit
Date: Thu, 15 Mar 2012 14:57:00 -0000 [thread overview]
Message-ID: <4F62032B.3000907@onevision.com> (raw)
In-Reply-To: <4F609EB7.2020801@onevision.com>
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
Hi...
Here is a new version of my patch from yesterday. I took (hopefully
correct) all
suggestions regarding formatting and indention into account. If there is
still
something wrong just tell me.
Regarding my byteswap code:
I spent nearly the whole day investigating that up and down. I can't use
the gdb read_memory functions here that do endianness conversion. I stepped
down many times the read_memory functions over all frames until the
point where the memory is read from the inferior using windows native
function ReadProcessMemory(). It appears that - in this case - the memory
returned is rotated by 2 bytes.
Example: Function pointer in a dll is eg: 0x0000000015027bba
In little endian it would be: 0xba7b021500000000
The ReadProcessMemory() call in windows-nat.c in function
windows_xfer_memory() always returns this:
0x021500000000ba7b
In all other cases the memory returned appears not to be rotated.
I also tried reading byte/word/int-wise but the result did not change.
I also queried the internet a long time but could not find any clear
explanation for this. So I left a comment in the patch at this point
as the result delivered by the new function represents the right
function pointer in any case I have checked.
Regarding Copyright Assignment:
As soon as I get the email from Tom I will do everything explained there
and send it in.
ChangeLog:
2012-03-15 Roland Schwingel <roland.schwingel@onevision.com>
* amd64-windows-tdep.c: #include "frame.h".
(amd64_windows_skip_trampoline_code): New function.
(amd64_windows_init_abi): Add trampoline registration.
Roland
[-- Attachment #2: amd64-windows-tdep.c.patch --]
[-- Type: text/plain, Size: 2665 bytes --]
--- amd64-windows-tdep.c_orig 2012-03-02 01:06:12.000000000 +0100
+++ amd64-windows-tdep.c 2012-03-15 15:37:45.647047400 +0100
@@ -23,6 +23,7 @@
#include "gdbtypes.h"
#include "gdbcore.h"
#include "regcache.h"
+#include "frame.h"
/* The registers used to pass integer arguments during a function call. */
static int amd64_windows_dummy_call_integer_regs[] =
@@ -153,12 +154,65 @@
return pc;
}
+/* Check win64 DLL jmp trampolines and find jump destination. */
+
+static CORE_ADDR
+amd64_windows_skip_trampoline_code (struct frame_info *frame, CORE_ADDR pc)
+{
+ CORE_ADDR destination = 0;
+ struct gdbarch *gdbarch = get_frame_arch (frame);
+ enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+
+ /* Check for jmp *<offset>(%rip) (jump near, absolute indirect (/4)). */
+ if (pc && read_memory_unsigned_integer (pc, 2, byte_order) == 0x25ff)
+ {
+ /* Get opcode offset and see if we can find a reference in our data. */
+ ULONGEST indirect =
+ read_memory_unsigned_integer (pc + 2, 4, byte_order);
+ struct minimal_symbol *indsym =
+ indirect ? lookup_minimal_symbol_by_pc (pc + indirect) : 0;
+ const char *symname = indsym ? SYMBOL_LINKAGE_NAME (indsym) : 0;
+
+ if (symname)
+ {
+ if (strncmp (symname, "__imp_", 6) == 0
+ || strncmp (symname, "_imp_", 5) == 0)
+ {
+ gdb_byte *pos,addr[8];
+
+ read_memory(pc + indirect, addr, 8);
+ /* The data fetched from the inferior is in this
+ case not little endian, 2 bytes from the
+ beginning are rotated to the end.
+ Example:
+ function pointer expected in little endian:
+ 0xba7b021500000000
+ pointer fetched from inferior:
+ 0x021500000000ba7b
+ So I do byteswapping here on my own. */
+ pos = (gdb_byte *)&destination;
+ pos[0] = addr[6];
+ pos[1] = addr[7];
+ pos[2] = addr[0];
+ pos[3] = addr[1];
+ pos[4] = addr[2];
+ pos[5] = addr[3];
+ pos[6] = addr[4];
+ pos[7] = addr[5];
+ }
+ }
+ }
+ return destination;
+}
static void
amd64_windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+ /* register trampoline handling code */
+ set_gdbarch_skip_trampoline_code (gdbarch, amd64_windows_skip_trampoline_code);
+
amd64_init_abi (info, gdbarch);
/* On Windows, "long"s are only 32bit. */
next prev parent reply other threads:[~2012-03-15 14:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 13:36 [PATCH] " Roland Schwingel
2012-03-14 15:34 ` Tom Tromey
2012-03-14 16:13 ` Joel Brobecker
2012-03-15 14:57 ` Roland Schwingel [this message]
2012-03-15 15:38 ` [PATCH v2] " Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F62032B.3000907@onevision.com \
--to=roland@onevision.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox