Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)
Hi Stefan, what you are describing should work out of the box, so the fact that you are having to add the symbols manually is a bug. I haven't tried it with the apache binary specifically, but lldb can certainly find external debug symbols for libc (definitely on ubuntu 14.04, as that's what I use). We need to figure out what is different in your case. The most important function here is SymbolVendorELF::CreateInstance. Could you step through that function, and see why it fails to find the file? On 7 May 2016 at 19:45, Stefan Kratochwil via lldb-dev wrote: > Hi, > > I need to gather information about variables on the stack frames of a given > program, lets say apache2 (httpd), using the C++ flavour of the lldb > scripting bridge. > > Now, if I attach to the corresponding process id, lldb does not find any > debug symbols, although I have installed the debug symbols package for > apache2 (apache2-dbg). > > If I use the lldb cli, I have to use > 'target symbols load /usr/lib/debug/usr/sbin/apache2' > (or any other path under /usr/lib/debug, depending on the stack frame / > module I am currently looking at) to load the corresponding debug symbols. > > However, if I try the same with gdb, then it automagically uses the binaries > under /usr/lib/debug (the non-stripped binaries from any *-dbg package are > located here) for symbolification. > > > Now, there are two questions for me: > > 1.: Is there a way to let lldb automagically load debug symbols from > /usr/lib/debug, if there are any? > > 2.: If not, how can I do this manually using the C++ API? > The SBTarget class does not have suitable methods for this - the closest > thing is SBTarget#AddModule(), but this gives me a _new_ module, instead of > associating a symbolfile with an existing one. The code path of > CommandObjectTarget.cpp#AddModuleSymbols() seems not to be reflected in the > scripting bridge, or at least I haven't found it yet. You can use SBDebugger::HandleCommand to execute any command which does have an API equivalent. It's not ideal, but it works. :) cheers, pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)
Hi Pavel,
thanks for your quick reply. I am currently using a release build, so it
may take a moment until I can step through there. I'll report back as
soon as possible (my masters thesis somehow depends on that ;) ).
I was just about to implement an addon for the API tonight, when I found
SBDebugger::HandleCommand("target symbols add ..."). Yeah, it's a little
weird way of using an API, and it's a one way command with stdout as
reply channel, but it works ^^
Cheers,
Stefan
On 05/09/2016 10:22 AM, Pavel Labath wrote:
Hi Stefan,
what you are describing should work out of the box, so the fact that
you are having to add the symbols manually is a bug. I haven't tried
it with the apache binary specifically, but lldb can certainly find
external debug symbols for libc (definitely on ubuntu 14.04, as that's
what I use). We need to figure out what is different in your case. The
most important function here is SymbolVendorELF::CreateInstance. Could
you step through that function, and see why it fails to find the file?
On 7 May 2016 at 19:45, Stefan Kratochwil via lldb-dev
wrote:
Hi,
I need to gather information about variables on the stack frames of a given
program, lets say apache2 (httpd), using the C++ flavour of the lldb
scripting bridge.
Now, if I attach to the corresponding process id, lldb does not find any
debug symbols, although I have installed the debug symbols package for
apache2 (apache2-dbg).
If I use the lldb cli, I have to use
'target symbols load /usr/lib/debug/usr/sbin/apache2'
(or any other path under /usr/lib/debug, depending on the stack frame /
module I am currently looking at) to load the corresponding debug symbols.
However, if I try the same with gdb, then it automagically uses the binaries
under /usr/lib/debug (the non-stripped binaries from any *-dbg package are
located here) for symbolification.
Now, there are two questions for me:
1.: Is there a way to let lldb automagically load debug symbols from
/usr/lib/debug, if there are any?
2.: If not, how can I do this manually using the C++ API?
The SBTarget class does not have suitable methods for this - the closest
thing is SBTarget#AddModule(), but this gives me a _new_ module, instead of
associating a symbolfile with an existing one. The code path of
CommandObjectTarget.cpp#AddModuleSymbols() seems not to be reflected in the
scripting bridge, or at least I haven't found it yet.
You can use SBDebugger::HandleCommand to execute any command which
does have an API equivalent. It's not ideal, but it works. :)
cheers,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)
You can also use SBCommandInterpreter::HandleCommand, which gives you
a bit more control over what happens.
good luck with your thesis.
pl
On 9 May 2016 at 10:00, Stefan Kratochwil wrote:
> Hi Pavel,
>
> thanks for your quick reply. I am currently using a release build, so it may
> take a moment until I can step through there. I'll report back as soon as
> possible (my masters thesis somehow depends on that ;) ).
>
> I was just about to implement an addon for the API tonight, when I found
> SBDebugger::HandleCommand("target symbols add ..."). Yeah, it's a little
> weird way of using an API, and it's a one way command with stdout as reply
> channel, but it works ^^
>
> Cheers,
> Stefan
>
>
>
> On 05/09/2016 10:22 AM, Pavel Labath wrote:
>>
>> Hi Stefan,
>>
>> what you are describing should work out of the box, so the fact that
>> you are having to add the symbols manually is a bug. I haven't tried
>> it with the apache binary specifically, but lldb can certainly find
>> external debug symbols for libc (definitely on ubuntu 14.04, as that's
>> what I use). We need to figure out what is different in your case. The
>> most important function here is SymbolVendorELF::CreateInstance. Could
>> you step through that function, and see why it fails to find the file?
>>
>> On 7 May 2016 at 19:45, Stefan Kratochwil via lldb-dev
>> wrote:
>>>
>>> Hi,
>>>
>>> I need to gather information about variables on the stack frames of a
>>> given
>>> program, lets say apache2 (httpd), using the C++ flavour of the lldb
>>> scripting bridge.
>>>
>>> Now, if I attach to the corresponding process id, lldb does not find any
>>> debug symbols, although I have installed the debug symbols package for
>>> apache2 (apache2-dbg).
>>>
>>> If I use the lldb cli, I have to use
>>> 'target symbols load /usr/lib/debug/usr/sbin/apache2'
>>> (or any other path under /usr/lib/debug, depending on the stack frame /
>>> module I am currently looking at) to load the corresponding debug
>>> symbols.
>>>
>>> However, if I try the same with gdb, then it automagically uses the
>>> binaries
>>> under /usr/lib/debug (the non-stripped binaries from any *-dbg package
>>> are
>>> located here) for symbolification.
>>>
>>>
>>> Now, there are two questions for me:
>>>
>>> 1.: Is there a way to let lldb automagically load debug symbols from
>>> /usr/lib/debug, if there are any?
>>>
>>> 2.: If not, how can I do this manually using the C++ API?
>>> The SBTarget class does not have suitable methods for this - the closest
>>> thing is SBTarget#AddModule(), but this gives me a _new_ module, instead
>>> of
>>> associating a symbolfile with an existing one. The code path of
>>> CommandObjectTarget.cpp#AddModuleSymbols() seems not to be reflected in
>>> the
>>> scripting bridge, or at least I haven't found it yet.
>>
>>
>> You can use SBDebugger::HandleCommand to execute any command which
>> does have an API equivalent. It's not ideal, but it works. :)
>>
>> cheers,
>> pl
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)
Hi Pavel,
I stepped through SymbolVendorELF::CreateInstance(), and it seems that
the problem lies within Symbols::LocateExecutableSymbolFile
(Host/common/Symbols.cpp). This method looks at the correct locations:
(gdb) print debug_file_search_paths
$35 = {m_files = std::vector of length 3, capacity 4 = {
{m_directory = {m_string = 0x7994f8 "/usr/lib"},
m_filename = {m_string = 0x7fffe400ba88 "x86_64-linux-gnu"},
m_is_resolved = true,
m_syntax = lldb_private::FileSpec::ePathSyntaxPosix},
{m_directory = {m_string = 0x7fffe400bae0
"/home/stefan/git/dsu-ld/libdsu-project"},
m_filename = {m_string = 0x7fffe400bac8 "."},
m_is_resolved = true,
m_syntax = lldb_private::FileSpec::ePathSyntaxPosix},
{m_directory = {m_string = 0x7994f8 "/usr/lib"},
m_filename = {m_string = 0x7fffe400bb18 "debug"},
m_is_resolved = true,
m_syntax = lldb_private::FileSpec::ePathSyntaxPosix}}}
But it looks for the wrong file names. Under Ubuntu, the contents of a
*-dbg packge are stored under /usr/lib/debug, using the exact same file
names as their regular executable counterparts. In the case of
apache2-dbg, the files under /usr/lib/debug are (for example):
/usr/lib/debug/usr/bin/rotatelogs
/usr/lib/debug/usr/sbin/apache2
/usr/lib/debug/usr/lib/apache2/modules/mod_ssl.so
and so on.
If i now look at the file names lldb looks for, I find for
/usr/lib/x86_64-linux-gnu:
(gdb) print files
$36 = std::vector of length 4, capacity 4 = {
"/usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
"/usr/lib/x86_64-linux-gnu/.debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
"/usr/lib/x86_64-linux-gnu/.build-id/B5/9D72EE0B01E9B2947C7F95E7B4EBBBF05A8AA5.debug",
"/usr/lib/x86_64-linux-gnu/usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug"}
For my /home/stefan/git/dsu-ld/libdsu-project/:
(gdb) print files
$38 = std::vector of length 4, capacity 4 = {
"/home/stefan/git/dsu-ld/libdsu-project/./9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
"/home/stefan/git/dsu-ld/libdsu-project/./.debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
"/home/stefan/git/dsu-ld/libdsu-project/./.build-id/B5/9D72EE0B01E9B2947C7F95E7B4EBBBF05A8AA5.debug",
"/home/stefan/git/dsu-ld/libdsu-project/./usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug"}
And finally for the /usr/lib/debug directory:
(gdb) print files
$39 = std::vector of length 4, capacity 4 = {
"/usr/lib/debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
"/usr/lib/debug/.debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
"/usr/lib/debug/.build-id/B5/9D72EE0B01E9B2947C7F95E7B4EBBBF05A8AA5.debug",
"/usr/lib/debug/usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug"}
So, lldb expects that the uuid/build of the Module it is about to load
is also contained in the symbol file name.
Imho, we also have to take the FileSpec contents of the ModuleSpec we
are currently looking at, and add its path to the files vector. But I am
not that familiar with the whole lldb backend to tell for sure what
would happen then.
I also checked the current HEAD of the lldb source tree to see if there
are any changes, compared with my older revision. There is only a slight
difference in how Symbols::LoadExecutableSymbolFile uses the
/usr/lib/debug directory:
// Some debug files may stored in the module directory like this:
// /usr/lib/debug/usr/lib/library.so.debug
if (!file_dir.IsEmpty())
files.push_back (dirname + file_dir.AsCString() + "/" ++
symbol_filename);
This would be in fact the solution to my problem, if it wouldn't use the
symbol_filename (which contains a uuid, something the *-dbg packages
don't have).
Well, what do you think?
Cheers,
Stefan
On 05/09/2016 11:23 AM, Pavel Labath wrote:
You can also use SBCommandInterpreter::HandleCommand, which gives you
a bit more control over what happens.
good luck with your thesis.
pl
On 9 May 2016 at 10:00, Stefan Kratochwil wrote:
Hi Pavel,
thanks for your quick reply. I am currently using a release build, so it may
take a moment until I can step through there. I'll report back as soon as
possible (my masters thesis somehow depends on that ;) ).
I was just about to implement an addon for the API tonight, when I found
SBDebugger::HandleCommand("target symbols add ..."). Yeah, it's a little
weird way of using an API, and it's a one way command with stdout as reply
channel, but it works ^^
Cheers,
Stefan
On 05/09/2016 10:22 AM, Pavel Labath wrote:
Hi Stefan,
what you are describing should work out of the box, so the fact that
you are having to add the symbols manually is a bug. I haven't tried
it with the apache binary specifically, but lldb can certainly find
external debug symbols for libc (definitely on ubuntu 14.04, as that's
what I use). We need to figure out what is different in your case. The
most important function here is SymbolVendorELF::CreateInstance. Could
you step through tha
[lldb-dev] [Bug 27687] New: We cannot backtrace out of fflush() on Linux x86_64
https://llvm.org/bugs/show_bug.cgi?id=27687 Bug ID: 27687 Summary: We cannot backtrace out of fflush() on Linux x86_64 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified This is happening in TestPrintStackTraces, where we can end up here: ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2: 0x77df04e0 <+0>: 48 83 ec 38 subq $0x38, %rsp 0x77df04e4 <+4>: 48 89 04 24 movq %rax, (%rsp) 0x77df04e8 <+8>: 48 89 4c 24 08movq %rcx, 0x8(%rsp) 0x77df04ed <+13>: 48 89 54 24 10movq %rdx, 0x10(%rsp) 0x77df04f2 <+18>: 48 89 74 24 18movq %rsi, 0x18(%rsp) 0x77df04f7 <+23>: 48 89 7c 24 20movq %rdi, 0x20(%rsp) 0x77df04fc <+28>: 4c 89 44 24 28movq %r8, 0x28(%rsp) 0x77df0501 <+33>: 4c 89 4c 24 30movq %r9, 0x30(%rsp) 0x77df0506 <+38>: 48 8b 74 24 40movq 0x40(%rsp), %rsi 0x77df050b <+43>: 48 8b 7c 24 38movq 0x38(%rsp), %rdi 0x77df0510 <+48>: e8 4b 8f ff ffcallq 0x77de9460; ___lldb_unnamed_symbol54$$ld-linux-x86-64.so.2 0x77df0515 <+53>: 49 89 c3 movq %rax, %r11 0x77df0518 <+56>: 4c 8b 4c 24 30movq 0x30(%rsp), %r9 0x77df051d <+61>: 4c 8b 44 24 28movq 0x28(%rsp), %r8 0x77df0522 <+66>: 48 8b 7c 24 20movq 0x20(%rsp), %rdi 0x77df0527 <+71>: 48 8b 74 24 18movq 0x18(%rsp), %rsi 0x77df052c <+76>: 48 8b 54 24 10movq 0x10(%rsp), %rdx 0x77df0531 <+81>: 48 8b 4c 24 08movq 0x8(%rsp), %rcx -> 0x77df0536 <+86>: 48 8b 04 24 movq (%rsp), %rax 0x77df053a <+90>: 48 83 c4 48 addq $0x48, %rsp 0x77df053e <+94>: 41 ff e3 jmpq *%r11 0x77df0541 <+97>: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:(%rax,%rax) image show-unwind --address 0x77df0536 UNWIND PLANS for ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2 (start addr 0x77df04e0) Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn profiling' Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI' Assembly language inspection UnwindPlan: This UnwindPlan originally sourced from assembly insn profiling This UnwindPlan is sourced from the compiler: no. This UnwindPlan is valid at all instruction locations: yes. Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 88576-0x00015a70) row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8] row[2]: 94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8] eh_frame UnwindPlan: This UnwindPlan originally sourced from eh_frame CFI This UnwindPlan is sourced from the compiler: yes. This UnwindPlan is valid at all instruction locations: no. Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 88576-0x00015a61) row[0]:0: CFA=rsp+24 => rip=[CFA-8] row[1]:4: CFA=rsp+80 => rip=[CFA-8] row[2]: 94: CFA=rsp +8 => rip=[CFA-8] So the, eh_frame unwind plan is actually correct, but we are using the assembly emulation unwind plan, which ends up being hopelessly incorrect, as the function we are in does not have a normal stack frame (it exits via a tail call, and I think it is entered by one as well). The unwind machinery eventually picks itself up, but not before skipping a couple of frames on the stack. We should find a way to get lldb to use eh_frame plan (or eh_frame+augmentation) here. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
I'll defer to Greg on remapping FileSpecs in SymbolContexts - he's the one who
added it, in r168845:
commit 214d2a327feb2e5987d093c2b63c457ffbd1d677
Author: Greg Clayton
Date: Thu Nov 29 00:53:06 2012 +
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: jing...@apple.com [mailto:jing...@apple.com]
Sent: Friday, May 06, 2016 6:01 PM
To: Ted Woodward
Cc: LLDB
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
> 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 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: jing...@apple.com [mailto:jing...@apple.com]
>> Sent: Friday, May 06, 2016 2:41 PM
>> To: Ted Woodward
>> Cc: LLDB
>> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol
>> context and target.source-map s
Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)
> I also checked the current HEAD of the lldb source tree to see if there are > any changes, compared with my older revision. There is only a slight > difference in how Symbols::LoadExecutableSymbolFile uses the /usr/lib/debug > directory: > > // Some debug files may stored in the module directory like this: > // /usr/lib/debug/usr/lib/library.so.debug > if (!file_dir.IsEmpty()) >files.push_back (dirname + file_dir.AsCString() + "/" ++ symbol_filename); > > > > This would be in fact the solution to my problem, if it wouldn't use the > symbol_filename (which contains a uuid, something the *-dbg packages don't > have). > > > Well, what do you think? > That sounds like a valid plan. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
I talked with Greg about this before I posted the suggestion below, and having
the LineEntry contain both mapped and unmapped FileSpec's was his suggestion...
But who knows what changes of heart a weekend might bring.
Jim
> On May 9, 2016, at 9:43 AM, Ted Woodward wrote:
>
> I'll defer to Greg on remapping FileSpecs in SymbolContexts - he's the one
> who added it, in r168845:
>
> commit 214d2a327feb2e5987d093c2b63c457ffbd1d677
> Author: Greg Clayton
> Date: Thu Nov 29 00:53:06 2012 +
>
>
>
>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: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Friday, May 06, 2016 6:01 PM
> To: Ted Woodward
> Cc: LLDB
> 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
>> 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
>>> 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.
>>>
>>> --
>>> Qualc
