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.
