From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16332 invoked by alias); 11 Dec 2008 23:41:01 -0000 Received: (qmail 16318 invoked by uid 22791); 11 Dec 2008 23:40:59 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Dec 2008 23:40:24 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBBNcMFU022848; Thu, 11 Dec 2008 18:38:22 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBBNcLmS016818; Thu, 11 Dec 2008 18:38:22 -0500 Received: from opsy.redhat.com (vpn-12-219.rdu.redhat.com [10.11.12.219]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBBNcKJR013720; Thu, 11 Dec 2008 18:38:21 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id D5EE1508027; Thu, 11 Dec 2008 16:38:19 -0700 (MST) To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFA: fix macro expansion bug References: <200812112304.39302.pedro@codesourcery.com> From: Tom Tromey Reply-To: Tom Tromey Date: Thu, 11 Dec 2008 23:41:00 -0000 In-Reply-To: <200812112304.39302.pedro@codesourcery.com> (Pedro Alves's message of "Thu\, 11 Dec 2008 23\:04\:38 +0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2008-12/txt/msg00217.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: >> +gdb_test "macro expand siginfo.si_addr" \ >> + "expands to: siginfo. fields.fault.si_addr" \ Pedro> Just curious, as it's just a visual annoyance: do you know where Pedro> this space comes from? Do we store the definition with the space for Pedro> some reason? We don't get that extra space if the define came Pedro> from the code, instead of from a 'macro define'. Here's a patch to fix it. This requires a minor tweak to the previous patch's test case, but otherwise nothing. As with the previous, I'm sending this through the regression tester, but I don't expect problems. Ok if it passes? Tom 2008-12-11 Tom Tromey * macrocmd.c (macro_define_command): Skip whitespace after macro name. (print_one_macro): Print space after macro name. diff --git a/gdb/macrocmd.c b/gdb/macrocmd.c index 56e9a48..fa639d1 100644 --- a/gdb/macrocmd.c +++ b/gdb/macrocmd.c @@ -315,13 +315,17 @@ macro_define_command (char *exp, int from_tty) } /* Skip the closing paren. */ ++exp; + skip_ws (&exp); macro_define_function (macro_main (macro_user_macros), -1, name, new_macro.argc, (const char **) new_macro.argv, exp); } else - macro_define_object (macro_main (macro_user_macros), -1, name, exp); + { + skip_ws (&exp); + macro_define_object (macro_main (macro_user_macros), -1, name, exp); + } do_cleanups (cleanup_chain); } @@ -358,9 +362,7 @@ print_one_macro (const char *name, const struct macro_definition *macro, macro->argv[i]); fprintf_filtered (gdb_stdout, ")"); } - /* Note that we don't need a leading space here -- "macro define" - provided it. */ - fprintf_filtered (gdb_stdout, "%s\n", macro->replacement); + fprintf_filtered (gdb_stdout, " %s\n", macro->replacement); }