search for: dw_tag_label

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, I notice...

...-----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, 2019, at 1:06 PM, Snider, Todd via llvm-dev <llvm- > dev at lists.llvm.org> wrote: > > > > > > In llvm/lib/MC/MCDwarf.cpp’s EmitGenDwarfAbbrev(), the DWARF > abbreviation declaration for a...

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

...ct format, we need to keep debug format-independent data in DebugHandlerBase. Afterwards, we could convert these data to CodeView format or DWARF format. 6. Create DWARF DIE specific data structure in DwarfDebug. In class DwarfDebug, we keep DWARF specific data structure for DILabel. 7. Generate DW_TAG_label and fill details of DW_TAG_label. Finally, generating DW_TAG_label DIE and its attributes into DIE structure. I am looking forward to any thoughts & feedback!

...bel, we might as well use the location of the first instruction in the basic block described by the label, since that is where execution will continue. 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. Let me know what you think! -- adrian > > 2. Create MI instruction DBG_LABEL. > > I create new MI instruction DBG_LABEL to keep debug information after > LLVM IR 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 parent scope. In C/C++ the only scope is the containing function, which I...

...the location of the first instruction in the basic block described by the label, since that is where execution will continue. >>> >>> 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. >> I still think that we should collect debug information from source >> code level instead of infer from instructions in the basic block. As >> Paul said, "th...

...ight as well use the location of the first instruction in the basic block described by the label, since that is where execution will continue. > > 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. I still think that we should collect debug information from source code level instead of infer from instructions in the basic block. As Paul said, "the top instructions in a blo...

...;> Subject: Re: [llvm-dev] [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 parent scope. In C/C++ the only scope is...

...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 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 parent scope. In C/C++ the only scope is the > conta...

...at-independent data in > DebugHandlerBase. Afterwards, we could convert these data to CodeView > format or DWARF format. > > 6. Create DWARF DIE specific data structure in DwarfDebug. > > In class DwarfDebug, we keep DWARF specific data structure for DILabel. > > 7. Generate DW_TAG_label and fill details of DW_TAG_label. > > Finally, generating DW_TAG_label DIE and its attributes into DIE structure. > > I am looking forward to any thoughts & feedback! > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.o...

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

...at-independent data in > DebugHandlerBase. Afterwards, we could convert these data to CodeView > format or DWARF format. > > 6. Create DWARF DIE specific data structure in DwarfDebug. > > In class DwarfDebug, we keep DWARF specific data structure for DILabel. > > 7. Generate DW_TAG_label and fill details of DW_TAG_label. > > Finally, generating DW_TAG_label DIE and its attributes into DIE structure. > > I am looking forward to any thoughts & feedback! > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.o...

...] 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 parent scope. In C/C+...

...ell use the location of the first instruction in the basic block described by the label, since that is where execution will continue. >> >> 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. > I still think that we should collect debug information from source > code level instead of infer from instructions in the basic block. As > Paul said, "the top instru...

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

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

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 submit the patches? Son Tuan Vu On Mon, Apr 2, 2018 at 5:37 PM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Apr 1, 2018, at 9:12 AM, Hsia...

...ation 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 parent sc...

> 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