Re: Problem with getExe and testInsertedBreakpoint

[Phil Muldoon <pmuldoon@redhat.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