Re: C++ conversion status update

Pedro Alves
2016-04-16T00:21:23Z

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