From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14560 invoked by alias); 8 Jun 2010 02:33:08 -0000 Received: (qmail 14552 invoked by uid 22791); 8 Jun 2010 02:33:07 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jun 2010 02:33:03 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o582WWB7011793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jun 2010 22:32:32 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o582WVKb002969; Mon, 7 Jun 2010 22:32:31 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o582WTSw001139; Mon, 7 Jun 2010 22:32:30 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 9D2A73782A3; Mon, 7 Jun 2010 20:32:29 -0600 (MDT) From: Tom Tromey To: Pedro Alves Cc: Jan Kratochvil , Eli Zaretskii , mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [patch] Forbid run with a core file loaded References: <20100606195033.GA9710@host0.dyn.jankratochvil.net> <201006071220.58289.pedro@codesourcery.com> Reply-To: tromey@redhat.com Date: Tue, 08 Jun 2010 02:33:00 -0000 In-Reply-To: <201006071220.58289.pedro@codesourcery.com> (Pedro Alves's message of "Mon, 7 Jun 2010 12:20:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2010-06/txt/msg00197.txt.bz2 Jan> I hope you agree the target stack should be made specific for each Jan> inferior. Pedro> I've gone back and forth on that for a while with the multi-exec Pedro> work. It's trickier than that. How else would you propose letting people attach to multiple inferiors using multiple targets? This seems like a reasonable thing to want to do, e.g., debugging a distributed application of some kind. Pedro> Consider the extended-remote target --- if you do "add-inferior; Pedro> ; inferior 2; run", if we simply had a target Pedro> stack per inferior, then when you get to "run", you'd only have Pedro> "exec" on the inferior 2's stack, but you wanted extended-remote Pedro> to handle creating the inferior. I don't really know enough about the target API, but this seems fixable. "Target stack per inferior" does not necessarily imply that the targets cannot be shared, just that conceptually each inferior carries its own. Tom