[PATCH] gprofng: a new GNU profiler

[Joseph Myers]

On Thu, 12 Aug 2021, Vladimir Mezentsev via Binutils wrote:

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

Normally we make functionality available on all platforms where it can 
reasonably be expected to work; we don't restrict it to (for example) 
*-linux-gnu instead of the more general *-linux* without a concrete reason 
why it won't work with other libc implementations.  So if this 
functionality depends on hardware and Linux kernel features, but not on 
details of what libc implementation is used on the target or what 
endianness is in use, that would be x86_64-*-linux*, i?86-*-linux* and 
aarch64*-*-linux*.

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

For native-only code, you should be able to rely on the macros predefined 
by the compiler, such as __x86_64__ and __i386__, without needing to 
define your own.  If you do need to define your own, it would be best to 
use names such as NATIVE_I386 that definitely do not conflict with 
anything predefined by a compiler.

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

A single 64-bit GDB binary can debug both 32-bit and 64-bit (and x32) 
inferiors (a 32-bit GDB binary can't debug 64-bit inferiors, however, for 
lack of appropriate kernel interfaces in the 32-bit syscall interface), 
and a single set of binutils binaries (either 32-bit or 64-bit) can 
support assembling / linking both 32-bit and 64-bit code (with appropriate 
options passed to e.g. the assembler to tell it whether to generate 32-bit 
or 64-bit output).  It's clearly preferable to support that if possible.  
Is it practical to support that in gprofng, or does it depend on kernel 
interfaces that aren't available for the case of a 64-bit process 
operating on a 32-bit one, or on loading libraries in the profiled 
process's address space that thus need to be built separately for each 
ABI?

-- 
Joseph S. Myers
joseph@codesourcery.com