From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25646 invoked by alias); 26 Jul 2007 13:23:40 -0000 Received: (qmail 25638 invoked by uid 22791); 26 Jul 2007 13:23:39 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME X-Spam-Check-By: sourceware.org Received: from rgminet01.oracle.com (HELO rgminet01.oracle.com) (148.87.113.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jul 2007 13:23:38 +0000 Received: from rgmsgw01.us.oracle.com (rgmsgw01.us.oracle.com [138.1.186.51]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l6QDNYcm004253 for ; Thu, 26 Jul 2007 07:23:34 -0600 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmsgw01.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l6QDNXpg023553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 07:23:34 -0600 Received: from kvanhees by ca-server1.us.oracle.com with local (Exim 4.63) (envelope-from ) id 1IE3JV-00081O-7v for frysk@sourceware.org; Thu, 26 Jul 2007 06:23:33 -0700 Date: Thu, 26 Jul 2007 13:23:00 -0000 From: Kris Van Hees To: frysk@sourceware.org Subject: Problem with getExe and testInsertedBreakpoint Message-ID: <20070726132332.GD20459@ca-server1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00187.txt.bz2 Recently, a problem has surfaced related to getExe() in relation to core files and its use in the testInsertedBreakpoint() test. Specifically, the core file seems to store the first 79 characters of the full executable pathname only. This results in truncation in cases where the frysk build tree is located fairly far down a directory hierarchy (which is a implicit test in itself), and the testInsertedBreakpoint test tries to read the executable using a truncated (and thus invalid) executable path name. As far as the test is concerned, I think it might be easiest to simply use the (known) path name to the executable name directly because this particular test is *not* verifying whether the getExe() processing works. Avoiding this problem altogether in this test will at least avoid the current problem. Whether this problem can be resolved in general remains to be seen. If the executable name is simply not available, there is nothing we can do. However, there might be a tiny hope that we can get to the executable path name anyway. Running 'strings' on the core files I checked displays the untruncated version twice. I'm currently looking whether there is a clean, dependable way to get to that information. Cheers, Kris