This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: Problem with getExe and testInsertedBreakpoint
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Kris Van Hees <kris dot van dot hees at oracle dot com>
- Cc: frysk at sourceware dot org
- Date: Thu, 26 Jul 2007 09:59:42 -0500
- Subject: Re: Problem with getExe and testInsertedBreakpoint
- References: <20070726132332.GD20459@ca-server1.us.oracle.com>
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