From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109299 invoked by alias); 15 Apr 2016 00:30:22 -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 109218 invoked by uid 89); 15 Apr 2016 00:30:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=periods, busy, person, our X-HELO: nm19-vm4.bullet.mail.ne1.yahoo.com Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (HELO nm19-vm4.bullet.mail.ne1.yahoo.com) (98.138.91.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 15 Apr 2016 00:30:09 +0000 Received: from [98.138.101.132] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 15 Apr 2016 00:30:07 -0000 Received: from [98.138.226.128] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 15 Apr 2016 00:29:07 -0000 Received: from [127.0.0.1] by smtp215.mail.ne1.yahoo.com with NNFMP; 15 Apr 2016 00:29:07 -0000 X-Yahoo-SMTP: uLlXihWswBAw_asaF5e6lP5gQBt5Jmin Subject: Re: [PATCH] Negative repeat count for 'x' command To: Pedro Alves , 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> Cc: Paul_Koning@Dell.com, andrew.burgess@embecosm.com, jhb@freebsd.org From: Toshihito Kikuchi Message-ID: <571035CC.7060802@yahoo.de> Date: Fri, 15 Apr 2016 00:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570B95AE.80406@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00340.txt.bz2 Hi Pedro, We know we all are busy with our main work :). I walked through all of your comments. Thank you for the thorough review. Especially your suggestion for find_pc_sect_line gdb_insn_length is really helpful. These functions are what I was looking for. Well, I was not a patient person, so I've started a V2 thread two weeks ago. (https://sourceware.org/ml/gdb-patches/2016-04/msg00023.html) The difference between V1 and V2 was only NEWS file. Please ignore it. Once I address all of the comments, I'll start a V3 thread. 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? > Typo "previoius". Double-space after periods. This recursion sounds > nasty -- sounds like if you request a high number of addresses, crossing > many lines, we'll hit stack limits. Can we do without recursion? Yeah, actually this was a painful part. Let me rethink a better algorithm without using recursive calls (and VEC if possible). >> + } >> + >> /* Print as many objects as specified in COUNT, at most maxelts per line, >> with the address of the next one at the start of each line. */ >> >> @@ -913,6 +1164,9 @@ do_examine (struct format_data fmt, struct gdbarch *gdbarch, CORE_ADDR addr) >> printf_filtered ("\n"); >> gdb_flush (gdb_stdout); >> } >> + >> + if (addr_rewound) > > addr_rewound != 0 > > But actually, please make sure that "address == 0" is treated as a > valid address (not just here, but in the whole patch), as it is valid > on non-MMU machines. That may suggest using a separate boolean variable > to represent "have address". Thank you for the insightful comment! I never thought non-MMU architectures.. >> + >> + const char TestStrings[] = { >> + "ABCD" >> + "EFGHIJKLMNOPQRSTUVWXYZ\0" >> + "\0" >> + "\0" >> + "\u307B\u3052\u307B\u3052\0" >> + "012345678901234567890123456789\0" >> + "!!!!!!\0" >> + }; >> +*/ >> + >> +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? Thanks, Toshihito