From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110192 invoked by alias); 18 Mar 2015 09:21:46 -0000 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 Received: (qmail 110181 invoked by uid 89); 18 Mar 2015 09:21:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Mar 2015 09:21:44 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2I9LfFm016651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Mar 2015 05:21:41 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2I9LdHA005900; Wed, 18 Mar 2015 05:21:40 -0400 Message-ID: <550943A3.70709@redhat.com> Date: Wed, 18 Mar 2015 09:21:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tristan Gingold , " ml" Subject: Re: [Patch] Fix windows 64 unwinding issues References: <2D4C0DC1-2CE7-4C9B-9CA1-1BC13B0FC9E1@adacore.com> In-Reply-To: <2D4C0DC1-2CE7-4C9B-9CA1-1BC13B0FC9E1@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00536.txt.bz2 Hi Tristan, Looks good to me. Thanks for the investigations and adding comments. Please fix the nits below and push. On 03/05/2015 01:42 PM, Tristan Gingold wrote: > > commit da3b5213dc072fca195451a04f35a2eb6342bb62 > Author: Tristan Gingold > Date: Thu Mar 5 14:36:32 2015 +0100 > > Fix amd64 windows unwinding issues within MS dlls. > > Unwind info in system dlls uses almost all possible codes, contrary to unwind > info generated by gcc. A few issues have been discovered: incorrect handling > of SAVE_NONVOL opcodes and incorrect in prologue range checks. Furthermore I > added comments not to forget what has been investigated. > > gdb/ChangeLog: > * amd64-windows-tdep.c (amd64_windows_find_unwind_info): Move > redirection code to ... > (amd64_windows_frame_decode_insns): ... Here. Fix in prologue > checks. Fix SAVE_NONVOL operations. Add debug code and comments. > > diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c > index 2aa10a1..9278a26 100644 > --- a/gdb/amd64-windows-tdep.c > +++ b/gdb/amd64-windows-tdep.c > @@ -621,9 +621,47 @@ amd64_windows_frame_decode_insns (struct frame_info *this_frame, > CORE_ADDR cur_sp = cache->sp; > struct gdbarch *gdbarch = get_frame_arch (this_frame); > enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > - int j; > + int first = 1; > + > + /* There are at least 3 possibilities to share an unwind info entry: > + 1. Two different runtime_function entries (in .pdata) can point to the > + same unwind info entry. There is no such indication while unwinding, > + so we don't really care about that case. We suppose this scheme is > + used to save memory when the unwind entries are exactly the same. tabs/spaces here don't look right. > + 2. Chained unwind_info entries, with no unwind codes (no prologue). > + There is a major difference with the previous case: the pc range for > + the function is different (in case 1, the pc range comes from the > + runtime_function entry; in case 2, the pc range for the chained entry > + comes from the first unwind entry). Case 1 cannot be used instead as Likewise. > + the pc is not in the prologue. This case is officially documented. > + (There might be unwind code in the first unwind entry to handle > + additionnal unwinding). GCC (at least until gcc 5.0) doesn't chain Typo "additionnal". > + entries. > + 3. Undocumented unwind info redirection. Hard to know the exact purpose, > + so it is considered as a memory optimization of case 2. > + */ > > - for (j = 0; ; j++) > + if (unwind_info & 1) > + { > + /* Unofficially documented unwind info redirection, when UNWIND_INFO > + address is odd (http://www.codemachine.com/article_x64deepdive.html). > + */ > + struct external_pex64_runtime_function d; > + CORE_ADDR sa, ea; > + > + if (target_read_memory (cache->image_base + (unwind_info & ~1), > + (gdb_byte *) &d, sizeof (d)) != 0) > + return; > + > + cache->start_rva = > + extract_unsigned_integer (d.rva_BeginAddress, 4, byte_order); "=" goes on the next line. > + cache->end_rva = > + extract_unsigned_integer (d.rva_EndAddress, 4, byte_order); > + unwind_info = > + extract_unsigned_integer (d.rva_UnwindData, 4, byte_order); > + } Thanks, Pedro Alves