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).

Does that make sense/would that work?

Cheers,

Mark