[PATCH] gprofng: a new GNU profiler

[Joseph Myers]

On Wed, 11 Aug 2021, Vladimir Mezentsev wrote:

> gprofng can be built for the  x86_64, i686 or aarch64 platforms.
> For the other platforms, the gprofng build is turned off.

Could you point to the relevant parts of the patches that implement this 
turning off?  Is it the case statement on ${target} in 
gprofng/configure.ac?

What happens if building for e.g. --host=powerpc64le-linux-gnu 
--target=aarch64-linux-gnu?  Does that produce a gprofng binary that can 
process data collected on AArch64, while not supporting native collection?

I'm concerned about the definitions such as -D__i386 that you're using 
based on the target, because there might be host headers using such 
defines to test whether the *host* is i386.  I think you need to avoid any 
defines of such macros for target properties that might be confused with 
macros for host properties defined by host compilers (and correspondingly 
adjust any #ifdef in the gprofng code so it uses e.g. TARGET_I386 
conditionals that cannot be confused with conditionals for the host 
architecture).

The target patterns you have in gprofng/configure.ac seem rather 
restrictive.  Does it really need to be restricted to *-linux-gnu or would 
e.g. -linux-uclibc and -linux-musl work just as well if the target used 
*-linux*?  Does it need to be restricted to i686 not i?86 covering e.g. 
i486 or i586 targets as well?  Does it need to be restricted to aarch64 
(i.e. tools defaulting to little-endian) rather than allowing aarch64* (so 
including aarch64_be as well)?

For x86_64/i686, binutils supports both 32-bit and 64-bit code generation 
(by default for x86_64; for i686 if --enable-64-bit-bfd).  Can gprofng 
support that, i.e. x86_64, or i686 --enable-64-bit-bfd, gprofng support 
processing data collected on the relevant architecture, and support native 
collection for both 32-bit and 64-bit binaries if built as native?

I don't think the tests for specific paths in /usr, e.g. /usr/bin/javac, 
are a good idea.  If testing for a tool such as Java, you should look for 
it in the PATH rather than making assumptions that a version in a specific 
directory such as /usr is the right one to use.

-- 
Joseph S. Myers
joseph@codesourcery.com