From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12001 invoked by alias); 5 Sep 2010 17:16:09 -0000 Received: (qmail 11991 invoked by uid 22791); 5 Sep 2010 17:16:09 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_50,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ns.intrepid.com (HELO mail.intrepid.com) (74.95.8.113) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 05 Sep 2010 17:16:02 +0000 Received: from screamer.local (screamer.local [10.10.1.2]) by mail.intrepid.com (8.13.8/8.13.8) with ESMTP id o85HG1kh003819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Sep 2010 10:16:01 -0700 Received: from [10.10.1.224] ([10.10.1.224]) by screamer.local (8.14.4/8.14.4) with ESMTP id o85HG1lk030273 for ; Sun, 5 Sep 2010 10:16:01 -0700 Message-ID: <4C83D050.7010903@intrepid.com> Date: Sun, 05 Sep 2010 17:16:00 -0000 From: Nenad Vukicevic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: multi-{inferior,exec} References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00035.txt.bz2 > I think the next missing bit is support for I/T sets. E.g., I wanted to > try to debug g++ but put a breakpoint in its cc1plus subprocess. You > can do this today, but only clumsily: either by using add-inferior to > load the symbols for cc1plus, or by using "catch exec" and setting the > breakpoint at exec time. I/T sets would let users set this sort of > breakpoint more easily. I think that I/T sets is a very useful addition. Recently we've made some changes for debugging of the UPC - http://www.gnu.org/software/gcc/projects/gupc.html - programs. However, as our run-time contains a thread that is not UPC language related, I made some changes and created a "upcmode" of operation where commands like breakpoint, info threads, .. apply only to UPC threads (a set in your example). Also, "c -a" like commands apply only to UPC threads. Same with "thread apply all". In essence you are focusing your debugging to a group of threads. Switching off "upcmode" makes everything go back to normal (in your case selecting a thread set "all" turns off this feature). Also, having set names is better then numbers (e.g. "upc" set of threads for UPC program set) and using names or numbers should be interchangeable. We also had to implement "collective" breakpoints where breakpoint is announced to user only once all the threads reached it. In "upcmode" every breakpoint is a collective one, unless you explicitly turn this feature off. Nenad