https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70787
--- Comment #2 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- The Go runtime seems to register a handler for SIGPROF even if it does not want to profile. So it always uninstalls the handler installed by Glibc on behalf of the -pg option. To me it looks like -pg actually enables the profiling from libgo instead. Some ways to circumvent this: 1) Don't install a SIGPROF handler in the Go runtime if another is already installed (possibly emit a warning or a fatal error if the program attempts to enable the Go profiling). => Simple to implement. 2) Install the SIGPROF handler on the fly when it's needed instead of unconditionally at Go runtime startup. Possibly emit a warning if an existing signal handler is uninstalled in the process. => Cleanest solution. 3) Store the previous signal handler and call it at the start of the Go runtime signal handler. However, this introduces a number several problems (the Go runtime won't notice if the original profiling code wants to uninstall the handler or install a new one or it might overwrite the Go runtime handler; also, the two profiling systems will probably not agree on a common timing interval). => May allow to run Glibc and libgo profiling in parallel but probably has some unfixable issues.
