search for: dw_op_bit_pieces

...(0, 32))) call llvm.dbg.value(token undef, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32))) ; This now only invalidates the .j part %tok2 = call llvm.dbg.value(token %undef, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32))) In that case we would probably have to require that all DW_OP_bit_pieces in non-key-call expressions are a subrange of those in the associated key call. Is there any information in the tokens that could not be recovered by a > static analysis of the debug intrinsics? > Note that having redundant information available explicitly is not > necessarily a bad thing...

...llvm.dbg.value(token undef, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32))) > > ; This now only invalidates the .j part > %tok2 = call llvm.dbg.value(token %undef, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32))) > > In that case we would probably have to require that all DW_OP_bit_pieces in non-key-call expressions are a subrange of those in the associated key call. > > This way all non-key-call additional locations are describing alternative locations for (a subset of) the bits described the key-call location. Makes sense, and again would simplify the backend’s work. >...

..._bit_piece(32, 32))) >> > >> > ; This now only invalidates the .j part >> > %tok2 = call llvm.dbg.value(token %undef, %j, !Struct, >> !DIExpression(DW_OP_bit_piece(32, 32))) >> > >> > In that case we would probably have to require that all >> DW_OP_bit_pieces in non-key-call expressions are a subrange of those in the >> associated key call. >> > >> > This way all non-key-call additional locations are describing >> alternative locations for (a subset of) the bits described the key-call >> location. Makes sense, and aga...

We are running into trouble with debug information in that we have registers along with sub registers, and they both point to the same dwarf register. Does LLVM support the DW_OP_piece/bit_piece debug information when allocating a sub-register from a super register? If not, is there any plan to add it? If not, would it be difficult to add? Thanks, Micah -------------- next part -------------- An

On Jul 7, 2011, at 12:08 PM, Villmow, Micah wrote: > We are running into trouble with debug information in that we have registers along with sub registers, and they both point to the same dwarf register. Does LLVM support the DW_OP_piece/bit_piece debug information when allocating a sub-register from a super register? If not, is there any plan to add it? If not, would it be difficult to add?

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {

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

On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> LLVM SSA values obviously do not have an address that we can take and >> they don’t live in registers, so neither the default memory location model >> nor DW_OP_regN make sense

It's worth remembering that there are two syntactically similar but semantically different kinds of "expression" in DWARF. A DWARF expression computes a value; if the available value is a pointer, you add DW_OP_deref to express the pointed-to value. A DWARF location expression computes a location, and adds various operators to express locations that a (value) expression cannot, such

Debug info today handles two cases reasonably well: 1. At -O0, dbg.declare does a good job describing variables that live at some known stack offset 2. With optimizations, variables promoted to SSA can be described with dbg.value This leaves behind a large hole in our optimized debug info: variables that cannot be promoted, typically because they are address-taken. This is