[lldb-dev] lldb tests
egranata at apple.com
Fri Mar 30 07:26:44 PDT 2012
The 'foo' is indeed a left-over debugging printout. I usually remove them before committing the files, but every once in a while one remains. I will replace it with a Logger call later today.
If you actually read the code for libcxx.py:
logger = Logger.Logger()
if index < 0:
if index >= self.num_children():
iterator = stdmap_iterator(self.root_node,max_count=self.num_children())
# the debug info for libc++ std::map is such that __begin_node_ has a very nice and useful type
# out of which we can grab the information we need - every other node has a less informative
# type which omits all value information and only contains housekeeping information for the RB tree
# hence, we need to know if we are at a node != 0, so that we can still get at the data
need_to_skip = (index > 0)
current = iterator.advance(index)
if current == None:
self.garbage = True
current = current.Dereference()
obj = current.GetChildMemberWithName('__value_')
obj_data = obj.GetData()
self.get_value_offset(current) # make sure we have a valid offset for the next items
# we do not return __value_ because then we would end up with a child named
# __value_ instead of 
return self.valobj.CreateValueFromData('[' + str(index) + ']',obj_data,self.data_type)
# FIXME we need to have accessed item 0 before accessing any other item!
if self.skip_size == None:
return current.CreateChildAtOffset('[' + str(index) + ']',self.skip_size,self.data_type)
except Exception as err:
"foo" is printed when self.get_data_type() does not work. On my side, the right thing to do is add a fair amount of logging to better diagnose this and similar scenarios.
On your side, there are several possibilities:
(a) wait for the logging to be in, and then repeat the test case and send the new log files
(b) send the a.out and associated dSYM and let's check if they look correct or the older compiler is doing something wrong with the debug info
(c) compile a new clang from TOT and retry using the updated compiler
✆ (four oh eight) 862-7683
On Mar 30, 2012, at 2:54 AM, Filipe Cabecinhas wrote:
> Attahced is the output of the test ran in verbose mode.
> There's a very weird 'foo' that is shown after I enabled logging in the test (I enables verbose formatter logging right before the instruction that fails).
> That print comes from stdmap_SynthProvider.get_child_at_index(), on line 546 of the Python/libcxx.py file. It seems like some kind of error, maybe you know what it's about (Something unfinished in that file?).
> On Thursday, March 29, 2012 at 6:31 PM, Enrico Granata wrote:
>> a good first step is for you to run the test in verbose mode and attach the output.
>> You can also try to manually repeat the test case behavior and seeing what you get.
>> Moving from there should not be too complicated.
>> As for tool versions, I am using a previous version of swig because of licensing issues. I also have a more recent clang based off LLVM 3.1 svn. I am not sure why that would be the case but given that the test case at fault here is related to libc++ I would guess that the build of libc++ has something to do with it. However, we are on the same OSX version.
>> Enrico Granata
>> ✉ egranata@.com
>> ✆ (four oh eight) 862-7683
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev