[PATCH] Unify Solaris procfs and largefile handling
Rainer Orth
ro@CeBiTec.Uni-Bielefeld.DE
Tue Jul 28 13:51:19 GMT 2020
Hi Simon,
> On 2020-06-30 11:15 a.m., Rainer Orth wrote:
>> 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
>
> I understood some (not all of this).
>
> Regarding the "old" and "new" procfs interfaces, can't you just always include
> procfs.h and never sys/procfs.h? Using sys/procfs.h seems like it would only
> be useful for pre-1997 Solaris, which doesn't seem useful. And then you could
> have large file support always on?
Unfortunately not: <sys/procfs.h> is sometimes used in code shared with
non-Solaris systems, none of which have <procfs.h>. So we'd have to
conditionalize on HAVE_PROCFS_H vs. HAVE_SYS_PROCFS_H.
And on older Solaris 11.3, even when using the new procfs interface,
<sys/procfs.h> errors out when largefile support is enabled.
As I said: it's a royal mess ;-(
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
More information about the Gdb-patches
mailing list