On Fri, May 21, 2021 at 05:29:30PM -0700, Jason Thorpe wrote: > This looks awesome, David, thanks for writing it!
:-) > Might it be worth noting some of the historical legacy symbol > naming issues that were are the root of the bug report we were just > talking about a little while ago? After investigation I don't think that's actually true: the name in MCOUNT_DECL is a C name, so in a.out days if given as "mcount" would have come out as "_mcount" and still be in the user namespace. The name of the assembly function is not necessarily, but that's _mcount on alpha. Now, anyway; was probably different originally as having the same obviously would never have worked. (context for passersby: PR 10582) To cut down on future confusion we should probably (if it's not excessively expensive for some reason) change all the compiler configs to call "__mcount_hook" and change the name of the C function to always be "__mcount_impl" or "__mcount_backend" or something like that. Having both _mcount and __mcount is terrible, especially when their roles are exchanged on ~half the ports we have. (Since profiling binaries are static and these functions aren't user-facing there's no compatibility issues with changing them.) -- David A. Holland dholl...@netbsd.org
