From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17415 invoked by alias); 20 Jan 2016 23:33:29 -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 17401 invoked by uid 89); 20 Jan 2016 23:33:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=hacked, HX-Greylist:AUTH, HX-Greylist:succeeded, HX-Greylist:SMTP X-HELO: bigwig.baldwin.cx Received: from bigwig.baldwin.cx (HELO bigwig.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 20 Jan 2016 23:33:27 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 043A6B94B; Wed, 20 Jan 2016 18:33:25 -0500 (EST) From: John Baldwin To: gdb@sourceware.org Cc: Pedro Alves Subject: Re: C++ conversion status update Date: Wed, 20 Jan 2016 23:33:00 -0000 Message-ID: <3244238.TJBgqNL2lm@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <569F6B1D.60406@redhat.com> References: <565460FB.6070103@redhat.com> <290689073.6kaHW0HruR@ralph.baldwin.cx> <569F6B1D.60406@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00044.txt.bz2 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