[PATCH] glibc code coverage

[Joseph Myers]

On Wed, 2 Dec 2020, Ashutosh Pandey via Libc-alpha wrote:

> Enable building glibc with instrumentation for code coverage. For
> +    individual files '--coverage' can be used, but this fails
> +    when it is used as an option with '../configure' command to build
> glibc.
> +    To successfully build glibc with coverage, you must first build and
> install glibc
> +    with shared libraries enabled. This will allow some files such as
> +    'libc-modules.h' to be generated which are needed for code coverage to
> +    work.
> +    The command '../configure --disable-shared --enable-gcov
> --without-selinux
> +    --disable-nscd --prefix=/path/to/install'
> +    will build glibc with code coverage. Note that not including a prefix,
> +    or setting the prefix to usr/lib can affect the system glibc and can
> +    render the system unusable. The command to make is 'make CXX=', without
> +    which you will get a error 'cannot find -lgcc_s'.

Much of this reads more like a list of caveats about a work-in-progress 
patch, than a description of a configure option that is ready for 
inclusion in glibc.  I'd expect such issues to be fixed, so that the new 
option can be used by itself, before it should go in glibc.  If there is 
some reason it's inherently hard to fix those issues, the proposed commit 
message should explain *why* those issues arise and are hard to fix.

I know glibc has historically been hard to build and had many pitfalls in 
building it, but we should do better than that, which includes making new 
build-time features more robust.  (If something about the build 
environment doesn't work for a feature, a clear error message at configure 
time is much better than an obscure error part way through the build - 
whether or not that error part way through the build is mentioned in the 
installation manual.)

glibc should be configured using --prefix=/usr; a non-default glibc should 
be installed in a different sysroot, not configured with a different 
prefix.  (usr/lib isn't a prefix, it's a directory relative to a sysroot.)

Could you explain the design decisions made in more detail?  This patch 
looks like the configure option changes how the existing libraries are 
built.  Why is it doing things that way rather than something like 
--enable-profile: an option that enables an additional set of libraries 
built with coverage options, alongside the normal shared and static 
libraries?  Something like --enable-profile, that can be used with any 
other glibc configure options rather than needing a series of other 
options, including poorly-tested ones such as --disable-shared, could be 
more convenient for users - even if in practice it's more of an option for 
glibc developers than one where distributions would be expected to 
provided packages of the coverage-enabled libraries.

I suppose there's the question of whether coverage-enabled shared 
libraries make sense - if they do, it's harder to have them share a 
sysroot with normal shared libraries than it is to have a separate set of 
coverage-enabled static libraries.  So supporting coverage-enabled shared 
libraries would be one reason to have the configure option work as it does 
in this patch.

The documentation of the configure option in install.texi will need to 
make clear which choice is made (separate libraries versus changing how 
static / shared libraries are built).  Note that install.texi, saying what 
the option does, is separate from the commit message, which should discuss 
more about the rationale and design choices - separate text will be needed 
for each place.  A short NEWS entry will also be needed for a new 
configure option.  At least one build with the new option should be added 
to build-many-glibcs.py and verified to work there.

Note that configure should be regenerated with *unmodified* upstream 
autoconf, not with a version with distribution patches that introduce 
changes (--runstatedir) unrelated to the subject of the patch.

-- 
Joseph S. Myers
joseph@codesourcery.com