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
// entries when handing out a line entry
FileSpec new_file_spec;
if (m_sc.target_sp->GetSourcePathMap().FindFile
(m_sc.line_entry.file, new_file_spec))
m_sc.line_entry.file = new_file_spec;
}
This code gets called if the StackFrame ctor is called with the SymbolContext =
nullptr, but this is skipped if the SymbolContext is valid. All new StackFrames
in StackFrameList are done with a null SC, except for an inlined frame. In that
case, StackFrameList::GetFramesUpTo calls
SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo
does not remap it like StackFrame::GetSymbolContext does. Then it creates a new
StackFrame with the SC.
Adding this before the new StackFrame fixes the issue:
if (target_sp)
{
// Be sure to apply and file remappings to our file and
line
// entries when handing out a line entry
FileSpec new_file_spec;
if
(target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file,
new_file_spec))
next_frame_sc.line_entry.file = new_file_spec;
}
I've put up a patch on Phabricator with Jim as reviewer.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, May 06, 2016 2:41 PM
To: Ted Woodward <[email protected]>
Cc: LLDB <[email protected]>
Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context
and target.source-map setting
> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
> <[email protected]> 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 call. I expect lldb to step over
> the breakpoint, run to the end of the range that sets up the inlined function
> call, run through the inlined function call, then run to the end of the line.
> Instead, it runs to the inlined call, then stops.
>
> I’m running lldb on Windows, debugging a Hexagon application that was built
> on Linux. I’m using the target.source-map setting to let me see source.
>
> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re
> still on the same line by comparing the filename in the Stepping Plan’s line
> entry to the filename in the current frame’s line entry.
> m_addr_context.line_entry.file has been normalized by the value in
> target.source-map, but new_context.line_entry.file hasn’t, so they’re not the
> same, even though they should be.
>
> SymbolContext
> new_context(frame->GetSymbolContext(eSymbolContextEverything));
> if (m_addr_context.line_entry.IsValid() &&
> new_context.line_entry.IsValid())
> {
> if (m_addr_context.line_entry.file == new_context.line_entry.file)
> {
>
>
> Either both should use target.source-map, or neither should. How do I run
> new_context.line_entry.file through the target.source-map normalization?
It doesn't seem right to me that when symbols are handed out they have the
source map applied to their file spec's. After all, then you could get into
problems like: somebody started a step so we recorded m_addr_context. Then
their step was interrupted (say by hitting a breakpoint) and the user added a
source mapping. Then we stop in a frame from the same module, and now the
SymbolContext that the step plan stored (m_addr_context) has a different path
than the one in the frame when we get to it. Checking every time you compared
file specs seems very error prone, we shouldn't do it that way. I guess if the
FileSpec == handled this it would be odd but not too bad. But that seems like
it would result in a lot of unnecessary work. I think it would be better to
only do source map path conversion when sources are looked up, and maybe when
paths are printed. For symbols we should stick to what the debug info says.
Jim
>
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
