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 *
Author: jmolenda
Date: Mon Oct 16 20:13:39 2017
New Revision: 315967
URL: http://llvm.org/viewvc/llvm-project?rev=315967&view=rev
Log:
Reverting r315966 - it caused a build failure on an ubuntu x android bot.
Modified:
lldb/trunk/include/lldb/API/SBDebugger.h
lldb/trunk/include/lldb/Core
Author: jmolenda
Date: Mon Oct 16 20:03:44 2017
New Revision: 315966
URL: http://llvm.org/viewvc/llvm-project?rev=315966&view=rev
Log:
Committing this for Larry D'Anna:
This patch adds support for passing an arbitrary python stream
(anything inheriting from IOBase) to SetOutputFileHandle or
SetEr
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 Tu
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
get
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 to run additional cod
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 w
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
ar
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 unable to acquire the lock in the first pla
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
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
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
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:
> `re
13 matches
Mail list logo
