From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39823 invoked by alias); 20 Dec 2018 23:26:07 -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 39812 invoked by uid 89); 20 Dec 2018 23:26:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,KAM_SHORT,LIKELY_SPAM_BODY,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=shot, daily X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Dec 2018 23:26:05 +0000 Received: by simark.ca (Postfix, from userid 112) id 17B951E7AF; Thu, 20 Dec 2018 18:26:04 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 0B5A31E059; Thu, 20 Dec 2018 18:25:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Dec 2018 23:26:00 -0000 From: Simon Marchi To: Tom Tromey Cc: Svante Signell , Andreas Schwab , gdb-patches@sourceware.org, Pedro Alves Subject: Re: [PATCH] Please define thread_info as struct thread_info (and other stuff) In-Reply-To: <878t0j4ykk.fsf@tromey.com> References: <000db1d81a0c415190b6648222ed29db7f927df9.camel@gmail.com> <87d0q13w6b.fsf@tromey.com> <878t0j4ykk.fsf@tromey.com> Message-ID: <69b7d5f5ddfd13b33f62ff58e643af40@simark.ca> X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.6 X-SW-Source: 2018-12/txt/msg00243.txt.bz2 On 2018-12-20 17:34, Tom Tromey wrote: >>>>>> "Svante" == Svante Signell writes: > > Svante> Seems like nothing is happening so far. Did you expect me to > Svante> take action on this issue? Or is this a low-prio problem for > Svante> you, Hurd being a second class citizen? > > It's not so much second-class as that the usual way gdb development > works is that ports need maintainers, and the current contributors are > pretty busy and/or have other interests. That's an important point. For example, the Freebsd port is in pretty good shape, because somebody (thanks John) uses it daily and is able to report quickly any breakage to us non-Freebsd users. I have tried earlier to give it a shot and build GDB using the image available here: https://www.gnu.org/software/hurd/hurd/running/qemu.html but couldn't get very far (apt-get install wouldn't work). Or at least, is there an easy way to get a cross-compiling environment for Debian/Hurd, let's say on Debian/Linux stable? > I took a quick look at it and one question I have is whether > nm-i386gnu.h really needs to include any of the headers it does. > defs.h > already includes unistd.h, and regcache.h should probably not be > needed; > and removing the mach includes would at least reduce the number of > spots > needing the "struct". Could you try removing these lines? > > Also I happened to notice that file declares gnu_target_pid_to_str -- > but I didn't see a definition. So perhaps that could be removed as > well. And to answer Svante's question about "what to do next", I think the intention long term was to put all of gdb in its own namespace, initially for fixing some gnulib clashes. That's what triggered Pedro to do some C++ improvements (including wild matching). For more details, see this, around the 15:00 mark: https://slideslive.com/38902352/gdb-c-conversion-dogfooding-c Looks like the prototype he did is on this branch: https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace If this would fix the Hurd case, then maybe we can go with this. Pedro, do you think we would be ready for such a move? I would prefer to do that than to re-add a ton of "struct" keywords. Simon