From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15062 invoked by alias); 30 Jul 2013 19:20:23 -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 15036 invoked by uid 89); 30 Jul 2013 19:20:22 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_05,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 30 Jul 2013 19:20:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6UJK7WI020453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jul 2013 15:20:11 -0400 Received: from barimba (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6UJK4Ds029104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Jul 2013 15:20:04 -0400 From: Tom Tromey To: Pedro Alves Cc: lgustavo@codesourcery.com, "'gdb-patches\@sourceware.org'" Subject: Re: [PATCH] Share ptrace options discovery/linux native code between GDB and gdbserver References: <51F04092.2070008@codesourcery.com> <51F80CDB.3050106@redhat.com> Date: Tue, 30 Jul 2013 19:20:00 -0000 In-Reply-To: <51F80CDB.3050106@redhat.com> (Pedro Alves's message of "Tue, 30 Jul 2013 19:58:35 +0100") Message-ID: <87ehaflusc.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-07/txt/msg00792.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> That's a roundabout way of ending up with all code in a Pedro> single file anyway. And it left us with a weird linux-nat-common.c file Pedro> in a few intermediate steps where it no longer hold code used by the Pedro> gdb side backend (because by then there's no gdb side backend!). If the Pedro> code within is well isolated, we could even consider not merging it Pedro> back into linux-low.c in the end, keeping the backend split in smaller Pedro> modules. But in order to do that, we best name it something actually Pedro> indicative or its contents, and avoid coming up with new kitchen sinks. Pedro> Say, this file holds the waitpid/__WALL/EINTR wrapper replacement, so Pedro> what about linux-waitpid.c ? Then: Pedro> linux-nat.c, gdbserver/linux-low.c, Pedro> -> linux-nat.c, gdbserver/linux-low.c, common/linux-waitpid.c Pedro> -> gdbserver/linux-low.c, common/linux-waitpid.c Pedro> -> common/linux-low.c, common/linux-waitpid.c My initial reaction was that combining movement and refactoring is bad. But on reflection it seems like just movement: the functions (pretty much) stay the same; they may get some minor tweaks (as you'd expect from a merge); but putting them into separate smaller new files is really no different from stuffing them all into one big new file. So I'm on board. More stuff to put on the project page on the wiki... Tom