From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11210 invoked by alias); 18 Apr 2016 13:17:48 -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 11050 invoked by uid 89); 18 Apr 2016 13:17:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=literals, H*F:U*palves, Hx-languages-length:1641, HTo:D*yahoo.de 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; Mon, 18 Apr 2016 13:17:44 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0241A7F341; Mon, 18 Apr 2016 13:17:42 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3IDHdKp016685; Mon, 18 Apr 2016 09:17:40 -0400 Subject: Re: [PATCH] Negative repeat count for 'x' command To: Toshihito Kikuchi , gdb-patches@sourceware.org References: <1095889805.138513.1453786618993.JavaMail.yahoo@mail.yahoo.com> <20160127160420.GM3338@embecosm.com> <56AA013F.8010601@redhat.com> <56B7D0E3.8020402@yahoo.de> <570B95AE.80406@redhat.com> <571035CC.7060802@yahoo.de> Cc: Paul_Koning@Dell.com, andrew.burgess@embecosm.com, jhb@freebsd.org From: Pedro Alves Message-ID: <5714DE73.5010104@redhat.com> Date: Mon, 18 Apr 2016 13:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <571035CC.7060802@yahoo.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00400.txt.bz2 On 04/15/2016 01:29 AM, Toshihito Kikuchi wrote: > Let me answer a couple of non-trivial questions. Otherwise fixes will be > included in V3. > >>> +If a negative repeat count is specified for the formats @samp{s} or @samp{i}, >>> +the absolute value of the given number of null-terminated strings or >>> +instructions before the address are displayed. For the @samp{i} format, >>> +we use line number information in the debug info to resolve a correct frame >>> +while dissasembling backward. >> >> What does "a correct frame" mean? > > It seems that I was using a wrong term. Instead of 'frame', does 'procedure > boundary' make sense? Yes, that'd make sense. >>> +const char TestStrings[] = { >>> + 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, >> >> I wonder whether 'A', 'B', etc. would work? > > These test strings contain non-alphabetical characters shown as > "\u307B\u3052\u307B\u3052\0" above, and that syntax is not allowed without C99. > Also, > I want to keep the same style for 1-byte, 2-bytes, and 4-bytes test strings. > That's why I didn't use a character literals here. ... > Do you have any thoughts? Nope. BTW, aren't these tests dependent on the host's charset? (show host-charset) An idea to generalize the x/i tests to all archs would be to let go of the asm, and instead write the test function in C. Then you'd first use forward x/i to store a few line's instructions in a list/array, and afterwards you'd disassemble backwards, comparing with the expected instructions stored in the stored list/array. I wonder whether that'd work. Thanks, Pedro Alves