From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116490 invoked by alias); 29 May 2018 14:53:33 -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 116478 invoked by uid 89); 29 May 2018 14:53:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Probably, newcomers, talks X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 May 2018 14:53:32 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E50B402178A; Tue, 29 May 2018 14:53:30 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id E16BA2166BB2; Tue, 29 May 2018 14:53:29 +0000 (UTC) Subject: Re: [PATCH 4/4] Introduce class target_stack To: Tom Tromey References: <20180528161041.32497-1-palves@redhat.com> <20180528161041.32497-5-palves@redhat.com> <87h8mrxify.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 29 May 2018 14:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87h8mrxify.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00758.txt.bz2 On 05/29/2018 04:13 AM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> The problem then is in finding a target's "beneath" target, if we > Pedro> consider that for some target_ops types, we'll be sharing a > Pedro> single target_ops instance between several inferiors. For > Pedro> example, so far, I found no need to have multiple instances of > Pedro> the spu_multiarch_target / exec_target / dummy_target targets. > > Is it the case that sometimes a particular target_ops instance will have > to be shared among multiple target stacks? > > If so, then this all makes sense to me. Right, it is the case. That is true for targets that support multi-process. E.g., native targets and remote targets. The current model in the branch is: - Each inferior gets its own target stack. - There's only ever one instance of the native target_ops. All native processes/inferiors use the same target_ops, because it's the same ptrace API "instance" that talks to all of them. For example, if you do "info os processes" to list all processes, it's the single native target_ops instance that implements that call. - There's one remote_target (target_ops) instance for each remote connection. All processes/inferiors debugged via that connection share the same remote_target instance. You can have multiple remote connections. - Each process_stratum target_ops instance has its own PID number space. IOW, a process is uniquely identified by the (process_stratum target_ops *, int PID) tuple. Since each inferior has its own target stack, we should be able to do things like activate "target record full" for inferior 1, and "target record btrace" for inferior 2, though I haven't done that. > > Pedro> +/* The target stack. */ > Pedro> +static target_stack g_target_stack; > > As an aside, I often wonder about blank lines between comments and > definitions. > > I prefer not to have them, though not for any actual reason. But some > spots have them and some do not, so in practice what I do is either > follow the local style; or leave the blank line out if I think I can; or > else feel guilty since I vaguely recall there was a rule to have one and > so put it in even though I'd rather not. I think the main rule is: blank line in definition, no blank line in declarations: https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Documenting_Your_Code That's what I think most newer code follows, but it's like you say, in reality I guess most folks follow the local style. I've fixed that case you pointed out. The case in our codebase where I most tend to find blank lines odd, is in the documentation of structure fields: struct S { /* This is foo. */ int foo; /* This is bar. */ int bar; }; I think I dislike it because that way you lose the visual grouping between comment and field that you otherwise have with: struct S { /* This is foo. */ int foo; /* This is bar. */ int bar; }; Curiously, this case that is not explicitly specified in the wiki, though the struct example there does not include spaces. > > Pedro> + Note that rather than allow an empty stack, we always have the > Pedro> + dummy target at the bottom stratum, so we can call the function > Pedro> + vectors without checking them. */ > > Probably just "methods" rather than "function vectors". Indeed, probably less confusing to newcomers. That was just copied over from elsewhere, but I'll adjust it. Thanks, Pedro Alves