:
http://stackoverflow.com/questions/21743144/using-stdatomic-with-aligned-classes
On Thu, Jun 30, 2016 at 1:19 PM, Philippe Lavoie via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
Hello,
has anyone tried to compile LLDB with Visual Studio 2015 Update 3 ?
It compiles fine with Update
Hello,
has anyone tried to compile LLDB with Visual Studio 2015 Update 3 ?
It compiles fine with Update 2, but with Update 3 we get error messages like:
D:\dev\llvm\tools\lldb\include\lldb/Target/Process.h(3194): error C2719:
'default_stop_addr': formal parameter with requested alignment
belongs to
>// a different compile unit in the same symbol file.
>return m_dwarf2Data->DebugInfo()->GetDIEForDIEOffset(die_offset);
>}
>}
>return DWARFDIE(); // Not found
> }
>
>
> From:
@lists.llvm.org] on behalf of Philippe Lavoie
via lldb-dev [lldb-dev@lists.llvm.org]
Sent: Friday, April 29, 2016 3:27 PM
To: Greg Clayton
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] LTO debug info
> So the main question is why is anything that is indexing the current CU only,
> ac
ks up a DIE in another CU and that CU
> is running 'ExtractDIEsIfNeeded' or 'ClearDIEs', it will access a stale or
> invalid DWARFCompileUnit::m_die_array ...
So the main question is why is anything that is indexing the current CU only,
accessing anything from another C
PM
To: Philippe Lavoie
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] LTO debug info
> On Apr 25, 2016, at 1:37 PM, Philippe Lavoie via lldb-dev
> wrote:
>
> Hello,
>
> We noticed an issue with dwarf parsing when debugging a large application
> compiled with LTO.
>
>
Hello,
We noticed an issue with dwarf parsing when debugging a large application
compiled with LTO.
Since an LTO application's debug info can have inter-compile-unit references,
(for example: a type defined in one compile-unit and used in another) we
noticed that the "m_type_index" vector in S
We have a big-endian target that we debug from LLDB running on Windows through
a custom process plugin and communication protocol.
The target's default byte order is set to eByteOrderBig in 'g_core_definitions'
in ArchSpec.cpp.
Most features work correctly (registers, variables, breakpoints, d
you need to do some cleanup when the plan gets popped.
Was this causing some problem?
Jim
On Sep 25, 2015, at 1:51 PM, Philippe Lavoie via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed to
being popped from the st
I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed to
being popped from the stack), MischiefManaged() is not called and the disabled
breakpoint is not re-enabled.
Is this the intended behavior ?
-Philippe
___
lldb-dev mailing
e0x7fff9968868c; <+20>
>> 0x7fff99688684 <+12>: movq %rax, %rdi
>> 0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
>> 0x7fff9968868c <+20>: retq
>>
>>
>> So we see the public state was set to eState
2c78; cerror
>0x7fff9968868c <+20>: retq
>
>
> So we see the public state was set to eStateAttaching and then it was set to
> eStateStopped. Try this out and let me know what you are seeing.
>
> Greg
>
>
>
e know what you are seeing.
Greg
> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev
> wrote:
>
> It is the AttachToProcessWithID that hangs and never returns, so I cannot use
> my listener yet.
>
> -Philippe
>
> F
opped, and nobody is fetching that.
Jim
> On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev
> wrote:
>
>
> I am trying to attach to a stopped process on our dsp target using the
> SBTarget interface but the call hangs.
> What I understand is that it is waiting for e
nd watch things fail, and attach the log.
Greg Clayton
> On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev
> wrote:
>
>
> I am trying to attach to a stopped process on our dsp target using the
> SBTarget interface but the call hangs.
> What I understand is that it is
I am trying to attach to a stopped process on our dsp target using the SBTarget
interface but the call hangs.
What I understand is that it is waiting for events on the "lldb.process"
broadcaster using the "lldb.Target.Attach.attach.hijack" listener.
Enabling the logs, I see that the process is
16 matches
Mail list logo
