search for: dbginfo

...221306). Hooray \o/ Testing this with asan, it seems to be working: Given a simple example of inlining failure: $ cat asan.cpp __attribute__((always_inline)) inline void func(int* i) { *i = 3; } int main() { func(nullptr); } The failures before this change: #0 0x4a320e in func(int*) /tmp/dbginfo/asan.cpp:1:59 #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4 And then if we delete the .dwo (to simulate running on another machine, etc, etc): #0 0x4a320e in main /tmp/dbginfo/asan.cpp:1:59 So we get the expected weird mixed stack frame. Then, with the improvements, we see: #0 0x4a32...

I've got a suggestion for a refinement: Right now, we have classes like DILocation that wrap an MDNode* to provide more convenient access to it. It would be more convenient for users if instead of MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag); Inst2->setMD(MDKind::DbgTag, DbgInfo); they could write: DILocation DbgInfo = Inst->getMD<DILocation>(); inst2->setMD(DbgInfo); we'd use TheContext->RegisterMDKind<MyKindWrapper>() or ...Register<MyKindWrapper>("name&...

Devang's work on debug info prompted this, thoughts welcome: http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt -Chris

...tables below: Abbreviations: LLVM bin size  - size of llvm  build/bin directory. LLVM build time  - compilation time for building llvm. Clang size - size of clang binary. link time - time for linking clang binary. Errors  - number of errors reported by llvm-dwarfdump --verify for clang binary. gc-dbginfo - linker option added by this patch. Spelled as "-gc-debuginfo". gc-dbgtypes - linker option added by this patch. Spelled as "-gc-debuginfo-types" Table 1. LLVM codebase. ------------------------------------------------------------------- |   |       CL options          | LLVM...

...) b/ b.cpp // does the same thing as a.cpp, but with its own external function, b() if you run "clang++ -emit-llvm -S -Iinclude -c lib/a/a.cpp lib/b/b.cpp -g" you get two .ll files both with the obvious: !9 = metadata !{metadata !"include/foo.h", metadata !"/tmp/dbginfo/pathtest"} But if you do this instead: "cd lib/a; clang++ -emit-llvm -S -I../../include -c a.cpp -g; cd ../../lib/b; clang++ -emit-llvm -S -I../../include -c b.cpp -g" you get two different nodes: !9 = metadata !{metadata !"../../include/foo.h", metadata !"/tmp/dbgin...

> On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi all, > > Consider this ARM assembly code of a C function: > > 00008124 <foo>: > 8124: push {r4, r6, r7, lr} > 8126: add r7, sp, #8 > 8128: mov r4, r0 > 812a: ldrsb.w

...onsider the consequences > carefully. > > --paulr > > > > *From:* aprantl at apple.com [mailto:aprantl at apple.com] > *Sent:* Friday, April 27, 2018 11:22 AM > *To:* Son Tuan VU > *Cc:* Robinson, Paul; Vedant Kumar; dblaikie at gmail.com; llvm-dev > *Subject:* Re: [DbgInfo] Potential bug in location list address ranges > > > > > > > > On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > > > Hi all, > > > > Consider this ARM assembly code of a C function: > > > > 00008124 &lt...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

...list purposes. But this is a tricky area, and we'd need to consider the consequences carefully. --paulr From: aprantl at apple.com [mailto:aprantl at apple.com] Sent: Friday, April 27, 2018 11:22 AM To: Son Tuan VU Cc: Robinson, Paul; Vedant Kumar; dblaikie at gmail.com; llvm-dev Subject: Re: [DbgInfo] Potential bug in location list address ranges On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com<mailto:sontuan.vu119 at gmail.com>> wrote: Hi all, Consider this ARM assembly code of a C function: 00008124 <foo>: 8124: push {r4, r...

...e.com <mailto:aprantl at apple.com> [mailto:aprantl at apple.com <mailto:aprantl at apple.com>] > Sent: Friday, April 27, 2018 11:22 AM > To: Son Tuan VU > Cc: Robinson, Paul; Vedant Kumar; dblaikie at gmail.com <mailto:dblaikie at gmail.com>; llvm-dev > Subject: Re: [DbgInfo] Potential bug in location list address ranges > > > > > > > > > On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com <mailto:sontuan.vu119 at gmail.com>> wrote: > > > > Hi all, > > > > Consider this AR...

Hi all, Consider this ARM assembly code of a C function: 00008124 <foo>: 8124: push {r4, r6, r7, lr} 8126: add r7, sp, #8 8128: mov r4, r0 812a: ldrsb.w r0, [r2] 812e: cmp r0, #1 8130: itt lt 8132: movlt r0, #85 ;

...>> >> --paulr >> >> >> >> *From:* aprantl at apple.com [mailto:aprantl at apple.com] >> *Sent:* Friday, April 27, 2018 11:22 AM >> *To:* Son Tuan VU >> *Cc:* Robinson, Paul; Vedant Kumar; dblaikie at gmail.com; llvm-dev >> *Subject:* Re: [DbgInfo] Potential bug in location list address ranges >> >> >> >> >> >> >> >> On Apr 27, 2018, at 7:48 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: >> >> >> >> Hi all, >> >> >> >> Consider this ARM...

...riday 11 September 2009 15:20, Jeffrey Yasskin wrote: > I've got a suggestion for a refinement: > > Right now, we have classes like DILocation that wrap an MDNode* to > provide more convenient access to it. It would be more convenient for > users if instead of > > MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag); > Inst2->setMD(MDKind::DbgTag, DbgInfo); > > they could write: > > DILocation DbgInfo = Inst->getMD<DILocation>(); > inst2->setMD(DbgInfo); > > we'd use TheContext->RegisterMDKind<MyKindWrapper>() or > .....

...elp how to do it? >>> >>> >> Compile the original .cpp file with clang -g option. >> The file/line is maintained in SDNodes with DebugLoc field. >> > > Can you also get this information in LLVM ? > See Analysis/DebugInfo.h, and opt -print-dbginfo for an example of how to use it. > And what about with llvm-gcc ? > Yes, if compiled with -g. Best regards, --Edwin

...ction signature: from: Value *CreatePreserveArrayAccessIndex(Value *Base, unsigned Dimension, unsigned LastIndex) to Value *CreatePreserveArrayAccessIndex(Value *Base, unsigned Dimension, unsigned LastIndex, MDNode *DbgInfo) and the clang patch uses this newly changed function. Any recommendation on what is the best practice to merge such llvm/clang inter-dependent patches? Thanks! Yonghong

>> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On >> Behalf Of Saman Aliari Zonouz >> Sent: Thursday, July 09, 2009 11:44 AM >> To: llvmdev at cs.uiuc.edu >> Subject: [LLVMdev] Source file information. >> >> Hi, >> >> I am new to LLVM, and need to find the line number

On Tue, Sep 24, 2019 at 11:22 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alexay, > > Thank you for the detailed explanation. The other question I have is, as > discussed above, about dsymutil. You said that dsymutil is not usable at > link-time. What does that mean? If we only have to emit an output file in > the usual way and then automatically

...will be nice if I can know which line in the source an >> instruction (or value) corresponds to. >> >> I found a document online: >> http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an >> example of doing it at the byte code level. > > -print-dbginfo should print the source lines, at least the one in 2.6, > the one in 2.7 seems to have the source line printing removed. > > I'll add it back when I get some time. > > Best regards, > --Edwin > _______________________________________________ > LLVM Developers mailing lis...

Just working on some of the gmlt+fission debug info stuff and I came across a comment that might be relevant to reducing the number of distinct debugloc metadata nodes: "or some sub-optimal metadata that // isn't structurally identical (see: file path/name info from clang, which // includes the directory of the cpp file being built, even when the file name // is absolute (such as

...writing a > passer and if will be nice if I can know which line in the source an > instruction (or value) corresponds to. > > I found a document online: > http://llvm.org/docs/SourceLevelDebugging.html, but I can't find an > example of doing it at the byte code level. -print-dbginfo should print the source lines, at least the one in 2.6, the one in 2.7 seems to have the source line printing removed. I'll add it back when I get some time. Best regards, --Edwin