[llvm-dev] about __attribute__((artificial)) and inline pass

[David Blaikie via llvm-dev]

On Fri, Jan 28, 2022 at 12:07 PM Robinson, Paul <paul.robinson at sony.com>
wrote:

> In order to get the described effect, I think we’d need to put
> DW_AT_artificial on the subprogram, and then not attach source locations to
> the generated code.  That would have the effect of not allowing break/step
> inside, but the subprogram name is still available. This is not the same as
> `nodebug`, where you lose the subprogram name too.
>
> Shouldn’t be at all hard to get this to work.
>

That doesn't seem to be the described or actual effect (testing GCC's debug
info, even for __attribute__((artificial)) functions, the locations inside
the function (inlined or non-inlined) are attributed to their original
source location, not to the call site) - I believe the intent is that only
effect of the attribute is to add the DW_AT_artificial attribute to the
function (& that seems to be the implemented effect) - but if GCC is
emitting some other debug info format (not sure what other formats it
supports) that doesn't have an equivalent to DW_AT_artificial, it does the
next best thing - which is to attribute the inlined source locations to the
call site. (unclear what it does for non-inlined code in that case - though
interestingly the attribute is only valid in GCC on functions that are
marked "inline"... which seems like a weird limitation to me).

I believe Clang is implementing the same behavior as GCC, as far as DWARF
is concerned at least. It appears to be a documentation issue to me.

- Dave


>
>
> Fangqing, would you be able to file an issue for this?
>
> Thanks,
>
> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *David
> Blaikie via llvm-dev
> *Sent:* Friday, January 28, 2022 2:37 PM
> *To:* Reid Kleckner <rnk at google.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] about __attribute__((artificial)) and inline
> pass
>
>
>
> On Fri, Jan 28, 2022 at 11:26 AM Reid Kleckner <rnk at google.com> wrote:
>
> I thought `artificial` and `nodebug` were supposed to be synonyms, just
> different names invented by different communities.
>
>
> Doesn't look like it, based on the GCC documentation and behavior - GCC
> puts the DW_AT_artificial attribute on the entity, but still fully
> describes it (DWARF remains the same except for that attribute). I think
> the second option in the GCC docs is for debug info formats that don't have
> an equivalent of DW_AT_artificial, in which case it downgrades to the
> equivalent of "nodebug".
>
>
> The linked patch doesn't implement the LLVM side of things, so I'm not
> sure when that got added.
>
>
> The patch added the artificial flag on the metadata which was already
> implemented/supported in LLVM (used for things like implicit constructors,
> etc, which don't have user-written code in them) and matches the GCC
> behavior - no extra work was needed on the LLVM side.
>
>
>
>
> On Fri, Jan 28, 2022 at 11:03 AM David Blaikie <dblaikie at gmail.com> wrote:
>
> Hmm, seems I missed this feature (or at least don't remember) when it went
> in.
>
> Looks like the GCC spec might be more accurate to the current
> implementation than what Clang's documentation says:
>
> "artificial
>
> This attribute is useful for small inline wrappers which if possible
> should appear during debugging as a unit, depending on the debug info
> format it will either mean marking the function as artificial or using the
> caller location for all instructions within the inlined body."
>
>
> & the "marking the function as artificial" is the thing that this patch
> implemented in Clang. This did not have the same effect as nodebug, and
> doesn't "use the caller location for all instructions within the inlined
> body".
>
> It's possible we could implement the "artificial" attribute as a an alias
> for "nodebug" which would also be conforming with GCC's spec, but would be
> less expressive than the current implementation (though would save debug
> info size in a way the current Clang implementation does not).
>
> It looks like Clang's implementation is consistent with GCC's
> implementation for DWARF - "marking the function as artificial", not "using
> the caller location for instructions within the inlined body", but Clang's
> documentation is incorrect, since it documents the latter and not the
> former.
>
>
>
> On Fri, Jan 28, 2022 at 9:44 AM Fangqing Du via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Dear all,
>
>
>
> In clang/llvm 7.0, `__attribute__((artificial))` can be identified by
> clang and attach `DIFlagArtificial` into function metadata in this change.
> <https://urldefense.com/v3/__https:/reviews.llvm.org/D43259*change-jbvcnfxttyAz__;Iw!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BoX9IMFWg$>
>
>
>
> And according to the specification
> <https://urldefense.com/v3/__https:/clang.llvm.org/docs/AttributeReference.html*artificial__;Iw!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BrUKhXpvw$>
> of `artificial`, if I understand correctly, when the function (which is
> marked with `artificial` attribute) is inlined, the inlined function
> instructions should be associated with the callsite line number, instead of
> the line of inlined callee.
>
>
>
> But from my observation, with and without this attribute, the inline pass
> behavior is not affected, and inlined instructions debug location still
> point to the callee instead of callsite.
>
> Here is my experiment: godbolt experiment link
> <https://urldefense.com/v3/__https:/godbolt.org/z/oW8Td5d4M__;!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BqqabukgA$>
>
>
>
> Is my understanding correct?
>
> Thanks,
>
> Fangqing
>
> Xilinx Inc.
>
>
>
> == ------------ example -------------===
>
>   1 int bar(int);
>
>   2
>
>   3 inline int __attribute__((artificial)) __attribute__((always_inline))
> foo(int x)
>
>   4 {
>
>   5     return bar(x + 1);
>
>   6 }
>
>   7
>
>   8 void baz(void)
>
>   9 {
>
>  10     auto x = foo(1);
>
>  11     x = foo(2);
>
>  12 }
>
>
>
> When function 'foo' is inlined, the debug location of call instruction
> 'bar' still points to line #5, instead of line #10 and #11.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3Bp86eErug$>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220128/a55eb044/attachment.html>