From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13428 invoked by alias); 26 Jul 2007 15:00:10 -0000 Received: (qmail 13419 invoked by uid 22791); 26 Jul 2007 15:00:09 -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:00:06 +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 l6QExh7a017004; Thu, 26 Jul 2007 10:59:43 -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 l6QExhKC020241; Thu, 26 Jul 2007 10:59:43 -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 l6QExgAm017351; Thu, 26 Jul 2007 10:59:42 -0400 Message-ID: <46A8B6DE.6080305@redhat.com> Date: Thu, 26 Jul 2007 15:00:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Kris Van Hees CC: frysk@sourceware.org Subject: Re: Problem with getExe and testInsertedBreakpoint References: <20070726132332.GD20459@ca-server1.us.oracle.com> In-Reply-To: <20070726132332.GD20459@ca-server1.us.oracle.com> 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/msg00190.txt.bz2 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. For context here. The executable name is usually stored in two places, both in the same note: eu-readelf -n core.2843 Note segment of 584 bytes at offset 0x294: Owner Data size Type CORE 124 PRPSINFO state: T (84), zombie: 49, nice: 48 flags: 00400000, uid: 500, gid: 500 pid: 2843, ppid: 2807, pgrp: 2843, sid: 2807 fname: funit-child args: /home/pmuldoon/frysk_bin/frysk-core/frysk/pkglibdir/funit-child 10000 --busy-lo The first is fname, and the second ... assuming no tinkering with the args, is arg[0] in the args list. In the struct elf_prpsinfo, these two are defined as char pr_fname[16]; /* Filename of executable */ char pr_psargs[80]; /* Initial part of arg list */ So the length is limited in the notes section in the core file. There is nothing fcore, or gcore can do to overcome this. The fcore command uses automatic executable location, which tries to find the executable from arg[0], or /usr/bin, or /bin. This is because there are two constructors in dead/LinuxHost. One that just takes just a core file and tries to find the core file itself (with hopefully build-id patches in the future), and one that takes a core file and its corresponding executable. From an api point of view, the latter will always be more accurate. Perhaps fcore and other core file utilities need to utilize the second constructor? Personally I would prefer this approach. > 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. > The truncation is always going to occur in that case :( > 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. > The second constructor in dead/LinuxHost will satisfy that. Anyway, good catch. Regards Phil