This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should --enable-bounded be removed?
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