glibc code coverage

  I am a new contributor. I have applied for copyright papers and signed them.

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

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.
  

On Thu, 3 Dec 2020, 12:15 am Joseph Myers, <joseph@codesourcery.com> wrote:

> 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


Hi,

Thank you for your feedback. I'm still working on improvements to the
patch. Progress is slow because I'm a beginner, but I'm still at it! In the
feedback you said:

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.

I actually gave a presentation at the recently concluded ELISA Workshop #6
where I discussed the patch, among other things. One of the attendees
suggested that I link it here, so I am doing that. Here's the Google drive
link:

https://drive.google.com/file/d/1eW3rz5vvvCTeCoLKZh72P1wPL3RYSYDp/view

I'm not sure about the other questions, but this should provide some
insight as to why this patch would be needed (atleast for a specific subset
of developers).

Once again, thank you for your time.

Regards,
Ashutosh