[PATCH] gprofng: a new GNU profiler

[Vladimir Mezentsev]

On 8/12/21 5:49 AM, Joseph Myers wrote:
> 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?

  yes. It is 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?
gprofng has two parts:
    1. to collect data. It is libraries: libgp-collector.so, 
libgp-heap.so, ...
    2. to display data.

(2) is independent on machines. It is implemented in c++.
  It was built and tested with gcc8 and gcc11 on X86_64 and aarch64 
(Linux ol8)

(1) is implemented in c. The code is native-only. It should be built and 
used when host == target.
(1) was built and tested on X86_64 and aarch64.
On X86_64,  we build  32-bit and 64-bit libraries to profile the 32-bit 
and 64-bit applications.

>
> 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).
   Agree.
  I will see how the other parts of binutils deal with this and fix gprofng.


>
> 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?

Only these three targets were built and tested:
     x86_64-*-linux-gnu
     i686-*-linux-gnu
     aarch64-*-linux-gnu

The other configurations were not available to me.


>    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)?

We need to know where we build.
We use -D__amd64, -D__i386, -D__aarch64 for it.

I agree  that we should not use these defines to determine the byte order.
Moreover,  we should not use these defines.
I will fix it.


> 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?

For x86_64, I build twice. One is  for 64-bit gprofng. The other is for 
32-bit libraries only:
1. --prefix=INSTALL_DIR --enable-shared
2. --prefix=INSTALL_DIR --enable-shared CFLAGS=-m32 CXXFLAGS=-m32  
CCFLAGS=-m32 --target=i686-pc-linux-gnu --libdir=INSTAL_DIR/lib32

Is it correct ?
How do you build binutils-gdb for x86_64/i686?

>
> I don't think the tests for specific paths in /usr, e.g. /usr/bin/javac,
> are a good idea.

Agree. Not good idea. I will fix it too.

>   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.

   We don't really need java or javac.
We need jni.h for build to support java profiling.



Joseph, thank you for review.

-Vladimir