From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18392 invoked by alias); 1 May 2008 18:07:00 -0000 Received: (qmail 18383 invoked by uid 22791); 1 May 2008 18:06:58 -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; Thu, 01 May 2008 18:06:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2B8042A99FA; Thu, 1 May 2008 14:06:28 -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 vTTWQ4kZCBtB; Thu, 1 May 2008 14:06:28 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id BDA472A99F2; Thu, 1 May 2008 14:06:27 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 5EB0BE7ACD; Thu, 1 May 2008 11:06:25 -0700 (PDT) Date: Thu, 01 May 2008 18:07:00 -0000 From: Joel Brobecker To: Nick Roberts Cc: gdb-patches@sourceware.org Subject: Re: Regression in exec.c (print_section_info) ? Message-ID: <20080501180625.GC3801@adacore.com> References: <18453.10856.678467.961230@kahikatea.snap.net.nz> <20080429030510.GA28505@adacore.com> <18454.51085.276103.301144@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <18454.51085.276103.301144@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-05/txt/msg00014.txt.bz2 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1760 > > 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. > > It's easy to create a test for this specific case but I think it's > very hard to test the exact format of all CLI output in general, and > probably not worth the effort. The next regression will likely occur > elsewhere. I disagree. We already do a lot of testing of CLI output, and even if we didn't, we have to start somewhere. "The next regression will likely occur elsewhere" might be true, but that doesn't rule out the possibility of regressing again. Since it is easy to create a test, why not just do it, even if you think it's not going to bring actual gain? I like to think of it as insurance. I hope that it will prove useless, but it's still there if I need it. > I only have one architecture: my old PC. That's perfect. > I didn't really think of it as a patch, I was just trying to draw > attention to the regression. This approach is too casual for me. Everyone else writes a ChangeLog, which takes at most 1 min of your time. Please follow this part of the procedure, so that I can review the ChangeLog entry as well. > Actually it was a context diff - so you can read them! They just look > similar when lines are added. Argh. Consider sending unified diffs, I think others prefer them too. When I see context diffs, I usually end up converting it to unified... Anyway, I ended up checking the attached: 2008-05-01 Nick Roberts * exec.c (print_section_info): Add missing '\n'. 2008-05-01 Joel Brobecker * gdb.base/info-target.exp: New testcase. Tested on x86-linux. The new testcase fails without the change to exec.c. -- Joel --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="exec.c.diff" Content-length: 839 Index: exec.c =================================================================== RCS file: /cvs/src/src/gdb/exec.c,v retrieving revision 1.73 retrieving revision 1.74 diff -u -p -r1.73 -r1.74 --- exec.c 19 Apr 2008 02:07:19 -0000 1.73 +++ exec.c 1 May 2008 17:46:32 -0000 1.74 @@ -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)); --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="info-target.exp" Content-length: 1471 # Copyright 2008 Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see . if $tracelevel then { strace $tracelevel } set prms_id 0 set bug_id 0 set testfile start set srcfile ${testfile}.c set binfile ${objdir}/${subdir}/${testfile} if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { return -1 } gdb_exit gdb_start gdb_reinitialize_dir $srcdir/$subdir gdb_load ${binfile} set eol "\[\r\n\]+" # Check the output of "info target". Note that we are not interested # in this case in checking the actual info, but rather to make sure that # it is formatted properly. For instance, make sure that no '\n' is # missing at the end some lines. gdb_test "info target" \ "Symbols from \".*${testfile}.*\"\\..*${eol}Local exec file:${eol}.*Entry point: 0x\[0-9a-zA-Z\]+${eol}.*" \ "info target" --wac7ysb48OaltWcw--