search for: dw_tag_labels

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,

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 reference the lab...

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 program static int myfunction (int arg) { int i, j, r; j = 0; /* myfunction location */ r = arg; top: ++j; /* top location */ if (j == 10) goto

> > 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

> 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

> 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

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 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:

> -----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

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

...: Why not use DW_AT_ranges even when the range is contiguous? That way the low_pc that previously couldn't use an existing address pool entry + offset, could use the rnglist support for base address. The only unnecessary address pool entries that remain that I've found are DW_AT_low_pc for DW_TAG_labels - but there's only a handful of those in most code. So the "ranges everywhere" strategy gets the addresses for optimized clang down from 4758 (v4 address pool used 9923 addresses... ) to 342, with about ~4 "extra" addresses for DW_TAG_labels. This could also be a bit less c...

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

> -----Original Message----- > From: aprantl at apple.com [mailto:aprantl at apple.com] > Sent: Thursday, March 29, 2018 2:23 PM > To: Robinson, Paul > Cc: hsiangkai at gmail.com; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Generate Debug Information for Labels in > Function > > > > > On Mar 29, 2018, at 10:55 AM, paul.robinson at sony.com

> 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

...en the range is contiguous? That way the low_pc that > previously couldn't use an existing address pool entry + offset, could use > the rnglist support for base address. > > > > The only unnecessary address pool entries that remain that I've found > are DW_AT_low_pc for DW_TAG_labels - but there's only a handful of those > in most code. So the "ranges everywhere" strategy gets the addresses for > optimized clang down from 4758 (v4 address pool used 9923 addresses... ) > to 342, with about ~4 "extra" addresses for DW_TAG_labels. > > > &g...

...s? That way the low_pc that > > previously couldn't use an existing address pool entry + offset, could use > > the rnglist support for base address. > > > > > > The only unnecessary address pool entries that remain that I've found > > are DW_AT_low_pc for DW_TAG_labels - but there's only a handful of those > > in most code. So the "ranges everywhere" strategy gets the addresses for > > optimized clang down from 4758 (v4 address pool used 9923 addresses... ) > > to 342, with about ~4 "extra" addresses for DW_TAG_labels. &g...

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

> On Mar 29, 2018, at 11:51 AM, paul.robinson at sony.com wrote: > > > >> -----Original Message----- >> From: aprantl at apple.com [mailto:aprantl at apple.com] >> Sent: Thursday, March 29, 2018 2:23 PM >> To: Robinson, Paul >> Cc: hsiangkai at gmail.com; llvm-dev at lists.llvm.org >> Subject: Re: [llvm-dev] [RFC] Generate Debug Information for

> 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