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
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
> 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
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
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
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
