From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4334 invoked by alias); 24 Apr 2008 15:59:05 -0000 Received: (qmail 4325 invoked by uid 22791); 24 Apr 2008 15:59:04 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Apr 2008 15:58:43 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw1.br.ibm.com (Postfix) with ESMTP id 0268432C1B0 for ; Thu, 24 Apr 2008 12:35:43 -0300 (BRST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3OFwbhp2121848 for ; Thu, 24 Apr 2008 12:58:39 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3OFwQlv011678 for ; Thu, 24 Apr 2008 12:58:26 -0300 Received: from [9.18.238.201] (gargoyle.br.ibm.com [9.18.238.201]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3OFwQoO011278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Apr 2008 12:58:26 -0300 Subject: [RFC] Entry point update with "run" command From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: gdb-patches@sourceware.org Content-Type: multipart/mixed; boundary="=-jthBoqtWIOOQ/FkaA9t9" Date: Thu, 24 Apr 2008 16:45:00 -0000 Message-Id: <1209052694.18229.6.camel@gargoyle.br.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-IsSubscribed: yes 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/msg00559.txt.bz2 --=-jthBoqtWIOOQ/FkaA9t9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 825 Hi folks, It seems GDB doesn't really update the entry point of an object file if we "reload" the modified binary through the "run" command. This can be clearly seen with the reread.exp testcase: 1 - Run reread until "foo" breakpoint 2 - Move reread2 on top of reread 3 - "Run" and expect GDB to notice that the binary has changed 4 - GDB says it will re-read the symbols 5 - The entry point of the second binary is just the same as the first one. This causes problems with the displaced stepping since the entry point is used to store the instructions. The problem is that "init_entry_point_info" is never called with the "run" command. If we do a "file", then we get the right entry point. The attached patch does this on "reread_symbols", though it seems a brute-force method. Is this OK? Regards -- Luis Machado --=-jthBoqtWIOOQ/FkaA9t9 Content-Disposition: attachment; filename=entry_point.diff Content-Type: text/x-patch; name=entry_point.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 405 Index: hg/gdb/symfile.c =================================================================== --- hg.orig/gdb/symfile.c 2008-04-24 08:09:30.000000000 -0700 +++ hg/gdb/symfile.c 2008-04-24 08:45:50.000000000 -0700 @@ -2467,6 +2467,7 @@ objfile->mtime = new_modtime; reread_one = 1; reread_separate_symbols (objfile); + init_entry_point_info (objfile); } } } --=-jthBoqtWIOOQ/FkaA9t9--