[lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

Ted Woodward via lldb-dev lldb-dev at lists.llvm.org
Mon May 9 09:43:10 PDT 2016


I'll defer to Greg on remapping FileSpecs in SymbolContexts - he's the one who added it, in r168845:

commit 214d2a327feb2e5987d093c2b63c457ffbd1d677
Author: Greg Clayton <gclayton at apple.com>
Date:   Thu Nov 29 00:53:06 2012 +0000

    <rdar://problem/12445557>
    
    Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function.


http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StackFrame.cpp?r1=168845&r2=168844&pathrev=168845

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


-----Original Message-----
From: jingham at apple.com [mailto:jingham at apple.com] 
Sent: Friday, May 06, 2016 6:01 PM
To: Ted Woodward <ted.woodward at codeaurora.org>
Cc: LLDB <lldb-dev at lists.llvm.org>
Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

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 unreliable.  Probably should move the remapping to the LineEntry (LineEntry::ApplyFileMappings(Target &target) so it is clear who is in charge of this.  

Note, you absolutely should never use SourceMaps to remap FileSpecs that are in the module's debug information, since these modules are shared among all the Debugger's, and the Debuggers could have different SourceMaps.  So by putting this explicitly in the LineEntry - which is not something we use to store line information, it's just something we cons up to hand out when requested - it might make that requirement clearer.

Jim


> On May 6, 2016, at 3:49 PM, Jim Ingham via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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 to the file spec I've stored away before doing the compare.  After all, the user might have changed the source map and thus the file spec we are handing out.  That seems very error prone.  And we can't handle that in the FileSpec "==" operator because FileSpec's don't have Targets, so they have no way of getting to the map.  
> 
> Wouldn't it be better to use the source maps when we print filenames and look for actual source files, and leave the symbol context FileSpec's in some canonical form we know won't change over time?
> 
> Jim
> 
> 
>> On May 6, 2016, at 3:05 PM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
>> 
>> 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: jingham at apple.com [mailto:jingham at apple.com] 
>> Sent: Friday, May 06, 2016 2:41 PM
>> To: Ted Woodward <ted.woodward at codeaurora.org>
>> Cc: LLDB <lldb-dev at lists.llvm.org>
>> 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 <lldb-dev at lists.llvm.org> 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
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev




More information about the lldb-dev mailing list