[Lldb-commits] [patch] implement process launch with a user-specified working directory on Linux

[Greg Clayton]

On Jan 7, 2013, at 2:57 PM, "Malea, Daniel" <daniel.malea at intel.com> wrote:

> Yes there is synchronization; after the fork(), the child process does a ptrace(TRACEME) which causes the OS to stop the process when any signal is delivered. The subsequent call to execve() causes a SIGTRAP, which makes the child wait for lldb to continue it.
> 
> LLDB continues the process automatically when the user doesn't use the "-s" flag. However, when the "process launch -s" is used, lldb will stop somewhere in execve; before the actual child process is started. This behaviour is probably not ideal, as the target doesn't match the actual process image that lldb is debugging until the execve replaces the lldb image with the target's. As a result, it's not possible to see any backtrace or any meaningful information during this "transition period"...but at least the debugger won't miss any progress in the child.

Gotcha.

> 
> Out of curiosity, what's the ideal stopping place when starting a subprocess with the "stop-on-start"? I imagine the debugger should stop before main() is invoked... is the "_start" symbol reasonable? It shouldn't be too difficult to implement The Right Thing here.

Currently on MacOSX we stop at "__dyld_start" which is before any user code gets called, and this function will call all initializers and go directly to main.

A while ago there was glue inserted into the code which would stop at "_start", when then calls initializers and proceeds to main. I believe linux is this way but I could be wrong.

> Another question, what do you think about adding a shorthand version of "process launch -s" called "start" like GDB has? We have "run" but not "start".

That is fine to add as an alias.

> 
> Dan
> 
> 
> On 2013-01-07, at 4:49 PM, Greg Clayton wrote:
> 
> Gotcha. As long as the chdir is in the child process, the patch looks good.
> 
> Just curious: is there some anything that syncs with the child process from the parent while it has been forked but not exec'ed? This is a nice way to ensure you are connected to the process before it makes any progress since there is nothing on linux that says "start the process stopped for a debugger"...
> 
> Greg
> 
> On Jan 7, 2013, at 1:27 PM, "Malea, Daniel" <daniel.malea at intel.com<mailto:daniel.malea at intel.com>> wrote:
> 
> Hi Greg,
> 
> Thanks for looking into this. I agree, posix_spawn() would be really nice to use in lieu of the current approach, but since it is missing the ability to set working directories, I think it's a non-starter.
> 
> Currently on Linux, process starting works via a fork(), then in the child a call is made to chdir() and exec(). Since the chdir() happens after the fork() it shouldn't affect the parent host "lldb" instance cwd.
> 
> Dan
> 
> 
> 
> On 2013-01-07, at 12:51 PM, Greg Clayton wrote:
> 
> Calling "chdir" in process will change the working directory for the "lldb" binary. On MacOSX we use a thread specific version of chdir to minimize this affect, but that also only occurs in "debugserver" since all debugging on MacOSX is done remotely even on local machine.
> 
> It is really a shame that posix_spawn() doesn't have an attribute to set the working directory.
> 
> How does launching happen on Linux right now? The safest way to do this would be to fork, then chdir, then posix_spawn with exec only (if this is possible on linux/FreeBSD). This would eliminate the cwd from changing in the host "lldb".
> 
> Greg
> 
> On Jan 4, 2013, at 4:43 PM, "Malea, Daniel" <daniel.malea at intel.com<mailto:daniel.malea at intel.com>> wrote:
> 
> Hi all,
> 
> I noticed that on Linux (and FreeBSD) the working directory specified to the “process launch” command is ignored. Here’s a patch that implements the correct behaviour on Linux by propagating the working directory string down through ProcessPOSIX and ProcessMonitor, and eventually just calls ::chdir() before launching the inferior process.
> 
> It’s all pretty straight forward, but since there’s a common interface with FreeBSD (ProcessMonitor) that I had to modify the constructor of, I figured I’d ask here if someone could take a look when they have a spare moment.
> 
> This patch fixes the TestProcessLaunch test case.
> 
> Thanks in advance,
> Dan
> 
> 
> Daniel Malea daniel.malea at intel.com<mailto:daniel.malea at intel.com>
> Intel Embedded Computing, Debuggers & Libraries
> Intel Waterloo
> 
> <working_dir.patch>_______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu<mailto:lldb-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> 
> 
> Daniel Malea <daniel.malea at intel.com<mailto:daniel.malea at intel.com>>
> Intel Waterloo
> Phone: 519-772-2566
> 
> 
> 
> Daniel Malea <daniel.malea at intel.com<mailto:daniel.malea at intel.com>>
> Intel Waterloo
> Phone: 519-772-2566
>