How to call a C++ method from within an lldb summary format in XCode?

Question

XCode Version 6.3.2 (6D2105)

The variable I'm attempting to display is of type boost::posix_time::ptime but my question applies to any C/C++ type. The documentation for boost::posix_time::ptime specifies that the date part of the time (year, month, day) is retrieved by the date() method, and the fractional part of the time (hours, minutes, seconds) is returned by the time_of_day() method. So right-clicking on the variable in the list while the debugger is active allows me to set the summary format, and to just display the year part of the date should be something like {$VAR.date().year()} . Ideally I would like to print 2015/6/11 3:20:29 in the summary next to the variable in the debugger view, but for now I'm just trying to display the year part.

However, 'Summary Unavailable' is displayed, and the output window prints:

error: call to a function 'boost::date_time::date<boost::gregorian::date, boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::year() const' ('_ZNK5boost9date_time4dateINS_9gregorian4dateENS2_18gregorian_calendarENS2_13date_durationEE4yearEv') that is not present in the target

The documentation (PDF format) states that summary format expressions can contain function and method calls, but the example given is for Objective C, not C++. This is in the main section Writing Data Formatters and sub-section Expressions, including function or method calls

Answer 1

The error you are getting indicates that you are trying to call a function that doesn't exist in the program you are running. With C++ that can happen if the function was only ever present inlined. The debugger doesn't currently know how to construct callable versions of functions from headers, and we certainly can't call an inlined version of it. You can verify this by running nm on your binary and see if there really is a symbol like that around.

The other possibility is there is such a function, but it differs by const or that the type of one of the arguments is slightly different from the one the expression parser guessed it would be, so we are looking for a slightly different mangled name, and not finding it. If a plausible looking candidate does indeed show up when you do nm on the binary and we aren't calling it, please file a bug with the bug reporter at:

http://lldb.llvm.org

so somebody can take a look at it.