Re: C++ conversion status update

[John Baldwin <jhb at freebsd dot org>]

On Wednesday, January 20, 2016 11:10:21 AM Pedro Alves wrote:
> Indeed, thanks for noticing this.  I've sent a patch now:
>   https://sourceware.org/ml/gdb-patches/2016-01/msg00469.html
> 
> I've also pushed it to:
>   git@github.com:palves/gdb.git palves/cxx-conversion-attempt-part-2-no-fpermissive
> 
> (note there are a few more wip/pending C++ patches on that branch)
> 
> Could you give it a try?

Yes, that works well.

I see that you also have a patch (41bed896a) in that branch to fix ptrace()
args detection (which also broke for me, though I just hacked config.h locally
so I could work on the actual problems).

Unfortunately, your patch doesn't fix FreeBSD/amd64 with GCC 4.8 (at least).
The detection of the ptrace return type ('int' on FreeBSD) fails and falls
back to long and I think that prevents it from subsequently matching on the
correct types for the argument list.

The error for the failing test for the return type (which should work instead
I think) is:

configure:12453: /usr/local/bin/g++48 -c -pipe -DRL_NO_COMPAT -Wno-unused-function -Wno-unused-variable  -g -DLIBICONV_PLUG -g -fno-strict-aliasing  -DLIBICONV_PLUG  conftest.cpp >&5
conftest.cpp:166:22: error: declaration of C function 'int ptrace()' conflicts with
 EXTERN_C int ptrace ();
                      ^
In file included from conftest.cpp:154:0:
/usr/include/sys/ptrace.h:185:5: error: previous declaration 'int ptrace(int, pid_t, caddr_t, int)' here
 int ptrace(int _request, pid_t _pid, caddr_t _addr, int _data);
     ^
configure:12453: $? = 1
configure: failed program was:
....
| EXTERN_C int ptrace ();
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:12462: result: long
configure:12470: checking types of arguments for ptrace

I think the problem is that whereas in C "int foo()" means the args to foo()
are undefined, "int foo()" in C++ is equivalent to "int foo(void)".

I know that a comment in ptrace.ac4 mentions that C++ needs to be used to
determine if the first argument to ptrace is an enum that needs a cast,
but I wonder if we couldn't fall back to plain C for the return type
check?  (I'm not sure which of the tests in ptrace.ac4 needs C++ to make
the enum determination such that we could possibly shuffle things around
to do the one test needed while in C++ mode and the rest in C?)

Another possibility would be to move the return type check into the big
loop that currently checks the arguments as an outermost loop, something
like:

for gdb_ret in 'int' 'long'; do
  for gdb_arg1 in 'int' 'long'; do
    ...

This would work in C++ mode I think.

-- 
John Baldwin