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

Displaying 20 results from an estimated 1000 matches similar to: "[RFC] Generate Debug Information for Labels in Function"

2018 Mar 28
0
[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
2018 Mar 28
0
[RFC] Generate Debug Information for Labels in Function
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
2018 Mar 29
0
[RFC] Generate Debug Information for Labels in Function
> > 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
2018 Mar 30
2
[RFC] Generate Debug Information for Labels in Function
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
2018 Mar 30
4
[RFC] Generate Debug Information for Labels in Function
> 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
2019 Jan 30
2
[RFC] Generate Debug Information for Labels in Function
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
2018 Mar 30
0
[RFC] Generate Debug Information for Labels in Function
> 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
2018 Apr 02
2
[RFC] Generate Debug Information for Labels in Function
> 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
2018 May 28
0
[RFC] Generate Debug Information for Labels in Function
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
2019 Jan 18
2
Potential DWARF debug info bug: DW_TAG_label DIE has a DW_AT_prototyped attribute
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,
2019 Jan 18
2
Potential DWARF debug info bug: DW_TAG_label DIE has a DW_AT_prototyped attribute
> -----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,
2008 Oct 11
2
[LLVMdev] api changes in llvm 2.4
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
2018 Mar 29
2
[RFC] Generate Debug Information for Labels in Function
> 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
2020 Jul 19
2
Instrument intrinsic invalid
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(),
2017 May 09
2
lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIEntry(const llvm::DbgVariable&): Assertion `V.Var == Var && "conflicting variable"' failed.
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
2018 Mar 29
2
[RFC] Generate Debug Information for Labels in Function
> 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:
2017 May 09
2
lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIEntry(const llvm::DbgVariable&): Assertion `V.Var == Var && "conflicting variable"' failed.
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 >>
2008 Oct 13
0
[LLVMdev] api changes in llvm 2.4
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
2018 Mar 29
0
[RFC] Generate Debug Information for Labels in Function
> -----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
2009 Oct 26
2
R CMD check: Error in .C
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