From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2920 invoked by alias); 29 Apr 2008 03:05:33 -0000 Received: (qmail 2892 invoked by uid 22791); 29 Apr 2008 03:05:32 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Apr 2008 03:05:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DB5802A97E5; Mon, 28 Apr 2008 23:05:12 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GhWAdDrGBlBx; Mon, 28 Apr 2008 23:05:12 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A116C2A97DC; Mon, 28 Apr 2008 23:05:12 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 323B9E7ACD; Mon, 28 Apr 2008 20:05:10 -0700 (PDT) Date: Tue, 29 Apr 2008 07:01:00 -0000 From: Joel Brobecker To: Nick Roberts Cc: gdb-patches@sourceware.org Subject: Re: Regression in exec.c (print_section_info) ? Message-ID: <20080429030510.GA28505@adacore.com> References: <18453.10856.678467.961230@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <18453.10856.678467.961230@kahikatea.snap.net.nz> User-Agent: Mutt/1.4.2.2i 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-04/txt/msg00648.txt.bz2 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 885 > This works for me, e.g. with "info target" but perhaps there is a bigger > picture and this line was removed for another reason. I reviewed the history of the change, and I think it was an oversight. The change that removed the newline was meant to get rid of some uses of current_gdbarch, no more. Could you test the attached? I think it's generally better for internationalization to have one string rather than put together several string blocks. I doubt it would make much difference in this case, but might as well. I would also like to see a new test if we don't already have one to prevent this type of regression in the future. Please confirm that you did run the patch against the testcase on at least one architecture. One last thing: You also forgot to provide a ChangeLog entry. But *thank you* for sending a unified diff - I just can't read context diffs! -- Joel --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="exec.c.diff" Content-length: 809 Index: exec.c =================================================================== RCS file: /cvs/src/src/gdb/exec.c,v retrieving revision 1.73 diff -u -p -r1.73 exec.c --- exec.c 19 Apr 2008 02:07:19 -0000 1.73 +++ exec.c 29 Apr 2008 03:00:23 -0000 @@ -543,10 +543,8 @@ print_section_info (struct target_ops *t wrap_here (" "); printf_filtered (_("file type %s.\n"), bfd_get_target (abfd)); if (abfd == exec_bfd) - { - printf_filtered (_("\tEntry point: ")); - fputs_filtered (paddress (bfd_get_start_address (abfd)), gdb_stdout); - } + printf_filtered (_("\tEntry point: %s\n"), + paddress (bfd_get_start_address (abfd))) for (p = t->to_sections; p < t->to_sections_end; p++) { printf_filtered ("\t%s", hex_string_custom (p->addr, wid)); --VbJkn9YxBvnuCH5J--