From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81752 invoked by alias); 17 Dec 2018 21:41:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 81731 invoked by uid 89); 17 Dec 2018 21:41:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Hx-languages-length:2379 X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Dec 2018 21:41:28 +0000 Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9318310A87D; Mon, 17 Dec 2018 16:41:26 -0500 (EST) Subject: Re: [PATCH] Please define thread_info as struct thread_info (and other stuff) To: svante.signell@gmail.com, Tom Tromey Cc: Andreas Schwab , Simon Marchi , gdb-patches@sourceware.org References: <000db1d81a0c415190b6648222ed29db7f927df9.camel@gmail.com> <87d0q13w6b.fsf@tromey.com> From: John Baldwin Openpgp: preference=signencrypt Message-ID: <430466fb-3706-da11-39dc-28c0b342041c@FreeBSD.org> Date: Mon, 17 Dec 2018 21:41:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00202.txt.bz2 On 12/17/18 12:51 PM, Svante Signell wrote: > On Sun, 2018-12-16 at 16:10 -0700, Tom Tromey wrote: >>>>>>> "Svante" == Svante Signell writes: >> Svante> Another issue is to compile C-code (and C++-code) in *.c files. >> Svante> Please rename these to *.cpp (and eventually the header files to >> *.hpp)! As it is now it is very confusing. >> >> I think this was discussed When we made this switch, and the conclusion >> was that a mass rename would be worse. > > Do you really need to compile all files with a C++ compiler? Pure C-code could > still be compiled with a C compiler. GDB isn't written in C anymore. target_ops is a class with virtual methods, the use of gdb::unique_ptr<> (basically std::unique_ptr<>) is rather ubiquitous now, etc. In fact, I think we even require C++11 and not just C++03. >> Svante> Finally, I've found the problem (but no workaround yet): thread_info >> is an RPC on GNU/Hurd, and including mach.h in gdb/config/i386/nm- >> i386gnu.h:#include further includes which has >> the conflicting name Svante> of that RPC: kern_return_t thread_info >> >> Typical answers for this kind of thing are either to segregate the use >> of the system header somehow, or maybe namespacing or some other kind of >> renaming. I haven't looked into the details much in this case I'm >> afraid. > > As I see it you need to: > > 1) Apply the patches submitted earlier in this thread using struct thread_info > consistently everywhere (simplest). > 2) Rename all usage of the struct thread_info to something else e.g. struct > gdb_thread_info (not future-proof though). > 3) Create a gdb namespace for all your code to avoid conflicts. > 4) Segregate the use of system header files as you write above. Dunno how to do > that though, but some of you should. Normally code for native targets do 4). I've had to be careful about which includes I use in native FreeBSD targets to avoid namespace collisions, etc. 3) might not be a terrible idea eventually, but you'd have to make it explict and avoid using 'using namespace gdb' for it to actually be useful. -- John Baldwin                                                                            Â