See my other message.  In a ptrace based system the inferior has to call  
PT_TRACEME to signal it should be stopped at the first instruction.  So you do 
need to run that code.  As I said, Apple added an extension to posix_spawnp to 
do this for us.

Jim


> On Oct 16, 2017, at 2:17 PM, Zachary Turner via lldb-commits 
> <lldb-commits@lists.llvm.org> wrote:
> 
> Ahh wait, sorry.  I meant posix_spawn, not execve
> 
> On Mon, Oct 16, 2017 at 2:16 PM Zachary Turner <ztur...@google.com 
> <mailto:ztur...@google.com>> wrote:
> I guess what I mean is, my understanding is that the only "advantage" (if you 
> can even call it that) of using fork + exec over execve is that fork + exec 
> allows you to run additional code between the fork and the exec.
> 
> Do we actually rely on that?  Why do we need it to do fork at all?  Why can't 
> we just execve from the parent process without doing a fork at all?
> 
> On Mon, Oct 16, 2017 at 2:06 PM Tamas Berghammer <tbergham...@google.com 
> <mailto:tbergham...@google.com>> wrote:
> On linux when you call fork the new process will only have the thread what 
> called fork. Other threads will be ignored with leaving whatever dirty state 
> they had left in the new process. Regarding execve it doesn't do fork so we 
> would have to do fork & execve what have the same issue (actually we are 
> using execve as of now but it isn't different from exec in this regard).
> 
> Tamas
> 
> On Mon, Oct 16, 2017 at 1:57 PM Zachary Turner via lldb-commits 
> <lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>> wrote:
> On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath <lab...@google.com 
> <mailto:lab...@google.com>> wrote:
> On 15 October 2017 at 23:04, Zachary Turner <ztur...@google.com 
> <mailto:ztur...@google.com>> wrote:
> > Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it just
> > release at the end of the function?
> 
> 
> The thing is, it is unable to acquire the lock in the first place,
> because the mutex is already "locked". So, the sequence of events is
> process 1, thread 1: acquire lock
> process 1, thread 2: fork(), process 2 is created
> process 1 thread 1: release lock
> 
> Suppose process 1 thread 1 had been executing this code:
> ```
> lock();
> logSomething();  // thread 2 forks when thread 1 is here.
> unlock();
> ```
> 
> Doesn't thread 2 in the child process resume running from the same point?  If 
> so, it seems that both the child and parent would both gracefully unlock the 
> lock.
> 
> I'm sure I'm wrong about this, but hopefully you can clarify what I'm missing.
> 
> As a follow-up question, why can't we use execve instead of fork / exec?
> _______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to