[Lldb-commits] Bug 16443 - target create doesn't expand ~ on Linux

Matthew Sorrels sorrels.m at gmail.com
Fri Jul 5 09:08:08 PDT 2013


I believe this patch passes all the test suites.  Though to be fair there
really aren't tests for handling ~ expansion.  If you could go ahead and
commit this that would be great.



On Tue, Jul 2, 2013 at 12:46 PM, Greg Clayton <gclayton at apple.com> wrote:

> As long as the test suite passes, this looks good.
>
> On Jul 2, 2013, at 11:37 AM, Matthew Sorrels <sorrels.m at gmail.com> wrote:
>
> > Any comments on this?
> >
> >
> > On Wed, Jun 26, 2013 at 3:41 PM, Matthew Sorrels <sorrels.m at gmail.com>
> wrote:
> > This changes TargetList so that it will expand the ~ cases, but not
> process any symbolic links while doing so.  It does this by using the
> FileSpec::ResolveUsername function directly.  It seems to work on cases
> where the binary is something like ~/a.out it also works on cases where the
> binary is a symbolic link ~/mytest the arg0 passed in is mytest and not
> a.out.
> >
> > Index: source/Target/TargetList.cpp
> > ===================================================================
> > --- source/Target/TargetList.cpp    (revision 185025)
> > +++ source/Target/TargetList.cpp    (working copy)
> > @@ -221,8 +221,19 @@
> >
> >      FileSpec file (user_exe_path, false);
> >      if (!file.Exists() && user_exe_path && user_exe_path[0] == '~')
> >      {
> > -        file = FileSpec(user_exe_path, true);
> > +        // we want to expand the tilde but we don't want to resolve any
> symbolic links
> > +        // so we can't use the FileSpec constructor's resolve flag
> > +        char unglobbed_path[PATH_MAX];
> > +        unglobbed_path[0] = '\0';
> > +
> > +        size_t return_count = FileSpec::ResolveUsername(user_exe_path,
> unglobbed_path, sizeof(unglobbed_path));
> > +
> > +        if (return_count == 0 || return_count >= sizeof(unglobbed_path))
> > +            ::snprintf (unglobbed_path, sizeof(unglobbed_path), "%s",
> user_exe_path);
> > +
> > +        file = FileSpec(unglobbed_path, false);
> >      }
> > +
> >      bool user_exe_path_is_bundle = false;
> >      char resolved_bundle_exe_path[PATH_MAX];
> >      resolved_bundle_exe_path[0] = '\0';
> > @@ -304,8 +315,8 @@
> >
> >              }
> >              else
> >              {
> > -                // Just use what the user typed
> > -                target_sp->SetArg0 (user_exe_path);
> > +                // Use resolved path
> > +                target_sp->SetArg0 (file.GetPath().c_str());
> >              }
> >          }
> >          if (file.GetDirectory())
> >
> >
> >
> > On Tue, Jun 25, 2013 at 1:47 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> > This patch will break people who try and do the following:
> >
> > % lldb /usr/bin/clang++
> >
> > clang++ is a symlink to "/usr/bin/clang". When we debug the program and
> it reaches main, clang will look at argv[0] and do something if the program
> is clang++ and something else if it is clang. We really want to _just_
> resolve the "~" or the "~username" from the path and leave the rest alone
> so we don't change argv[0] from what the user specified.
> >
> > On Jun 25, 2013, at 1:29 PM, Matthew Sorrels <sorrels.m at gmail.com>
> wrote:
> >
> > > Bug 16443 - target create doesn't expand ~ on Linux
> > >
> > > I created a bug for this, but it wasn't as complex to fix as I had
> thought.  Though I'm not exactly sure what the effects this change could
> have.  The test suite runs the same on Linux with or without it, but I'm
> not sure that's enough.  It does seem like the code went out of its way to
> set the arg0 to be whatever the user typed, rather than the resolved path.
>  Perhaps there is a reason for this I don't understand?
> > >
> > >
> > > Here's the bug summary:
> > > If you start lldb and do a target create on a path with a ~ as part of
> the path, it is accepted but when trying to run the process the launch
> fails.
> > >
> > > Here's an example where the test binary is ~/a.out  it is also
> /home/matthews/a.out which works fine.  Both paths work fine when used on
> the command line (most likely due to shell expansion)
> > >
> > > matthews at matthews-linux:~/work/llvm/llvm/build$ bin/lldb
> > > (lldb) version
> > > lldb version 3.4 (
> > > http://llvm.org/svn/llvm-project/lldb/trunk
> > >  revision 184861)
> > > (lldb) target create ~/a.out
> > > Current executable set to '~/a.out' (x86_64).
> > > (lldb) run
> > > error: process launch failed: Child exec failed.
> > >
> > >
> > > (lldb) target create /home/matthews/a.out
> > > Current executable set to '/home/matthews/a.out' (x86_64).
> > > (lldb) run
> > > Process 4493 launched: '/home/matthews/a.out' (x86_64)
> > > Hello world!
> > > Function 106
> > > Process 4493 exited with status = 13 (0x0000000d)
> > > (lldb)
> > >
> > > The target list command shows the full path to the file, but that full
> path isn't being used when the process is started with run.
> > >
> > > (lldb) target create ~/a.out
> > > Current executable set to '~/a.out' (x86_64).
> > > (lldb) target list
> > > Current targets:
> > > * target #0: /home/matthews/a.out ( arch=x86_64--linux,
> platform=localhost )
> > >
> > >
> > > Here's a possible patch:
> > >
> > > Index: source/Target/TargetList.cpp
> > > ===================================================================
> > > --- source/Target/TargetList.cpp    (revision 184861)
> > > +++ source/Target/TargetList.cpp    (working copy)
> > > @@ -304,8 +304,8 @@
> > >              }
> > >              else
> > >              {
> > > -                // Just use what the user typed
> > > -                target_sp->SetArg0 (user_exe_path);
> > > +                // Use resolved path
> > > +                target_sp->SetArg0 (file.GetPath().c_str());
> > >              }
> > >          }
> > >          if (file.GetDirectory())
> > >
> > > _______________________________________________
> > > lldb-commits mailing list
> > > lldb-commits at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130705/cb1e51f8/attachment.html>


More information about the lldb-commits mailing list