Should --enable-bounded be removed?

[Joseph S. Myers]

On Tue, 3 Jan 2012, Roland McGrath wrote:

> > Doing "./conigure --enable-bounded ..." causes Makeconfig to try to use
> > -fbounded-pointers, which has been removed from GCC in 2002.
> > 
> > Should this optoion be cleaned up from GLIBC sources?
> 
> Yes.  If there is nothing else like it that can work (mudflap?) then we
> should not only remove the configury, but remove all the associated macros
> and their uses scattered across many assembly sources.

Agreed.  This was for a particular fat-pointers bounded-pointers 
implementation, which was quite different from other pointer-checking 
approaches, and I don't think BP_SYM, CHECK_BOUNDS_* etc. are useful any 
more (they are too bitrotten for it to be sensible to keep them in case of 
a revival, that's what the version control history is for).  Other things 
on my list of glibc configuration features I think are dead and could do 
with being removed:

* Conditionals for non-ELF object formats (note I recently removed the 
dead AIX support from ports, there's no need for the --with-xcoff 
configure option or aix* case in configure.in now).

* --enable-omitfp (GCC enables -fomit-frame-pointer by default at 
appropriate -O levels nowadays when appropriate for the target and with 
DWARF debug info it does not cause problems with debugging).

* Some relics of support for pre-C90 compilers such as use of __const 
instead of plain const in some headers.

* Support for Linux kernel versions prior to 2.6.0 final, in 
arch_minimum_kernel settings, kernel-features.h and places testing (in 
code only used with Linux) __ASSUME_* macros for features added (for all 
architectures) by 2.6.0.  NPTL means that glibc effectively requires 2.6 
and has done so for years (though some distributions may have backported 
support to 2.4 kernels, I don't think those should be considered relevant 
to future glibc releases).

* There's a case in configure.in that includes a whole series of 
architectures with no current glibc support:

a29k | am29000) base_machine=a29k machine=a29k ;;
c3[012])        base_machine=cx0 machine=cx0/c30 ;;
c4[04])         base_machine=cx0 machine=cx0/c40 ;;
m88???)         base_machine=m88k machine=m88k/$machine ;;
m88k)           base_machine=m88k machine=m88k/m88100 ;;

and another similarly irrelevant bit of code:

# Make sco3.2v4 become sco3.2.4 and sunos4.1.1_U1 become sunos4.1.1.U1.
os="`echo $os | sed 's/\([0-9A-Z]\)[v_]\([0-9A-Z]\)/\1.\2/g'`"

and then most of the case over $os except for the gnu* and linux* cases, 
and quite a bit of what follows.

(Ideally I think architecture cases should generally be avoided in 
architecture-independent configure scripts; that is, the non-obsolete 
architecture cases for libc architectures would move to subdirectory 
scripts in a similar way to that used for ports.  And I'd apply the same 
to kernel-features.h: again, I think the separation into 
architecture-specific files used for ports would be a better approach for 
libc as well.)

-- 
Joseph S. Myers
joseph@codesourcery.com