[PATCH] Unify Solaris procfs and largefile handling

[Rainer Orth]

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> Could someone please review the GDB side of this patch?  It's more than
>> a week now.
>>
>> Nick already approved the binutils part, but it needs to go in as a
>> whole.  binutils 2.35 has branched already and I suspect he will be
>> increasingly wary to allow it into the branch the closer the release
>> date gets.
>
> 11 days gone since the last reminder...
>
> Could someone please review the gdb parts of this patch?  As I'd
> mentioned, the binutils side of things has already been approved, but
> parts of config/largefile.m4 primarily affect gdb, so a second pair of
> eyes there would be helpful.

Another 8 days since the last reminder.  This patch is necessary to
unbreak the 32-bit Solaris builds.

Thanks.
	Rainer


>>> GDB currently doesn't build on 32-bit Solaris:
>>>
>>> * On Solaris 11.4/x86:
>>>
>>> In file included from /usr/include/sys/procfs.h:26,
>>>                  from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24:
>>> /usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment"
>>>  #error "Cannot use procfs in the large file compilation environment"
>>>   ^~~~~
>>>
>>> * On Solaris 11.3/x86 there are several more instances of this.
>>>
>>> The interaction between procfs and large-file support historically has
>>> been a royal mess on Solaris:
>>>
>>> * There are two versions of the procfs interface:
>>>
>>> ** The old ioctl-based /proc, deprecated and not used any longer in
>>>    either gdb or binutils.
>>>
>>> ** The `new' (introduced in Solaris 2.6, 1997) structured /proc.
>>>
>>> * There are two headers one can possibly include:
>>>
>>> ** <procfs.h> which only provides the structured /proc, definining
>>>    _STRUCTURED_PROC=1 and then including ...
>>>
>>> ** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based
>>>    /proc, but provides structured /proc if _STRUCTURED_PROC == 1.
>>>
>>> * procfs and the large-file environment didn't go well together:
>>>
>>> ** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit
>>>    compilations when the large-file environment was active
>>>    (_FILE_OFFSET_BITS == 64).
>>>
>>> ** In both Solaris 11.4 and Illumos, this restriction was lifted for
>>>    structured /proc.
>>>
>>> So one has to be careful always to define _STRUCTURED_PROC=1 when
>>> testing for or using <sys/procfs.h> on Solaris.  As the errors above
>>> show, this isn't always the case in binutils-gdb right now.
>>>
>>> Also one may need to disable large-file support for 32-bit compilations
>>> on Solaris.  config/largefile.m4 meant to do this by wrapping the
>>> AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding
>>> ACX_LARGEFILE.  Unfortunately the macro doesn't always succeed because
>>> it neglects the _STRUCTURED_PROC part.
>>>
>>> To make things even worse, since GCC 9 g++ predefines
>>> _FILE_OFFSET_BITS=64 on Solaris.  So even if largefile.m4 deciced not to
>>> enable large-file support, this has no effect, breaking the gdb build.
>>>
>>> This patch addresses all this as follows:
>>>
>>> * All tests for the <sys/procfs.h> header are made with
>>>   _STRUCTURED_PROC=1, the definition going into the various config.h
>>>   files instead of having to make them (and sometimes failing) in the
>>>   affected sources.
>>>
>>> * To cope with the g++ predefine of _FILE_OFFSET_BITS=64,
>>>   -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables.  It had
>>>   been far easier to have just
>>>
>>>   #undef _FILE_OFFSET_BITS
>>>
>>>   in config.h, but unfortunately such a construct in config.in is
>>>   commented by config.status irrespective of indentation and whitespace
>>>   if large-file support is disabled.  I found no way around this and
>>>   putting the #undef in several global headers for bfd, binutils, ld,
>>>   and gdb seemed way more invasive.
>>>
>>> * Last, the applicability check in largefile.m4 was modified only to
>>>   disable largefile support if really needed.  To do so, it checks if
>>>   <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined.  If it
>>>   doesn't, the disabling only happens if gdb exists in-tree and isn't
>>>   disabled, otherwise (building binutils from a tarball), there's no
>>>   conflict.
>>>
>>>   What initially confused me was the check for $plugins here, which
>>>   originally caused the disabling not to take place.  Since AC_PLUGINGS
>>>   does enable plugin support if <dlfcn.h> exists (which it does on
>>>   Solaris), the disabling never happened.
>>>
>>>   I could find no explanation why the linker plugin needs large-file
>>>   support but thought it would be enough if gld and GCC's lto-plugin
>>>   agreed on the _FILE_OFFSET_BITS value.  Unfortunately, that's not
>>>   enough: lto-plugin uses the simple-object interface from libiberty,
>>>   which includes off_t arguments.  So to fully disable large-file
>>>   support would mean also disabling it in libiberty and its users: gcc
>>>   and libstdc++-v3.  This seems highly undesirable, so I decided to
>>>   disable the linker plugin instead if large-file support won't work.
>>>
>>> The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both
>>> Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to
>>> predefined _FILE_OFFSET_BITS=64).  Also regtested on
>>> amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4),
>>> x86_64-pc-linux-gnu and i686-pc-linux-gnu.
>>>
>>> Ok for master?  While it would be nice to have this in the binutils 2.35
>>> and gdb 10 releases, I'd fully understand if the patch were considered
>>> too risky so close to the branch dates.
>>>
>>> 	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University