From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125454 invoked by alias); 18 Mar 2015 14:56:02 -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 125438 invoked by uid 89); 18 Mar 2015 14:56:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Mar 2015 14:55:58 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id AC5B42D05DF8; Wed, 18 Mar 2015 15:55:55 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYoYxQT8LD7I; Wed, 18 Mar 2015 15:55:55 +0100 (CET) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 9805C2D05D7F; Wed, 18 Mar 2015 15:55:55 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: [Patch] Fix windows 64 unwinding issues From: Tristan Gingold In-Reply-To: <550943A3.70709@redhat.com> Date: Wed, 18 Mar 2015 14:56:00 -0000 Cc: " ml" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D4C0DC1-2CE7-4C9B-9CA1-1BC13B0FC9E1@adacore.com> <550943A3.70709@redhat.com> To: Pedro Alves X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00544.txt.bz2 > On 18 Mar 2015, at 10:21, Pedro Alves wrote: >=20 > Hi Tristan, >=20 > Looks good to me. Thanks for the investigations and adding > comments. >=20 > Please fix the nits below and push. Thanks for the review. Just pushed with the nits fixed. Tristan. >=20 > On 03/05/2015 01:42 PM, Tristan Gingold wrote: >=20 >>=20 >> commit da3b5213dc072fca195451a04f35a2eb6342bb62 >> Author: Tristan Gingold >> Date: Thu Mar 5 14:36:32 2015 +0100 >>=20 >> Fix amd64 windows unwinding issues within MS dlls. >>=20 >> Unwind info in system dlls uses almost all possible codes, contrary t= o unwind >> info generated by gcc. A few issues have been discovered: incorrect = handling >> of SAVE_NONVOL opcodes and incorrect in prologue range checks. Furth= ermore I >> added comments not to forget what has been investigated. >>=20 >> 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. >>=20 >> 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 =3D cache->sp; >> struct gdbarch *gdbarch =3D get_frame_arch (this_frame); >> enum bfd_endian byte_order =3D gdbarch_byte_order (gdbarch); >> - int j; >> + int first =3D 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 unwi= nding, >> + 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. >=20 > tabs/spaces here don't look right. >=20 >> + 2. Chained unwind_info entries, with no unwind codes (no prologue). >> + There is a major difference with the previous case: the pc rang= e 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 >=20 > Likewise. >=20 >> + 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 >=20 > Typo "additionnal". >=20 >> + entries. >> + 3. Undocumented unwind info redirection. Hard to know the exact p= urpose, >> + so it is considered as a memory optimization of case 2. >> + */ >>=20 >> - for (j =3D 0; ; j++) >> + if (unwind_info & 1) >> + { >> + /* Unofficially documented unwind info redirection, when UNWIND_I= NFO >> + 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)) !=3D 0) >> + return; >> + >> + cache->start_rva =3D >> + extract_unsigned_integer (d.rva_BeginAddress, 4, byte_order); >=20 > "=3D" goes on the next line. >=20 >> + cache->end_rva =3D >> + extract_unsigned_integer (d.rva_EndAddress, 4, byte_order); >> + unwind_info =3D >> + extract_unsigned_integer (d.rva_UnwindData, 4, byte_order); >> + } >=20 > Thanks, > Pedro Alves >=20