search for: buildlocationlist

...alue(token %undef, %i, !Struct, > !DIExpression(DW_OP_bit_piece(0, 32))) > call llvm.dbg.value(token %tok2, metadata i32 0, !Struct, > !DIExpression(DW_OP_bit_piece(32, 32))) > > On the upside, having all this information explicit could simplify the > code in DwarfDebug::buildLocationList(). > Yeah, this is true. We could potentially extend the semantics by allowing separate key calls for pieces, i.e. %token = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32))) call llvm.dbg.value(token undef, %j, !Struct, !DIExpression(DW_OP_bit_pie...

...all llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32))) >           call llvm.dbg.value(token %tok2, metadata i32 0, !Struct, !DIExpression(DW_OP_bit_piece(32, 32))) > > On the upside, having all this information explicit could simplify the code in DwarfDebug::buildLocationList(). > > Yeah, this is true. We could potentially extend the semantics by allowing separate key calls for pieces, i.e. >   > %token = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32))) >            call llvm.dbg.value(token undef, %j, !Struct, !DIExp...

...the register is not clobbered outside the function prologue and epilogue the the range is the entire function. This is a heuristic to make stack frame-allocated variables work better. Otherwise the range extends until the next DBG_VALUE or the end of the basic block. 2. The buildLocationList() function takes the list of ranges of one variable and builds a location list. A variable may consist of many pieces which have their own live ranges. A live ranges for a piece is split up so that no piece's live range starts or ends in the middle of another piece's live range....

...; !DIExpression(DW_OP_bit_piece(0, 32))) >> > call llvm.dbg.value(token %tok2, metadata i32 0, !Struct, >> !DIExpression(DW_OP_bit_piece(32, 32))) >> > >> > On the upside, having all this information explicit could simplify the >> code in DwarfDebug::buildLocationList(). >> > >> > Yeah, this is true. We could potentially extend the semantics by >> allowing separate key calls for pieces, i.e. >> > >> > %token = call llvm.dbg.value(token %undef, %i, !Struct, >> !DIExpression(DW_OP_bit_piece(0, 32))) >> >...

Thanks for your comments. Replies inline. > The DWARF 5 standard says that > "Address range entries in a range list may not overlap.” > > The reasoning behind this is presumably that if a variable is in more than > one > location at a point all the values need to be identical, or the > information is useless Oh huh, for some reason I was under the impression that they

...ered > outside the function prologue and epilogue the the range is the > entire function. This is a heuristic to make stack > frame-allocated variables work better. Otherwise the range > extends until the next DBG_VALUE or the end of the basic block. > > 2. The buildLocationList() function takes the list of ranges of one > variable and builds a location list. A variable may consist of many > pieces which have their own live ranges. A live ranges for a piece > is split up so that no piece's live range starts or ends in the > middle of another pie...