From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14776 invoked by alias); 16 Apr 2016 00:21:23 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 14759 invoked by uid 89); 16 Apr 2016 00:21:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=mentions, determination, baldwin X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 16 Apr 2016 00:21:20 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 665934DB14; Sat, 16 Apr 2016 00:21:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3G0LH9v012487; Fri, 15 Apr 2016 20:21:18 -0400 Subject: Re: C++ conversion status update To: John Baldwin , gdb@sourceware.org References: <565460FB.6070103@redhat.com> <290689073.6kaHW0HruR@ralph.baldwin.cx> <569F6B1D.60406@redhat.com> <3244238.TJBgqNL2lm@ralph.baldwin.cx> From: Pedro Alves Message-ID: <5711857D.8030708@redhat.com> Date: Sat, 16 Apr 2016 00:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <3244238.TJBgqNL2lm@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00025.txt.bz2 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