Another alternative would be to make the LineEntry hold both the remapped &
original file spec, and add an API to get the "original FileSpec". Then
anybody who is holding onto a line entry or file spec derived therefrom will
know to compare the original file spec, since the remapped one is unre
Why are we remapping the FileSpecs in SymbolContext's we are handing out? That
seems to me a bad idea. It means that every time I want to do a FileSpec
compare between the LineEntry FileSpec's that I get at from stack frames at two
different times, I have to remember to re-apply the SourceMap
Symbols are being remapped. StackFrame::GetSymbolContext does this:
m_sc.line_entry = sc.line_entry;
if (m_sc.target_sp)
{
// Be sure to apply and file remappings to our file and
line
// en
> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
> wrote:
>
> I’m stepping over the first line of a libcxx test (source
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
> ). The first line has an inlined function
I'm stepping over the first line of a libcxx test (source
https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit
ion/thread.condition.condvar/wait.pass.cpp ). The first line has an inlined
function call. I expect lldb to step over the breakpoint, run to the end of
the range th
Adding lldb-dev to the loop. I don't think there should be major
issues there as lldb supports a strict subset targets, just making
sure everyone is aware of the plans.
Our team manages a couple of lldb buildbots still using cmake 2.8.
We'll get started on upgrading them though.
pl
On 5 May 2016
