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.fi...@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.fi...@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 <tbergham...@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.fi...@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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
