<div dir="ltr">Ooops, I accidentally dropped lldb mail list.<div>I have chatted this long relative path issue with our buck build team, they seem to do some kind of post-processing for the symbol files but failed to run another scripts to resolve the processed paths back into absolute path. And they are unable to fix this in short time. :-(</div><div><br></div><div>I am building a workaround for this issue:</div><div>I am building a middle indirection map between debugger UI and lldb. Whenever I enumerate a SBFileSpec a source line, I get the source file long relative path from it and add basepath of the build project then normalize into an absolute path, then store absolute_path->SBFileSpec mapping into the map, then send the absolute path to debugger UI. When the debugger UI is trying to set source line breakpoint, I got the absolute path back from debugger UI and use the middle indirection map to find corresponding SBFileSpec for that source file. Finally, I used the SBFileSpec to set source line breakpoint. </div><div>The assumption is that as long as I used the same SBFileSpec from lldb, I should use it to set source line breakpoint successfully.</div><div>However, it turns out this still does not work. The breakpoints are listed as pending:</div><div><br></div><div><div>break list</div><div>Current breakpoints:</div><div>1: file = './/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/App/main.m', line = 9, locations = 0 (pending)</div><div>2: file = './/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m', line = 20, locations = 0 (pending)<br></div></div><div><br></div><div>Questions:</div><div>Isn't lldb treating this long relative path as *absolute path* so as long as this long path is used to set breakpoint it should work? Any idea why this workaround approach does not work?</div><div><br></div><div>Jeffrey</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 6, 2016 at 8:47 AM, Jeffrey Tan <span dir="ltr"><<a href="mailto:jeffrey.fudan@gmail.com" target="_blank">jeffrey.fudan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nevermind, I do not know why "<span style="font-size:12.8px;color:rgb(80,0,80)">GetSelectedTarget().</span><span style="font-size:12.8px;color:rgb(80,0,80)">BreakpointCreateByLocation("</span><span style="font-size:12.8px;color:rgb(80,0,80)">EATAnimatedView.m", line)</span>" does not work for me last October. I tried it again, it works now. <div>I will see if I can figure out the weird relative <span style="font-size:12.8px">location path in symbol file issue.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks!</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 3:38 PM, Jeffrey Tan <span dir="ltr"><<a href="mailto:jeffrey.fudan@gmail.com" target="_blank">jeffrey.fudan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry for the late response. I finally had time to come back to this issue. <div><br><div>Can anyone help me with the "<span style="font-size:12.8px;color:rgb(80,0,80)">self.debugger.</span><span style="font-size:12.8px;color:rgb(80,0,80)">GetSelectedTarget().</span><span style="font-size:12.8px;color:rgb(80,0,80)">BreakpointCreateByLocation("</span><span style="font-size:12.8px;color:rgb(80,0,80)">EATAnimatedView.m", line)</span>" not working issue? Does it suppose to work? I can reproduce it pretty easily in a small python script. </div><div><br></div><div>I found the following lldb test that uses this API:</div><div><a href="http://www.opensource.apple.com/source/lldb/lldb-69/test/lang/objc/objc-stepping/TestObjCStepping.py" target="_blank">http://www.opensource.apple.com/source/lldb/lldb-69/test/lang/objc/objc-stepping/TestObjCStepping.py</a></div><div><br></div><div>So it seems that this should work. Am I doing something wrong? I am importing the Xcode's lldb by following:</div><div><div>developer_dir = subprocess.check_output(['xcode-select', '--print-path'])</div><div>    lldb_pythonpath = os.path.join(</div><div>        developer_dir.strip(), '../SharedFrameworks/LLDB.framework/Resources/Python')</div><div>    sys.path.append(lldb_pythonpath)</div></div><div><br></div></div><div>For the weird long path issue, I will follow-up with our build team, but definitely needs to resolve the <span style="color:rgb(80,0,80);font-size:12.8px">BreakpointCreateByLocatio</span><span style="color:rgb(80,0,80);font-size:12.8px">n() can't be called issue first. </span></div><div><br></div><div>Thanks for any help!</div><span><font color="#888888"><div>Jeffrey</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 8, 2015 at 10:46 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Oct 8, 2015, at 10:25 AM, Jeffrey Tan <<a href="mailto:jeffrey.fudan@gmail.com" target="_blank">jeffrey.fudan@gmail.com</a>> wrote:<br>
><br>
> Thanks Greg. Here is the info:<br>
> (lldb) br list --verbose<br>
> Current breakpoints:<br>
> 1: file = 'EATAnimatedView.m', line = 21<br>
>     1.1:<br>
>       module = /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/12E85C41-A74F-45E1-8440-E7D08D8EB1FA/data/Containers/Bundle/Application/3BA10AF8-9B18-4FD8-8C76-EA25DE2F37E6/MPKEats.app/MPKEats<br>
>       compile unit = EATAnimatedView.m<br>
>       function = -[EATAnimatedView initWithFrame:imageNames:animationDuration:repeatCount:touchEnabled:]<br>
>       location = ./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21<br>
>       address = 0x0000000103deae42<br>
>       resolved = true<br>
>       hit count = 0<br>
><br>
<br>
</span>Wow that is a lot of redundant ////'s. You should fix your build system to not do this for one, but I agree we need to deal with this.<br>
<br>
You can modify the following function:<br>
<br>
void<br>
FileSpec::RemoveBackupDots (const ConstString &input_const_str, ConstString &result_const_str);<br>
<br>
To remove the redundant slashes and it might make things work. The thing that really worries me is that you still have a relative location in your sources:<br>
<br>
"./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"<br>
<br>
<br>
This should have been resolved from the DWARF using DW_AT_comp_dir. What should happen is your DWARF should have a compile unit like:<br>
<br>
<br>
0x0000000b: DW_TAG_compile_unit [1] *<br>
            DW_AT_producer( "Apple LLVM version 7.x.x" )<br>
            DW_AT_language( DW_LANG_ObjC )<br>
            DW_AT_name( "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m" )<br>
            DW_AT_stmt_list( 0x00000000 )<br>
            DW_AT_comp_dir( "/tmp/build/foo/bar" )<br>
            DW_AT_low_pc( 0x0000000100000b50 )<br>
            DW_AT_high_pc( 0x0000000100000e62 )<br>
<br>
<br>
So if the DW_AT_name of your compile unit is relative, we should have a DW_AT_comp_dir that is absolute. Put the two together and we should have a complete path that works.<br>
<br>
Can you send me your ELF file that contains the DWARF so I can look at it?<br>
<span><br>
> I think we should fix this full path matching issue. It is totally reasonable for debugger user to move source file from build location to another place. Also, this needs to be supported for source server scenario. As long as the source file's checksum matches what recorded in symbol file we should match it.<br>
><br>
> I still need to figure out why "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m", line)" not working issue. The callstack seems to indicate I passed wrong number of arguments into it.<br>
<br>
</span>This might be a swig type map issue where "line" in the python is a long and we don't know how to convert it to be passed to a uint32_t. We have seen such issues if the past where if you variable is a long, integer or other, it might not convert to uint32_t correctly...<br>
<div><div><br>
<br>
><br>
> Jeffrey<br>
><br>
> On Thu, Oct 8, 2015 at 9:46 AM, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
> > On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > I am writing a python script to set source line breakpoint in ObjC on Mac OSX. But self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m", line) always fail. Any ideas?<br>
><br>
> As long as you have a selected target, this should work as long as you have debug info that matches.<br>
> ><br>
> > Also, can I use full path instead of file basename?<br>
><br>
> Yes you can, but it must match exactly if you use the full path.<br>
><br>
> > In lldb, I found "b /Users/jeffreytan/fbsource/fbobjc/Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21" will fail to bind but "b EATAnimatedView.m:21" will succeed.<br>
><br>
> This is usually because you have a makefile build system that is creating debug info that doesn't contain a path that matches. When you launch a compiler, it can often end up with different paths than what you think you have. So set the breakpoint by basename first, then do:<br>
><br>
> (lldb) b main.c:12<br>
> Breakpoint 1: where = a.out`main + 70 at main.c:12, address = 0x0000000100000b96<br>
> (lldb) breakpoint list --verbose<br>
> Current breakpoints:<br>
> 1: file = 'main.c', line = 12<br>
>     1.1:<br>
>       module = /Volumes/work/gclayton/Documents/src/args/a.out<br>
>       compile unit = main.c<br>
>       function = main<br>
>       location = /Volumes/work/gclayton/Documents/src/args/main.c:12<br>
>       address = a.out[0x0000000100000b96]<br>
>       resolved = false<br>
>       hit count = 0<br>
><br>
><br>
> You will see the full path to your source file in the "location" value. You will probably notice that the path is different. We try to take care of removing and extra "../useless_dir" things from the paths and still make things match, but you might have a case that we aren't handling. Let me know what you see when you set the breakpoint by basename.<br>
><br>
><br>
> > Traceback (most recent call last):<br>
> >   File "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/chromedebugger.py", line 69, in _generate_response<br>
> >     params=message.get('params', {}),<br>
> >   File "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py", line 42, in handle<br>
> >     return self._domains[domain_name].handle(method_name, params)<br>
> >   File "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py", line 106, in handle<br>
> >     return self._handlers[method](params)<br>
> >   File "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py", line 56, in _handler_wrapper<br>
> >     ret = func(self, params)<br>
> >   File "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py", line 248, in setBreakpointByUrl<br>
> >     int(params['lineNumber']) + 1)<br>
> >   File "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py", line 283, in _set_breakpoint_by_filespec<br>
> >     breakpoint = self.debugger.GetSelectedTarget().BreakpointCreateByLocation(filespec, line)<br>
> >   File "/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py", line 8650, in BreakpointCreateByLocation<br>
> >     return _lldb.SBTarget_BreakpointCreateByLocation(self, *args)<br>
> > NotImplementedError: Wrong number of arguments for overloaded function 'SBTarget_BreakpointCreateByLocation'.<br>
> >   Possible C/C++ prototypes are:<br>
> >     BreakpointCreateByLocation(lldb::SBTarget *,char const *,uint32_t)<br>
> >     BreakpointCreateByLocation(lldb::SBTarget *,lldb::SBFileSpec const &,uint32_t)<br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>