From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8918 invoked by alias); 8 Jun 2010 11:03:31 -0000 Received: (qmail 8804 invoked by uid 22791); 8 Jun 2010 11:03:30 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jun 2010 11:03:26 +0000 Received: (qmail 30258 invoked from network); 8 Jun 2010 11:03:25 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2010 11:03:25 -0000 From: Pedro Alves To: tromey@redhat.com Subject: Re: [patch] Forbid run with a core file loaded Date: Tue, 08 Jun 2010 11:03:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-22-generic; KDE/4.4.2; x86_64; ; ) Cc: Jan Kratochvil , Eli Zaretskii , mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb-patches@sourceware.org References: <20100606195033.GA9710@host0.dyn.jankratochvil.net> <201006071220.58289.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006081203.20066.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00200.txt.bz2 On Tuesday 08 June 2010 03:32:29, Tom Tromey wrote: > 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. It is. It's the obvious next step. It's the missing step into being able to debug parallel MPI programs running on different machines. But that also obviously needs to consider user interface issues -- more than just an internal implementation detail. > 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. Of course everything is fixable. tricker != impossible != undesirable. If you go the simply route of simply sharing the target stack between all inferiors that share the same process_stratum target, you have what we have today. None of that would make Jan's patch any different, because it would still need to be careful to not pop random targets off the stack when _one_ inferior is gone. If you say that you'd only share the _targets_ and not the _stack_ between inferiors, then you'd have to rethink things like the target->beneath pointer, as that is embedded within the target_ops object. -- Pedro Alves