On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev
wrote:
>
> Yes that’s what I’ve been thinking about as well.
>
> One thing I’ve been giving a lot of thought to is whether to serialize the
> handling of trace events. I want to balance the “this is a library and you
> should be able to
Hi,
It’s currently not possible to set the correct repository for lldb code
reviews. Could someone with the right privileges add LLDB to the list of active
repositories? (https://reviews.llvm.org/diffusion/)
Thanks,
Jonas
___
lldb-dev mailing list
lld
https://bugs.llvm.org/show_bug.cgi?id=37950
Bug ID: 37950
Summary: ExecutionContext::GetByteOrder() always returns
endian::InlHostByteOrder()
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Hello!
We want to add to LLDB a support of a lookup of variables values with PDB.
Now SymbolFilePDB::ParseVariableForPDBData function uses an empty location
for variables, so e.g. `fr v` prints values as ''. Symbol
location information is available in a PDB (through
PDBSymbolData::getLocationTyp
suppose process A (single threaded) is tracing process B (2 threads). If
trace events happen on both threads of B, then the second thread can’t
continue until both threads’ trace events have been fully handled,
synchronously. If process A has a second thread though, the tracer thread
can enqueue wo
On Wed, 27 Jun 2018 at 14:11, Zachary Turner wrote:
>
> suppose process A (single threaded) is tracing process B (2 threads). If
> trace events happen on both threads of B, then the second thread can’t
> continue until both threads’ trace events have been fully handled,
> synchronously. If proc
> On Jun 27, 2018, at 5:25 AM, Aleksandr Urakov via lldb-dev
> wrote:
>
> Hello!
>
> We want to add to LLDB a support of a lookup of variables values with PDB.
>
> Now SymbolFilePDB::ParseVariableForPDBData function uses an empty location
> for variables, so e.g. `fr v` prints values as ''.
> On Jun 26, 2018, at 5:14 PM, Zachary Turner wrote:
>
> Yes that’s what I’ve been thinking about as well.
>
> One thing I’ve been giving a lot of thought to is whether to serialize the
> handling of trace events. I want to balance the “this is a library and you
> should be able to get it to
The major difference between the way lldb works now and what a simple tracer
library is going to want w.r.t. reporting events is that lldb currently assumes
either
(a)control gets returned to the user with the process stopped and they will
examine it at their leisure
(b) that the user restart
Hi Everyone,
I'm writing a gdb-server for a new architecture and need to be able to debug
lldb to track down issues. Unfortunately disk space is tight here and the llvm
debug build consumes north of 40Gb with debug symbols. Is there any way to
build *only* lldb with debug symbols (and no optimi
10 matches
Mail list logo
