Re: [Lldb-commits] [lldb] r315967 - Reverting r315966 - it caused a build failure on an ubuntu x android bot.

Can anyone more familiar with the android SDK help out? Larry's patch in https://reviews.llvm.org/D38829 aadds this code to File.cpp: +File::File(void *cookie, + int (*readfn)(void *, char *, int), + int (*writefn)(void *, const char *, int), + int (*closefn)(void

Re: [Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

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

Re: [Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

This thread behavior over fork is the same on Mach, BTW. Apple extended posix_spawnp to take a “Stop at first instruction” attribute, basically just running PT_TRACEME for us. That has ended up being very handy because we get all the nice cleanup behavior that pthread_spawn does, but still

Re: [Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

Ahh wait, sorry. I meant posix_spawn, not execve On Mon, Oct 16, 2017 at 2:16 PM Zachary Turner 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

Re: [Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

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

Re: [Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

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

Re: [Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath wrote: > On 15 October 2017 at 23:04, Zachary Turner 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

[Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

eugene added a comment. DisableUnlocked methods makes me uneasy. Maybe we can take a log lock before forking and then properly release it in both parent and child processes? https://reviews.llvm.org/D38938 ___ lldb-commits mailing list

[Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

clayborg added a comment. Never mind, re-reading your original comment made it clear. https://reviews.llvm.org/D38938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

clayborg added a comment. Who is holding the lock and then fork'ing? Seems like we should fix that? I thought all log calls should be "lock, log, unlock". Why is this causing problems? https://reviews.llvm.org/D38938 ___ lldb-commits mailing list

[Lldb-commits] [PATCH] D38897: Add specific ppc64le hardware watchpoint handler

anajuliapc added inline comments. Comment at: source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp:374 + uint32_t tempControl = m_hwp_regs[wp_index].control; + long * tempSlot = reinterpret_cast(m_hwp_regs[wp_index].slot); + zturner wrote: >