[lldb-dev] How to set source line breakpoint using BreakpointCreateByLocation?
Jeffrey Tan via lldb-dev
lldb-dev at lists.llvm.org
Mon Mar 7 17:27:04 PST 2016
Thanks for the info, I will debug this.
One more quick question related to this: in full path breakpoint case(IDE
scenario), do we compare both file name and directory path exact match and
bind breakpoint successfully? I ask this because of the breakpoint issue I
found:
1. I have a symbolic link folder "/home/jeffreytan/foo/" which points to
"/data/users/jeffreytan/bar/foo".
2. If I built cpp file in /home/jeffreytan/foo/, and try to set breakpoint
using real path "b /data/users/jeffreytan/bar/foo/main.cpp:10" it will fail
to bind.
3. While "b /home/jeffreytan/foo//main.cpp:10" binds fine, vise verse.
I can't control how users open/build file in our IDE, they may choose to
open/build from symbolic link folder or real path folder. What is the
general suggestion to deal with symbolic link differences?
Jeffrey
On Mon, Mar 7, 2016 at 4:25 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> > On Mar 7, 2016, at 4:08 PM, Jeffrey Tan <jeffrey.fudan at gmail.com> wrote:
> >
> > Hi Greg,
> >
> > I am not sure if I understand the behavior here: the long relative file
> path from our build system does *not* exist on file system, do you mean
> lldb will always try to resolve this relative path to a *real* file on file
> system using stat() call?
>
> No it doesn't do that and that is why you path remains as is.
>
> > And it will fail to bind the breakpoint if can't find the resolved file
> path?
>
> No it shouldn't if you set it by basename. If it does fail to set the
> breakpoint using "EATAnimatedView.m" as the filename, then it is a bug.
>
> >
> > Per my testing, I was able to use #1. "b EATAnimatedView.m:33" to bind
> breakpoint, but not:
> > #2, "b
> .//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:20"
>
> That is interesting, and you will need to track down why this is
> happening. Obviously we are expecting this kind of path and something is
> going wrong.
>
> > break list --verbose
> > Current breakpoints:
> > 2: file =
> './/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
> line = 20
> >
> > 3: file = 'EATAnimatedView.m', line = 33
> > 3.1:
> > module =
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/32967F60-A4C3-43DC-ACA8-92D819413362/data/Containers/Bundle/Application/96DA24F5-E35D-402F-B4B7-1C5BBD40B270/MPKEats.app/MPKEats
> > compile unit = EATAnimatedView.m
> > function = -[EATAnimatedView
> initWithFrame:imageNames:animationDuration:repeatCount:touchEnabled:]
> > location =
> ./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:33
> > address = 0x000000010a1ff798
> > resolved = true
> > hit count = 0
> >
> > Do you mean #2 should work?
>
> I would expect #2 to work, but not surprised it doesn't.
>
> > I think I am a bit vague on how source breakpoint is supposed to work.
> What is the algorithm to successfully bind breakpoint here?
>
> What we currently do is break all file paths up into a basename
> (EATAnimatedView.m) and a directory
> (.//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View).
>
> We break up filenames like this because the user will rarely type full
> paths in commands. IDEs will often give us full paths to files, but users
> rarely do. So to efficiently store files and make them easy to compare, we
> split the path up into two strings. Each string gets constified by being
> placed into a ConstString object that uniques the string and gives out the
> same pointer for each string it uniques so we can use pointer comparisons
> to compare two strings. FileSpec objects contain:
>
> class FileSpec
> {
> protected:
> //------------------------------------------------------------------
> // Member variables
> //------------------------------------------------------------------
> ConstString m_directory; ///< The uniqued directory path
> ConstString m_filename; ///< The uniqued filename path
> mutable bool m_is_resolved; ///< True if this path has been resolved.
> PathSyntax m_syntax; ///< The syntax that this path uses (e.g.
> Windows / Posix)
> };
>
>
> So we can easily compare strings. You should probably step through some
> code and figure out why things are not matching up. The FileSpec class has
> some functions that try to clean up paths without calling stat:
>
> void
> FileSpec::NormalizePath ();
>
> void
> FileSpec::RemoveBackupDots (const ConstString &input_const_str,
> ConstString &result_const_str);
>
> And a few others. They might be causing the problems. You will need to
> debug this if you wish to figure out what is going wrong.
>
> A few tests that I ran include:
>
> (lldb) script
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
> >>> f =
> lldb.SBFileSpec('.//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
> False)
> >>> print f.GetFilename()
> EATAnimatedView.m
> >>> print f.GetDirectory()
>
> .//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View
> >>> f =
> lldb.SBFileSpec('.//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
> True)
> >>> print f.GetFilename()
> EATAnimatedView.m
> >>> print f.GetDirectory()
>
>
> .//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View
>
>
> So we seem to split the path up correctly in both cases where we don't
> resolve and resolve the path.
>
>
> >
> > Jeffrey
> >
> >
> >
> > On Mon, Mar 7, 2016 at 11:07 AM, Greg Clayton <gclayton at apple.com>
> wrote:
> > Not sure why we aren't treating this as a relative path. Probably
> because of the 1000 '/' characters. Feel free to dig into
> lldb_private::FileSpec and play around and see where things are going wrong.
> >
> > You can probably fix LLDB, when it resolves paths, to clean this up, but
> we typically don't resolve paths that we find in debug info when we run
> into it. Why? Because if you have DWARF info that contains paths that map
> to 10000 files that exist on network file system mounts, we would need to
> resolve all of those paths as we parse the line tables and calling stat()
> on all these files take a TON of time. So we won't resolve paths we find in
> debug info typically. We could try and run a path resolving function that
> doesn't call stat() to fix up an really bad paths like the ones that your
> build system is making, but we don't have support for that right now due to
> the network file system stat() issue.
> >
> > Greg
> >
> > > On Mar 5, 2016, at 11:47 AM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> > >
> > > Ooops, I accidentally dropped lldb mail list.
> > > 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. :-(
> > >
> > > I am building a workaround for this issue:
> > > 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.
> > > The assumption is that as long as I used the same SBFileSpec from
> lldb, I should use it to set source line breakpoint successfully.
> > > However, it turns out this still does not work. The breakpoints are
> listed as pending:
> > >
> > > break list
> > > Current breakpoints:
> > > 1: file =
> './/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/App/main.m',
> line = 9, locations = 0 (pending)
> > > 2: file =
> './/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m',
> line = 20, locations = 0 (pending)
> > >
> > > Questions:
> > > 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?
> > >
> > > Jeffrey
> > >
> > > On Wed, Jan 6, 2016 at 8:47 AM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> > > Nevermind, I do not know why
> "GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m", line)"
> does not work for me last October. I tried it again, it works now.
> > > I will see if I can figure out the weird relative location path in
> symbol file issue.
> > >
> > > Thanks!
> > >
> > > On Tue, Jan 5, 2016 at 3:38 PM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> > > Sorry for the late response. I finally had time to come back to this
> issue.
> > >
> > > Can anyone help me with the
> "self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
> line)" not working issue? Does it suppose to work? I can reproduce it
> pretty easily in a small python script.
> > >
> > > I found the following lldb test that uses this API:
> > >
> http://www.opensource.apple.com/source/lldb/lldb-69/test/lang/objc/objc-stepping/TestObjCStepping.py
> > >
> > > So it seems that this should work. Am I doing something wrong? I am
> importing the Xcode's lldb by following:
> > > developer_dir = subprocess.check_output(['xcode-select',
> '--print-path'])
> > > lldb_pythonpath = os.path.join(
> > > developer_dir.strip(),
> '../SharedFrameworks/LLDB.framework/Resources/Python')
> > > sys.path.append(lldb_pythonpath)
> > >
> > > For the weird long path issue, I will follow-up with our build team,
> but definitely needs to resolve the BreakpointCreateByLocation() can't be
> called issue first.
> > >
> > > Thanks for any help!
> > > Jeffrey
> > >
> > > On Thu, Oct 8, 2015 at 10:46 AM, Greg Clayton <gclayton at apple.com>
> wrote:
> > >
> > > > On Oct 8, 2015, at 10:25 AM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> > > >
> > > > Thanks Greg. Here is the info:
> > > > (lldb) br list --verbose
> > > > Current breakpoints:
> > > > 1: file = 'EATAnimatedView.m', line = 21
> > > > 1.1:
> > > > module =
> /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/12E85C41-A74F-45E1-8440-E7D08D8EB1FA/data/Containers/Bundle/Application/3BA10AF8-9B18-4FD8-8C76-EA25DE2F37E6/MPKEats.app/MPKEats
> > > > compile unit = EATAnimatedView.m
> > > > function = -[EATAnimatedView
> initWithFrame:imageNames:animationDuration:repeatCount:touchEnabled:]
> > > > location =
> ./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21
> > > > address = 0x0000000103deae42
> > > > resolved = true
> > > > hit count = 0
> > > >
> > >
> > > 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.
> > >
> > > You can modify the following function:
> > >
> > > void
> > > FileSpec::RemoveBackupDots (const ConstString &input_const_str,
> ConstString &result_const_str);
> > >
> > > 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:
> > >
> > >
> "./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m:21"
> > >
> > >
> > > 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:
> > >
> > >
> > > 0x0000000b: DW_TAG_compile_unit [1] *
> > > DW_AT_producer( "Apple LLVM version 7.x.x" )
> > > DW_AT_language( DW_LANG_ObjC )
> > > DW_AT_name(
> "./Apps/Internal/MPKEats/MPKEats/View/EATAnimatedView.m" )
> > > DW_AT_stmt_list( 0x00000000 )
> > > DW_AT_comp_dir( "/tmp/build/foo/bar" )
> > > DW_AT_low_pc( 0x0000000100000b50 )
> > > DW_AT_high_pc( 0x0000000100000e62 )
> > >
> > >
> > > 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.
> > >
> > > Can you send me your ELF file that contains the DWARF so I can look at
> it?
> > >
> > > > 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.
> > > >
> > > > 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.
> > >
> > > 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...
> > >
> > >
> > > >
> > > > Jeffrey
> > > >
> > > > On Thu, Oct 8, 2015 at 9:46 AM, Greg Clayton <gclayton at apple.com>
> wrote:
> > > > > On Oct 7, 2015, at 8:31 PM, Jeffrey Tan via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > 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?
> > > >
> > > > As long as you have a selected target, this should work as long as
> you have debug info that matches.
> > > > >
> > > > > Also, can I use full path instead of file basename?
> > > >
> > > > Yes you can, but it must match exactly if you use the full path.
> > > >
> > > > > 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.
> > > >
> > > > 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:
> > > >
> > > > (lldb) b main.c:12
> > > > Breakpoint 1: where = a.out`main + 70 at main.c:12, address =
> 0x0000000100000b96
> > > > (lldb) breakpoint list --verbose
> > > > Current breakpoints:
> > > > 1: file = 'main.c', line = 12
> > > > 1.1:
> > > > module = /Volumes/work/gclayton/Documents/src/args/a.out
> > > > compile unit = main.c
> > > > function = main
> > > > location = /Volumes/work/gclayton/Documents/src/args/main.c:12
> > > > address = a.out[0x0000000100000b96]
> > > > resolved = false
> > > > hit count = 0
> > > >
> > > >
> > > > 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.
> > > >
> > > >
> > > > > Traceback (most recent call last):
> > > > > File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/chromedebugger.py",
> line 69, in _generate_response
> > > > > params=message.get('params', {}),
> > > > > File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
> line 42, in handle
> > > > > return self._domains[domain_name].handle(method_name, params)
> > > > > File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
> line 106, in handle
> > > > > return self._handlers[method](params)
> > > > > File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/handler.py",
> line 56, in _handler_wrapper
> > > > > ret = func(self, params)
> > > > > File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
> line 248, in setBreakpointByUrl
> > > > > int(params['lineNumber']) + 1)
> > > > > File
> "/Users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide/debugger/lldb/scripts/debugger.py",
> line 283, in _set_breakpoint_by_filespec
> > > > > breakpoint =
> self.debugger.GetSelectedTarget().BreakpointCreateByLocation(filespec, line)
> > > > > File
> "/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py",
> line 8650, in BreakpointCreateByLocation
> > > > > return _lldb.SBTarget_BreakpointCreateByLocation(self, *args)
> > > > > NotImplementedError: Wrong number of arguments for overloaded
> function 'SBTarget_BreakpointCreateByLocation'.
> > > > > Possible C/C++ prototypes are:
> > > > > BreakpointCreateByLocation(lldb::SBTarget *,char const
> *,uint32_t)
> > > > > BreakpointCreateByLocation(lldb::SBTarget *,lldb::SBFileSpec
> const &,uint32_t)
> > > > > _______________________________________________
> > > > > lldb-dev mailing list
> > > > > lldb-dev at lists.llvm.org
> > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160307/668c634b/attachment-0001.html>
More information about the lldb-dev
mailing list