similar to: [RFC] Generate Debug Information for Labels in Function

LGTM. I think you can sent patch and let the ball rolling! I would like to review it. ;) 2018-03-28 10:41 GMT+08:00 Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org>: > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on

Sounds good to me. You can also see llvm.codeview.annotation which does a similar thing, but it is modeled as having internal, invisible side effects. These should stay separate, but it may provide a guide for implementation. On Tue, Mar 27, 2018 at 7:41 PM Hsiangkai Wang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello all, > > I would like to enhance LLVM debug info

> > On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on labels in function. Following is an example. > > // C

On Fri, Mar 30, 2018 at 12:05 AM, Adrian Prantl <aprantl at apple.com> wrote: >> >> On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I would like to enhance LLVM debug info that supports setting >> breakpoint on labels in function. >> >> Generally, if users use GDB

> On Mar 30, 2018, at 9:25 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: >> >> I agree with you. Attach debug metadata to basic block will be a >> better solution. I will change my design to convey debug metadata >> through basic block

What does GCC do in situations like this? I suspect the rightiest thing to do is probably multiple DW_TAG_labels with the same name, if that's what's happened. I guess another question/possibility - what happens if some inline asm references the label? I guess it probably constrains the optimizer not to unroll? Maybe? If the label can be duplicated and inline asm can still correctly

> On Mar 29, 2018, at 11:29 PM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > I agree with you. Attach debug metadata to basic block will be a > better solution. I will change my design to convey debug metadata > through basic block instead of intrinsic. > > https://reviews.llvm.org/D45078 In this revised design it is now possible to attach a DILabel to a

> On Apr 1, 2018, at 9:12 AM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > Hi all, > > I am sorry that I didn’t carefully think about how to handle labels in > inlined function. There is no need to apologize! Thank you very much for engaging in the discussion and for contributing you patches. > > Today, I did some simple experiments and found that some basic

Hello all, I am interested in this work, and have tested it a bit so far. In the latest revision, it seems to me that we do not have support in Clang (so it doesn't generate llvm.dbg.label intrinsic) and in Dwarf debug emission (so the backend doesn't generate the DW_TAG_label DIE from the DBG_LABEL Machine Instruction) yet. I attempted to implement these features, do you want me to

In llvm/lib/MC/MCDwarf.cpp's EmitGenDwarfAbbrev(), the DWARF abbreviation declaration for a DW_TAG_label includes a DW_AT_prototyped attribute, but the DWARF 4 specification indicates that the DW_AT_prototyped attribute is not a valid attribute for the DW_TAG_label debug information entry (DIE). In this case, EmitGenDwarfAbbrev() is clearly in violation of the DWARF 4 specification. However,

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Adrian Prantl via llvm-dev > Sent: Friday, January 18, 2019 5:20 PM > To: Snider, Todd > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Potential DWARF debug info bug: DW_TAG_label DIE > has a DW_AT_prototyped attribute > > > > > On Jan 18,

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

> Based on that I think it might be sufficient to have a flag on an IR label > that marks a user-originated label and triggers the backend to create a > DW_TAG_label for it. If we do need source location information for the > DW_TAG_label, we could grab it from the first instruction. Are there languages where labels are scoped? If so we'd need explicit metadata to identify the

Hi, I try to use llvm-dis to disassemble the result after opt, my pass will add a intrinsic after the load instruction, like following: bool fpscan::ldAddMetadata (Instruction *Inst, StringRef c) { std::vector<Metadata *> dataTuples; // Add metadata in list dataTuples.push_back(MDString::get(Inst->getContext(), c)); MDNode* N = MDNode::get(Inst->getContext(),

David, Dean, all, The bots got red today with assertion failures in llvm::DbgVariable::addMMIEntry: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/1816/steps/check-msan%20in%20gcc%20build/logs/stdio I did not find the offender yet. Any ideas? clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void

> On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com wrote: > > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via >> llvm-dev >> Sent: Thursday, March 29, 2018 1:54 PM >> To: aprantl at apple.com; hsiangkai at gmail.com >> Cc: llvm-dev at lists.llvm.org >> Subject: Re:

Thanks! On Mon, May 8, 2017 at 6:25 PM, Reid Kleckner <rnk at google.com> wrote: > I give it 99% odds it was r302483. Let's revert and debug it tomorrow. > > On Mon, May 8, 2017 at 6:20 PM, Kostya Serebryany via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> David, Dean, all, >> >> The bots got red today with assertion failures in >>

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via > llvm-dev > Sent: Thursday, March 29, 2018 1:54 PM > To: aprantl at apple.com; hsiangkai at gmail.com > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in > Function > > > Based on that I think it might be

Function/file names are hypothetical. Say I have written myfunction.R, which calls myfunction.c via .C("myfunction", ...). I've compiled successfully myfunction.c via R CMD SHLIB myfunction.c in the terminal. Then, in the R console: dyn.load("myfunction.so") source("myfunction.R") test <- myfunction() # works fine So everything is in order, myfunction works