Sounds good. I already have that working in a local patch, but I will wait
for the fix you described earlier to go in first, and handle the merge and
check in the weak_ptr change.
On Mon, Aug 31, 2015 at 2:53 PM Greg Clayton wrote:
>
> > On Aug 31, 2015, at 1:34 PM, Zachary Turner wrote:
> >
>
I think it's mostly a problem of tests. Basically we have tests which are
written in such a way that the inferior and the debugger need to reach a
synchronization point before the test can proceed to test what it wants to
test.
On Mon, Aug 31, 2015 at 4:08 PM Greg Clayton wrote:
> Or is this ju
Or is this just a problem with a bad test? Are we telling LLDB to launch the
test and LLDB is doing the launch + attach in the windows platform and that is
what is hosing up the attach? Or is this a flawed test where the test just
manually launches the process with no hopes of syncing with the p
So a few things:
1 - on MacOSX we can reliably launch a process via posix_spawn() with a flag
set that sets the process to stop at __dyld_start which is the first
instruction in the program. So our launch then attach always works reliably
because when we launch the process set set this posix_sp
> On Aug 31, 2015, at 1:34 PM, Zachary Turner wrote:
>
> Windows plugin holds a strong reference to itself. It calls
> shared_from_this() when the process is launched, and it releases this strong
> reference after a process exits. It does this because the debug loop happens
> in a different
Windows plugin holds a strong reference to itself. It calls
shared_from_this() when the process is launched, and it releases this
strong reference after a process exits. It does this because the debug
loop happens in a different thread, and it wanted to ensure that the
process plugin cannot be ki
A std::weak_ptr is necessary because Target contains a shared pointer to the
process and if you have the process have a shared pointer to the target then
neither will ever destruct.
I have no problem doing this. The main question is who actually has this strong
reference to the process? This s
It is just defined to be where all of the prologue instructions are done
setting up the stack frame for the current function. There is no right answer
in terms of source lines, the compiler can say anything it wants to.
Greg
> On Aug 31, 2015, at 4:22 AM, Aidan Dodds via lldb-dev
> wrote:
>
ARM and AArch64 all green, uploaded.
On 28 August 2015 at 02:46, Hans Wennborg wrote:
> On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote:
>> 3.7.0-rc4 has just been tagged. It is identical to rc3, plus:
>>
>> - r245902: Revert r245355: change of clang-tools-extra symlink in the
>> release sc
Hello all,
It seems that different LLVM backends (ARM, MIPS, X86) can output a
different line number for PROLOGUE_END in the DWARF line table.
Say I have a function as follows:
1. int my_function( int arg1 )
2. {
3.some_code();
4.
At -O0 I am seeing the PROLOGUE_END set on the fu
Le 28/08/2015 03:46, Hans Wennborg a écrit :
> On Wed, Aug 26, 2015 at 4:43 PM, Hans Wennborg wrote:
>> 3.7.0-rc4 has just been tagged. It is identical to rc3, plus:
>>
>> - r245902: Revert r245355: change of clang-tools-extra symlink in the
>> release script
>> - r245947: Merge of r245927: Fix LL
11 matches
Mail list logo
