similar to: [LLVMdev] metadata linking bug or by design

I looked at an earlier version. NamedMDNodes were linked after global values. Current trunk version links NamedMDNodes before that, though the comment says otherwise: "We do this after linking GlobalValues so that MDNodes that reference GlobalValues are properly remapped". see ModuleLinker::run in lib/Linker/LinkModules.cpp. If I move the call to linkNamedMDNodes in ModuleLinker::run

On Aug 4, 2011, at 11:30 AM, Xi Wang wrote: > I looked at an earlier version. NamedMDNodes were linked after global > values. Current trunk version links NamedMDNodes before that, though > the comment says otherwise: "We do this after linking GlobalValues so > that MDNodes that reference GlobalValues are properly remapped". see > ModuleLinker::run in

On Aug 4, 2011, at 8:21 AM, Xi Wang wrote: > Hi, > > It seems that current linker "drops" updated llvm::Value * references > in metadata. Here goes an example. We have a two-line source file > a.c: > > static int x; > void foo() { x = 1; } > > and a similar b.c: > > static int x; > void bar() { x = 1; } > > They both have an internal

> 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

However, I do have: !924 = metadata !{i32 786484, i32 0, null, metadata !"r", metadata !"r", metadata !"", metadata !841, i32 19, metadata !56, i32 0, i32 1, i32* @r} ; [ DW_TAG_variable ] [r] [line 19] [def] with on which `!0` is indirectly dependent and there is `!llvm.dbg.cu = !{!0}` . On Wed, Feb 27, 2013 at 11:35 AM, Alexandru Ionut Diaconescu <

Hi Sourabh, Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete. If at all possible, I’d /much/ rather we use the existing

*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf Of *Eric Schweitz (PGI) *Sent:* Thursday, November 01, 2018 1:02 PM *To:* flang-dev at lists.flang-compiler.org *Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support Fortran In order to support debugging in the Flang project, work has been done to extend LLVM debug information for the Fortran

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

Hello, I followed the http://stackoverflow.com/questions/13852180/how-to-get-variable-definition-line-number-etc-using-dbg-metadatain order to get the line number definition for local variables (allocas), which works fine. But I need the same for globals. So I tried to hack the `findDbgGlobalDeclare()` method from http://llvm.org/docs/doxygen/html/DbgInfoPrinter_8cpp_source.html#l00062 . However,

Hello Everyone, I need to have your thoughts on this. Consider the following test case -- ------------------------------------------- 1 int main(int Argc, char **Argv) { 2 int Local = 6; 3 printf("%d\n",Local); 4 5 { 6 printf("%d\n",Local); 7 int Local = 7; 8 printf("%d\n",Local); 9 }

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, I would like to implement a fix to how LLVM handles/creates debug info for entities declared inside a basic block. Below you will find 5 parts: 1. Motivation for this fix. 2. Background explaining the cases that need to be fixed. 3. An example for each case. 4. Proposal on how to represent each case in dwarf. 5. Secondary (workaround) proposal which might be

> 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

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 currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly. The core point of my confusion: Why does describing the thing a pointer

On Mon, Dec 14, 2015 at 7:01 AM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I verified that GDB 7.10 does support “DW_AT_abstract_origin” attribute on > “DW_TAG_lexical_block”. > I take it you mean that it does the right thing, finding the direct children of the abstract block when stepping into the inlined subroutine, etc? & this was a

Chandler Carruth wrote: > On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <wendling at apple.com > <mailto:wendling at apple.com>> wrote: > > On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote: > > > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling > <wendling at apple.com <mailto:wendling at apple.com>> wrote: > > Hello, >

Hi, I have a question regarding the metadata for compileunit debug info. I find a few things in it a bit strange, but maybe there it is a reason for it to be that way that I just don't understand (but if that is the case I guess the documentation needs to be clearer). Consider this C program: "int X;" Compiled with "clang -g" it debug metadata along these lines:

On Jan 24, 2012, at 9:11 PM, Nick Lewycky wrote: > Yeah, I can't think of any use for something that would pull out NamedMDNodes for no reason. That said, if you want this to work, please audit the module cloner at the very least (it should copy the NamedMDNodes). > > But what would you do with llvm-extract? llvm-extract already copies over named metadata. > Should it keep 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: >>> >>> >>>>

Thanks. isFreeCall() works well but for %call2 = call i32 bitcast (i32 (...)* @free to i32 (i8*)*)(i8* %call1) nounwind, !dbg !16 So I tried to figure out when the above instruction occurred. When <stdlib.h> is included, free(buf2R1); turn into call void @free(i8* %call1) nounwind, !dbg !16 when I forget to include <stdlib.h>, free(buf2R1); turn into %call2 = call i32 bitcast (i32