Re: Fix gdb 7.12 C++ compilation on Solaris

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

Hi Pedro,

>> Afterwards, I ran a 32-bit compilation, which (after adding
>> --disable-largefile to avoid
>> 
>> In file included from /usr/include/sys/procfs.h:28:0,
>>                  from /vol/src/gnu/gdb/gdb/local/gdb/i386-sol2-nat.c:23:
>> /usr/include/sys/old_procfs.h:39:2: error: #error "Cannot use procfs in the large file compilation environment"
>>  #error "Cannot use procfs in the large file compilation environment"
>>   ^
>> 
>
> BTW, the gdb/procfs.c file is long overdue for an overall face
> lift...  All the !NEW_PROC_API code should be dead, AFAIK.  Despite
> the comments at the top, the file is no longer used for any
> target other than Solaris:
>
>  $ grep -rn "[^-]procfs\.o" gdb/config/
>  gdb/config/sparc/sol2.mh:5:     procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o
>  gdb/config/i386/sol2-64.mh:3:   procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o
>  gdb/config/i386/i386sol2.mh:3:  procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o
>
> The other Unix ports mentioned are all gone.
>
> But I'm surprised that your Solaris build is including some
> "old_procfs.h" though.  I thought that any non-ancient Solaris
> version would be going through NEW_PROC_API too. 

No wonder: i386-sol2-nat.c unconditionally includes <sys/procfs.h>,
which has this:

/*
 * This definition is temporary.  Structured proc is the preferred API,
 * and the older ioctl-based interface will be removed in a future version
 * of Solaris.  Until then, by default, including <sys/procfs.h> will
 * provide the older ioctl-based /proc definitions.  To get the structured
 * /proc definitions, either include <procfs.h> or define _STRUCTURED_PROC
 * to be 1 before including <sys/procfs.h>.
 */
#ifndef _STRUCTURED_PROC
#define _STRUCTURED_PROC        0
#endif

#if !defined(_KERNEL) && _STRUCTURED_PROC == 0

#include <sys/old_procfs.h>

The Solaris code simply should include <procfs.h> everywhere.

> Doesn't this bit in gdb/configure.ac pick NEW_PROC_API for you
> in 32-bit mode? :
>
> # Detect which type of /proc is in use, such as for Solaris.
>
> if test "${target}" = "${host}"; then
>   case "${host}" in
>   *-*-sysv4.2* | *-*-sysv5* )
>       AC_DEFINE(NEW_PROC_API, 1,
>       [Define if you want to use new multi-fd /proc interface.])
>       ;;
>   *-*-solaris2.[[6789]] | *-*-solaris2.1[[0-9]]*)
>       AC_DEFINE(NEW_PROC_API, 1,
>       [Define if you want to use new multi-fd /proc interface.])
>       ;;
>   mips-sgi-irix5*)
>       # Work around <sys/proc.h> needing _KMEMUSER problem on IRIX 5.
>       AC_DEFINE([_KMEMUSER], 1,
>       [Define to 1 so <sys/proc.h> gets a definition of anon_hdl.  Works
>        around a <sys/proc.h> problem on IRIX 5.])
>       ;;
>   esac
> fi

It did as it should.

> It'd be great to find someone motivated to clean this all up.  :-)
> At least to make sure that the 32-bit and 64-bit compilations
> take the same paths in the backend...

Certainly: I initially encountered this in gcc when boehm-gc still used
the ioctl-based procfs which is finally gone in Solaris 12:

	https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01591.html

Given that the structured one became available with Solaris 2.6 back in
1997, there's no need at all to deal with the old ioctl interface
anywhere.

Besides, given that GCC 4.9 was the last version to support Solaris 9,
one might consider deprecating/removing anything before Solaris 10 in
gdb, too.

I'll see if I can find some spare cycles to clean procfs.c and friends
up: there are tons of opportunities with anything but Solaris gone as
clients of that file and a couple related ones.

> FYI, AFAIK, no GDB maintainer cares for/tests on Solaris
> routinely nowadays.

Neither do I: just whenever a new gdb or binutils release arrives, I
give them a try.  I'm way behind even on Solaris/gcc maintenance, so I
fear there's not much I can do about gdb on that front.  However,
there's a couple of Solaris patches for gdb 7.11 here:

	https://java.net/projects/solaris-userland/sources/gate/show/components/gdb/patches?rev=7127

Perhaps the authors can be motivated to contribute them upstream as they
obviously intended ;-)

>> Still ok for mainline?
>
> Still OK.

Thanks.  I'll commit as soon as I've sorted some problem with hg-git
out: plain git is completely unusable for me.

What about the 7.12 branch backport with the PR now filed?

	Rainer

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