[PATCH] D146595: [clang] Add clang trampoline_mangled_target attribute

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 27 14:37:23 PDT 2023


aaron.ballman added a comment.

In D146595#4225490 <https://reviews.llvm.org/D146595#4225490>, @aprantl wrote:

>> We don't want to have one attribute per debug format, because that's not going to scale.
>
> LLVM supports outputting a total of 2 debug info formats.

Why should the user have to write two separate attributes that do the same thing?

>> So how do we validate that this attribute should be exposed to users *now* before we know what the story is for other debug formats?
>
> Do you have any other debug info formats in mind? To my knowledge LLVM doesn't support lowering all of the the debug info metadata into PDB because there are some corners where it is less expressive than DWARF.
> I believe that the closest equivalent to this feature in PDB is a feature called "just my code". A web search came up with https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2022 and it seems like it's powered by an external database of function names. Would be interesting to hear from someone with knowledge and an interest in PDB about this.

It's less about other debug formats and more about user experience. My two big concerns are: 1) writing multiple attributes to do the same thing is somewhat user-hostile unless "the same thing" is actually different in some way users will care about, 2) we have a policy that user-facing attributes that do nothing are diagnosed as being ignored, so if we don't support Windows for this attribute, then compiling on that platform is going to generate a pile of "attribute ignored" warnings. If we can support the attribute with PDB as well, that solves both of my big concerns because it makes this attribute generally useful (which is what we aim for with attributes when possible).

> Would you say that we shouldn't create this attribute if it cannot be supported on Windows? Or would documenting that the attribute only has an effect on DWARF platforms be sufficient?

I don't want to sign y'all up for more work you can't easily do yourself, so I don't want to block on support for Windows unless it turns out to be completely trivial to support. But from a review POV, I'd like to hear back from someone who knows something about PDB to validate that the attribute doesn't require a breaking change for support there (like going from taking no args to requiring an arg for some reason, basically). If we don't think breaking changes should be needed, then I think documentation + diagnostics will be sufficient for me.

I did have two questions though:
What happens when stepping into the attributed function through a function pointer?
Are there any special situations where a function cannot/should not be marked with the attribute (virtual functions, lambda, blocks)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146595/new/

https://reviews.llvm.org/D146595



More information about the cfe-commits mailing list