Patch to Attach pid successfully from different dir

[emaste]

Summary

While using lldb we found the small bug with attaching to the running process.
"attach" works fine when we run the lldb on the same dir where we ran the executable but not if the dir changes.

cd lldb_temp/
./test &

[2] 39044

cd ../
/b/vignesh/lldb_daily_build/20170419_bkup/binaries/bin/lldb

(lldb) attach 39044
error: attach failed: unable to find executable for './test'

I see the lldb using the relative path instead of absolute path of the exe.
Modified the way sysctl gets the exe name to get the absolute path.

[emaste]

Sorry I've been away from LLDB for a bit, I will take a look at this soon.

[emaste]

Slightly simpler approach after early returns added in rL301100

[vbalu]

Fine. This will work. Thanks for the update.

[krytarowski]

I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now.

[emaste]

In D32271#735098, @krytarowski wrote:

I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now.

Thanks for the note. I wasn't aware that you had that planned, but I incorporated the improvements you made in NetBSD's Host.cpp (early returns etc.) in order to reduce diffs and facilitate shared effort on these bits at some point.

[krytarowski]

In D32271#735354, @emaste wrote:

In D32271#735098, @krytarowski wrote:

I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now.

Thanks for the note. I wasn't aware that you had that planned, but I incorporated the improvements you made in NetBSD's Host.cpp (early returns etc.) in order to reduce diffs and facilitate shared effort on these bits at some point.

At the moment at least attach to pid isn't functional on NetBSD.

However good that the NetBSD code helped to improve FreeBSD.

[emaste]

Test case in D32522

[dim]

As I found out in rL303015, the KERN_PROC_PATHNAME has one drawback: if an executable file has multiple hard links, you will get just one of its filenames as the result. Since that filename is more or less randomly chosen, it does *not* have to correspond to the actual argv[0] the executable was invoked with. If that does not matter, this approach is fine, though.

[krytarowski]

If we end up with hard links I think we should change them to symbolic ones. This is a common policy in some open source distributions.

[emaste]

In D32271#759361, @dim wrote:

As I found out in rL303015, the KERN_PROC_PATHNAME has one drawback: if an executable file has multiple hard links, you will get just one of its filenames as the result. Since that filename is more or less randomly chosen, it does *not* have to correspond to the actual argv[0] the executable was invoked with. If that does not matter, this approach is fine, though.

Thanks @dim, it's because of rL303015 that I added you to CC.

Thinking about this further, I think that in this (LLDB) case it's acceptable (even if it might prove slightly surprising). If we attach via -p <pid> this code is used to find the corresponding binary, and even if we open the file by the "wrong" name we still have the correct content.

[vbalu]

if (::sysctl(mib, 4, pathname, &len, NULL, 0) == 0)

"len" is not declared. Please change to "pathname_len".

[emaste]

correct variable

lldb/trunk/source/Host/freebsd/Host.cpp

DataExtractor data(arg_data, arg_data_size, endian::InlHostByteOrder(),
                      sizeof(void *));
   lldb::offset_t offset = 0;
   const char *cstr;
 
   cstr = data.GetCStr(&offset);
   if (!cstr)
     return false;
 
+  // Get pathname for pid. If that fails fall back to argv[0].
+  char pathname[MAXPATHLEN];
+  size_t pathname_len = sizeof(pathname);
+  mib[2] = KERN_PROC_PATHNAME;
+  if (::sysctl(mib, 4, pathname, &pathname_len, NULL, 0) == 0)
+    process_info.GetExecutableFile().SetFile(pathname, false);
+  else
     process_info.GetExecutableFile().SetFile(cstr, false);
 
   if (!(match_info_ptr == NULL ||
         NameMatches(process_info.GetExecutableFile().GetFilename().GetCString(),
                     match_info_ptr->GetNameMatchType(),
                     match_info_ptr->GetProcessInfo().GetName())))
     return false;
 
   Args &proc_args = process_info.GetArguments();