public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: frysk@sourceware.org
Subject: Re: Problem with getExe and testInsertedBreakpoint
Date: Thu, 26 Jul 2007 13:58:00 -0000	[thread overview]
Message-ID: <1185458316.3630.57.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <20070726132332.GD20459@ca-server1.us.oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-07-26 13:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-26 13:23 Kris Van Hees
2007-07-26 13:58 ` Mark Wielaard [this message]
2007-07-26 15:35   ` Phil Muldoon
2007-07-26 18:57     ` Mark Wielaard
2007-07-26 19:32       ` Phil Muldoon
2007-07-27 10:00         ` Mark Wielaard
2007-07-27 13:41           ` Phil Muldoon
2007-07-27 19:04           ` Roland McGrath
2007-07-31  9:57             ` Mark Wielaard
2007-07-31 10:18               ` Roland McGrath
2007-07-26 15:00 ` Phil Muldoon
2007-07-26 15:03   ` Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1185458316.3630.57.camel@dijkstra.wildebeest.org \
    --to=mark@klomp.org \
    --cc=frysk@sourceware.org \
    --cc=kris.van.hees@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).