[lldb-dev] Question on assert

[Todd Fiala via lldb-dev]

This seems to be working.  I put it up for review here, Tamas:

http://reviews.llvm.org/D13777

On Thu, Oct 15, 2015 at 9:03 AM, Todd Fiala <todd.fiala at gmail.com> wrote:

> I'm re-running the tests to make sure, but I think that fixed it.  I had
> always seen it at least once on test runs locally, but didn't see it on the
> last one.
>
> On Thu, Oct 15, 2015 at 8:10 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> Okay!  I'll give that a shot now and report back what I find.
>>
>> Thanks, Tamas :-)
>>
>> -Todd
>>
>> On Thu, Oct 15, 2015 at 3:37 AM, Tamas Berghammer <tberghammer at google.com
>> > wrote:
>>
>>> Hi Todd,
>>>
>>> The 64 bit ID of a DIE is built up in the following way:
>>> * The offset of the DIE is in the lower 32 bit
>>> * If we are using SymbolFileDWARF then the higher 32 bit is the offset
>>> of the compile unit this DIE belongs to
>>> * If we are using SymbolFileDWARFDwo then the higher 32 bit is the
>>> offset of the base compile unit in the parent SymbolFileDWARF
>>> * If we are using SymbolFileDWARFDebugMap then the higher 32 bit is the
>>> ID of the SymbolFileDWARF this DIE belongs to
>>> * If the higher 32 bit is 0 then that means that the source of the DIE
>>> isn't specified
>>>
>>> The assert then tries to verify that one of the following conditions
>>> holds:
>>> * The higher 32 bit of "id" is 0 what means that we don't have a symbol
>>> file pointer (AFAIK shouldn't happen) or we are coming from a
>>> SymbolFileDWARF
>>> * The higher 32 bit of "cu_id" is 0 what means that the compile unit is
>>> at 0 offset what is the case for the single compile units in
>>> SymbolFileDWARFDwo (and I think for SymbolFileDWARFDebugMap)
>>> * The higher 32 bit of "id" (what is the ID of the SymbolFileDWARF we
>>> are belonging to) matches with the higher 32 bit of "cu_id" (what is the
>>> offset of the compile unit in the base object file)
>>>
>>> After thinking a bit more about the assert I think the problem is that
>>> the way I calculate cu_id is incompatible for the case when we are using
>>> SymbolFileDWARFDebugMap.
>>>
>>> I think changing line 188 to the following should fix the issue:
>>> lldb::user_id_t cu_id = m_cu->GetID()&0xffffffff00000000ull;
>>>
>>> Please give it a try on OSX and let me know if it helps. I tested it on
>>> Linux and it isn't cause any regression there.
>>>
>>> Thanks,
>>> Tamas
>>>
>>> On Wed, Oct 14, 2015 at 9:13 PM Todd Fiala <todd.fiala at gmail.com> wrote:
>>>
>>>> Hi Tamas,
>>>>
>>>> There is an assert in DWARFDIE.cpp (lines 189 - 191) that we're hitting
>>>> on the OS X side somewhat frequently nowadays:
>>>>
>>>>             assert ((id&0xffffffff00000000ull) == 0 ||
>>>>
>>>>                     (cu_id&0xffffffff00000000ll) == 0 ||
>>>>
>>>>                     (id&0xffffffff00000000ull) == (cu_id&
>>>> 0xffffffff00000000ll));
>>>>
>>>>
>>>> It does not seem to get hit consistently.  We're trying to tease apart
>>>> what it is trying to do.  It's a bit strange since it is saying that the
>>>> assert should not fire if any one of three clauses is true.  But it's hard
>>>> to figure out what exactly is going on there.
>>>>
>>>>
>>>> Can you elucidate what this is trying to do?  Thanks!
>>>>
>>>> --
>>>> -Todd
>>>>
>>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151015/78eb3654/attachment.html>