Joseph Myers 8df5d34720 Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.

For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing.  For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.

We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.

This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler.  Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.

The config.make with-fp variable remains.  It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables.  For powerpc, -mcpu= options can imply use of
soft-float.  That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory.  If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).

Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.

	* configure.ac (--with-fp): Remove configure option.
	(with_fp_cond): New variable.
	(libc_cv_with_fp): New configure test.  Use this variable instead
	of with_fp.
	* configure: Regenerated.
	* config.make.in (with-fp): Use @libc_cv_with_fp@.
	* manual/install.texi (Configuring and compiling): Remove
	--without-fp.
	* INSTALL: Regenerated.
	* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
	* sysdeps/mips/preconfigure (with_fp_cond): Define.
	* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
	* sysdeps/sh/preconfigure (with_fp_cond): Define.
	* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
	use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
..
2017-09-22 17:43:42 +00:00
dir
..
2005-11-21 15:45:19 +00:00
2017-12-12 13:56:47 +00:00
2014-04-08 17:12:15 -04:00
2017-10-05 15:58:13 +00:00
2014-01-31 23:23:59 -02:00
2017-12-12 03:21:53 -08:00
2017-10-05 15:58:13 +00:00
2017-10-05 15:58:13 +00:00
2017-12-07 00:48:31 +00:00

			TUNABLE FRAMEWORK
			=================

Tunables is a feature in the GNU C Library that allows application authors and
distribution maintainers to alter the runtime library behaviour to match their
workload.

The tunable framework allows modules within glibc to register variables that
may be tweaked through an environment variable.  It aims to enforce a strict
namespace rule to bring consistency to naming of these tunable environment
variables across the project.  This document is a guide for glibc developers to
add tunables to the framework.

ADDING A NEW TUNABLE
--------------------

The TOP_NAMESPACE macro is defined by default as 'glibc'.  If distributions
intend to add their own tunables, they should do so in a different top
namespace by overriding the TOP_NAMESPACE macro for that tunable.  Downstream
implementations are discouraged from using the 'glibc' top namespace for
tunables they don't already have consensus to push upstream.

There are three steps to adding a tunable:

1. Add a tunable to the list and fully specify its properties:

For each tunable you want to add, make an entry in elf/dl-tunables.list.  The
format of the file is as follows:

TOP_NAMESPACE {
  NAMESPACE1 {
    TUNABLE1 {
      # tunable attributes, one per line
    }
    # A tunable with default attributes, i.e. string variable.
    TUNABLE2
    TUNABLE3 {
      # its attributes
    }
  }
  NAMESPACE2 {
    ...
  }
}

The list of allowed attributes are:

- type:			Data type.  Defaults to STRING.  Allowed types are:
			INT_32, UINT_64, SIZE_T and STRING.  Numeric types may
			be in octal or hexadecimal format too.

- minval:		Optional minimum acceptable value.  For a string type
			this is the minimum length of the value.

- maxval:		Optional maximum acceptable value.  For a string type
			this is the maximum length of the value.

- default:		Specify an optional default value for the tunable.

- env_alias:		An alias environment variable

- security_level:	Specify security level of the tunable.  Valid values:

			SXID_ERASE: (default) Don't read for AT_SECURE binaries and
				    removed so that child processes can't read it.
			SXID_IGNORE: Don't read for AT_SECURE binaries, but retained for
				     non-AT_SECURE subprocesses.
			NONE: Read all the time.

2. Use TUNABLE_GET/TUNABLE_SET to get and set tunables.

3. OPTIONAL: If tunables in a namespace are being used multiple times within a
   specific module, set the TUNABLE_NAMESPACE macro to reduce the amount of
   typing.

GETTING AND SETTING TUNABLES
----------------------------

When the TUNABLE_NAMESPACE macro is defined, one may get tunables in that
module using the TUNABLE_GET macro as follows:

  val = TUNABLE_GET (check, int32_t, TUNABLE_CALLBACK (check_callback))

where 'check' is the tunable name, 'int32_t' is the C type of the tunable and
'check_callback' is the function to call if the tunable got initialized to a
non-default value.  The macro returns the value as type 'int32_t'.

The callback function should be defined as follows:

  void
  TUNABLE_CALLBACK (check_callback) (int32_t *valp)
  {
  ...
  }

where it can expect the tunable value to be passed in VALP.

Tunables in the module can be updated using:

  TUNABLE_SET (check, int32_t, val)

where 'check' is the tunable name, 'int32_t' is the C type of the tunable and
'val' is a value of same type.

To get and set tunables in a different namespace from that module, use the full
form of the macros as follows:

  val = TUNABLE_GET_FULL (glibc, tune, hwcap_mask, uint64_t, NULL)

  TUNABLE_SET_FULL (glibc, tune, hwcap_mask, uint64_t, val)

where 'glibc' is the top namespace, 'tune' is the tunable namespace and the
remaining arguments are the same as the short form macros.

When TUNABLE_NAMESPACE is not defined in a module, TUNABLE_GET is equivalent to
TUNABLE_GET_FULL, so you will need to provide full namespace information for
both macros.  Likewise for TUNABLE_SET and TUNABLE_SET_FULL.

** IMPORTANT NOTE **

The tunable list is set as read-only after the dynamic linker relocates itself,
so setting tunable values must be limited only to tunables within the dynamic
linker, that too before relocation.

FUTURE WORK
-----------

The framework currently only allows a one-time initialization of variables
through environment variables and in some cases, modification of variables via
an API call.  A future goals for this project include:

- Setting system-wide and user-wide defaults for tunables through some
  mechanism like a configuration file.

- Allow tweaking of some tunables at runtime