Re: C++ conversion status update

Hi John,

Finally managed to get back to the ptrace prototype detection issue.

On 01/20/2016 11:33 PM, John Baldwin wrote:

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

Yes, agreed.  I've sent a patch that does that to the
list now:

 https://sourceware.org/ml/gdb-patches/2016-04/msg00374.html

If you could give it a try it'd be much appreciated.  I've pushed
it to the users/palves/ptrace-detection branch (at sourceware.org)
as well, for convenience.

Thanks,
Pedro Alves