Re: Fix gdb 7.12 C++ compilation on Solaris

Pedro Alves
2016-10-18T14:28:30Z

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