From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3397 invoked by alias); 26 Jul 2007 15:35:05 -0000 Received: (qmail 3389 invoked by uid 22791); 26 Jul 2007 15:35:04 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jul 2007 15:34:58 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6QFYFie009887; Thu, 26 Jul 2007 11:34:15 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6QFYEaB015064; Thu, 26 Jul 2007 11:34:14 -0400 Received: from localhost.localdomain (dhcp-232.hsv.redhat.com [172.16.17.232]) by pobox.hsv.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l6QFYDfT022513; Thu, 26 Jul 2007 11:34:13 -0400 Message-ID: <46A8BEF5.1080706@redhat.com> Date: Thu, 26 Jul 2007 15:35:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Mark Wielaard CC: Kris Van Hees , frysk@sourceware.org Subject: Re: Problem with getExe and testInsertedBreakpoint References: <20070726132332.GD20459@ca-server1.us.oracle.com> <1185458316.3630.57.camel@dijkstra.wildebeest.org> In-Reply-To: <1185458316.3630.57.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00194.txt.bz2 Mark Wielaard wrote: > Hi Kris, > > On Thu, 2007-07-26 at 06:23 -0700, Kris Van Hees wrote: > >> 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. >> > > Nice catch. But the test case seems to actually be testing the wrong > thing. It should test the symbols found in the actual core file, but it > tries to open Proc.getExe() which points to the (truncated) path of the > executable that created the core file. > > >> 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. >> > > As pointed out earlier today in the fexe command thread it would be nice > to split getExe() into 2 semantically different things. > > 1) String Proc.getExeName(); > Which provides the possible name of the executable. Using /proc/pid/exe > symlink following or the name stored in the core file. Both might not be > completely accurate because they were truncated or moved. This should be > used to display to the user what command was run. > 2) File Proc.getExeFile(); > Which provides the actual file path to open to get at the elf image > (/proc/pid/exe opened "raw", not following the symlink, or the actual > File that the core file was loaded from). > When a core file is modeled in Frysk, it could be a long time from when the core was created. An executable file might not be even available at that time. For this reason there are two layers of meta data built: 1) Basic meta-data. No executable available. No maps can be produced (but address ranges can). No solib tables can be built. No elided segment memory access. At this point we can model the information that is in the core file, and allow access to non-elided sections of the core file. This is basic inspection. Can't do much other than look at memory, and registers. 2) Enhanced meta-data. Executable is available. In this case we can find where the link-map was in the core file when it was dumped by looking at the executable's dynamic segment. We can build a table of what solibs were loaded and mapped into the process when it was dumped, and we can build a "rich" set of maps almost identical to what you would get in /proc/$$/maps. We can now allow elided memory access because we know what solib is at which address, so the host can open that solib and read that memory. This allows sophisticated operations as stack back traces, and so on. At no time is an executable ever loaded into memory during this process, or at any time. It's all simulated via CorefileByteBuffer, and dead/LinuxHost. The process might "look" alive from the interface, but it is well and truly, and probably forever will be, dead ;) All these operations are done by looking at the Elf image on disk. So relying on anything in /proc/$$ won't work in that instance. Hope that sheds a bit of light. Regards Phil