r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

The change itself is correct, but perhaps it deserves a test?

g(r)crt1.o enabled by -pg is a startup code for the c runtime. Is it right to call it the crt?

Is this also correct for musl and other targets that use a gnu toolchain?

Good question.
This flag is supported by GCC and Clang, so any target that uses them should accept it. If GCC/Clang does a wrong thing for a specific target, this is arguably not our fault, yet we still might want to add workarounds.

g(r)crt1.o enabled by -pg is a startup code for the c runtime. Is it right to call it the crt?

That's maybe a detail about the glibc specific implementation which can be redacted? non-gnu targets seem to have a little more varied behavior.

Is this also correct for musl and other targets that use a gnu toolchain?

musl, no. Linking should fail with unresolved mcount-ish symbols. Looking around at Clang, it does seem a few other platforms should respect this option. @mati865, I think you're right. If the target lacks support for this option, it will likely fail similar to musl. Removing the gnu check is likely helpful for other targets.

Just to double check we don't regress here.
Musl (and likely other libc like uclibc) failed to before and still do after this PR, albeit with different errors, right?

FreeBSD seems to support it: https://man.freebsd.org/cgi/man.cgi?query=moncontrol&sektion=3&apropos=0&manpath=freebsd

Even mingw-w64 provides the necessary objects.

Just to double check we don't regress here.
Musl (and likely other libc like uclibc) failed to before and still do after this PR, albeit with different errors, right?

I verified musl will fail to compile in the same way with and without -pg. It fails to link due to the missing mcount symbol. I think uclibc will fail similarly, it appears to lack an mcount implementation too.

ping