Symbols in optimized async programs are often not useful #65978
(As observed on
I'm making my first aggressive use of
This is complicated by the fact that basically all of my functions are named
For example, here is my function called
(The observant reader will note
I understand why this is happening:
(For what it's worth, I can change the situation by forcing
I am compiling at
The text was updated successfully, but these errors were encountered:
I think debuginfo should already include line-by-line information of code that was inlined. But when looking at objdump or a backtrace, it might not show up. We have to pick one function name which is going to be shown for every stack frame (or symbol).
In this case, there's one monomorphization per call site. Maybe we can add an attribute to
Ah, that's right. (I was confused by the fact that
In that case it's less clear to me how to solve this.
From the outside, it would look like a caller got inlined into its callee, rather than the other way around.
We could make some annotation that says "when a bunch of functions are inlined into a symbol, don't use the symbol name of this function," and the compiler can pick the name of the first inlined function which doesn't contain this annotation, if any.
Another way is to gather all the functions inlined into one and pick the "most specific function name," i.e. the function that is a candidate for inlining the least number of times. This might work, but it might also have odd unpredictable effects.
I'm not sure how easy these would be to implement.
I think this is partially fixed by the new symbol mangling scheme (
Hi! I've updated the codebase to a post-resume-arguments toolchain, and I can confirm that the symbols got replaced by something equally generic. :-)
Now most functions in my program are named
Here's a snippet from the
...and so forth.
In my ideal world, each of these functions would be named something that links them back to the