similar to: Fwd: RFC: Adding debug information to LLVM to support Fortran

Regarding flags, I was just thinking that maybe we should invent a new DISubprogramFlags type. DISubprogram already has a few bitfields for subprogram-specific things, Fortran will want 3 more, and there's no reason to fill up the generic DIFlags with more bits that are used in only one class. I agree that the array stuff needs to be designed with an eye to handling how other languages do

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i

Hi, ctfconvert is particularly unhappy about that (e.g., ERROR: ctfconvert: die 141: base type without name). Is it intended behavior? Simple testcase: int main(void) { int i[2]; return 0; } dwarfdump output: clang version 3.0 (tags/RELEASE_30/final): [...] LOCAL_SYMBOLS: [...] <3>< 120> DW_TAG_variable DW_AT_name i

Adrian, Thanks for a quick reply! On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Hi, >> >> I'm trying to achieve the following: >> >> - I have a global variable BaseAddress that holds the base address of >> a

On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Adrian, >> >> Thanks for a quick reply! >> >> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>>

> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Adrian, > > Thanks for a quick reply! > > On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Hi, >>>

On Thu, Mar 22, 2018 at 5:13 PM, Roman Levenstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Adrian, >>> >>> Thanks for a quick reply!

Hi, I'm trying to achieve the following: - I have a global variable BaseAddress that holds the base address of a contiguous dynamically allocated memory block. - I have a number of logical variables of different types that are mapped on certain address ranges inside the memory block pointed to by BaseAddress. The offset and the size of each such logical variable inside the memory block are

> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Hi, > > I'm trying to achieve the following: > > - I have a global variable BaseAddress that holds the base address of > a contiguous dynamically allocated memory block. > > - I have a number of logical variables of different types that are > mapped on certain address

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via

Let me try to summarize the implementation first. At the moment, there are two branches. 1. When an existing variable is optimized out and that variable is used to get the de-refereced value, pointed to by another pointer/reference variable. Such cases are being addressed using Dwarf expression DW_OP_implicit_pointer as de-referenced value of a pointer can be seen implicitly (using another

Hi David, Happy new year ! I just uploaded a POC patch that covers the cases when pointer points to un-named variables using DW_OP_implicit_pointer (references and dynamic allocation). This is using artificial variable as suggested by Paul. https://reviews.llvm.org/D72055 I hope that now it should address your concerns. Scope of DW_OP_implicit_pointer: As we initially decided split of

Hi, I see things like this. What does it mean? Is it documented somewhere? Thanks. ; preds = %for.body https://llvm.org/docs/LangRef.html ; <label>:91: ; preds = %88 %92 = load i8**, i8*** @glob_complete_word.matches, align 8, !dbg !99798 %93 = load i32, i32* @glob_complete_word.ind, align 4, !dbg !99799 %94 = sext i32 %93 to i64, !dbg !99798

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)? If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

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

> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values. > Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct? The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this