From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21618 invoked by alias); 15 Mar 2012 14:57:11 -0000 Received: (qmail 21608 invoked by uid 22791); 15 Mar 2012 14:57:09 -0000 X-SWARE-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,BAYES_20,KAM_STOCKGEN X-Spam-Check-By: sourceware.org Received: from outdoor.onevision.de (HELO outdoor.onevision.de) (212.77.172.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Mar 2012 14:56:55 +0000 Received: from sanders.onevision.de (moonrace [212.77.172.62]) by outdoor.onevision.de (8.14.3/8.13.7/ROSCH/DDB) with ESMTP id q2FEumDN011483 for ; Thu, 15 Mar 2012 15:56:53 +0100 Received: from [192.168.5.32] ([192.168.5.32]) by sanders.onevision.de (Lotus Domino Release 8.5.1FP3) with ESMTP id 2012031515564316-116254 ; Thu, 15 Mar 2012 15:56:43 +0100 Message-ID: <4F62032B.3000907@onevision.com> Date: Thu, 15 Mar 2012 14:57:00 -0000 From: Roland Schwingel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [PATCH v2] Add dll trampoline code handling for windows 64bit References: <4F609EB7.2020801@onevision.com> In-Reply-To: <4F609EB7.2020801@onevision.com> Content-Type: multipart/mixed; boundary="------------040104070406060703000100" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00538.txt.bz2 This is a multi-part message in MIME format. --------------040104070406060703000100 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-length: 1623 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 * amd64-windows-tdep.c: #include "frame.h". (amd64_windows_skip_trampoline_code): New function. (amd64_windows_init_abi): Add trampoline registration. Roland --------------040104070406060703000100 Content-Transfer-Encoding: 7bit Content-Type: text/plain; name="amd64-windows-tdep.c.patch" Content-Disposition: attachment; filename="amd64-windows-tdep.c.patch" Content-length: 2665 --- 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 *(%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. */ --------------040104070406060703000100--