Re: Fix gdb 7.12 C++ compilation on Solaris

[Pedro Alves <palves@redhat.com>]

On 10/18/2016 02:14 PM, Rainer Orth wrote:

>> Yes, with the tweak above on master.  But, the process for getting
> 
> Thanks.  When investigating the failure to detect -static-libstdc++
> support (more below), I found two more issues which only show up with
> -Werror:
> 
> /vol/src/gnu/gdb/gdb/local/gdb/procfs.c: In function 'ssd* proc_get_LDT_entry(procinfo*, int)':
> /vol/src/gnu/gdb/gdb/local/gdb/procfs.c:2487:19: error: variable 'old_chain' set but not used [-Werror=unused-but-set-variable]
>    struct cleanup *old_chain = NULL;
>                    ^
> 
> Unless I'm mistaken, you need to run do_cleanups on every return from
> the function.

You're right.  

> 
> 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. 

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'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...

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

> and two more instances) revealed
> 
> /vol/src/gnu/gdb/gdb/local/gdb/top.c: In function 'void gdb_safe_append_history()':
> /vol/src/gnu/gdb/gdb/local/gdb/top.c:1170:59: error: format '%d' expects argument of type 'int', but argument 3 has type 'pid_t {aka long int}' [-Werror=format=]
>      = xstrprintf ("%s-gdb%d~", history_filename, getpid ());
>                                                            ^
> 
> Fixed by casting pid_t to long and printing it as such.
> 
> Still ok for mainline?

Still OK.

Thanks,
Pedro Alves