Hi,
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:
def get_child_at_index(self,index):
logger = Logger.Logger()
if index < 0:
return None
if index >= self.num_children():
return None;
if self.garbage:
return None
try:
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
return None
if self.get_data_type():
if not(need_to_skip):
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 [0]
return
self.valobj.CreateValueFromData('[' + str(index) + ']',obj_data,self.data_type)
else:
# FIXME we need to have accessed item 0
before accessing any other item!
if self.skip_size == None:
return None
return current.CreateChildAtOffset('['
+ str(index) + ']',self.skip_size,self.data_type)
else:
print "foo"
return None
except Exception as err:
print err
return None
"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
Thanks,
Enrico Granata
✉ egranata@.com
✆ (four oh eight) 862-7683
On Mar 30, 2012, at 2:54 AM, Filipe Cabecinhas wrote:
> Hi,
>
> 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?).
>
>
> Filipe
>
>
> On Thursday, March 29, 2012 at 6:31 PM, Enrico Granata wrote:
>
>> Hi,
>>
>> 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.
>>
>> Thanks.
>>
>> Enrico Granata
>> ✉ egranata@.com
>> ✆ (four oh eight) 862-7683
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
