From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16198 invoked by alias); 17 Jun 2009 18:19:35 -0000 Received: (qmail 16190 invoked by uid 22791); 17 Jun 2009 18:19:34 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Jun 2009 18:19:27 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5HIJQYP004425 for ; Wed, 17 Jun 2009 14:19:26 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5HIJPCd016340; Wed, 17 Jun 2009 14:19:25 -0400 Received: from opsy.redhat.com (vpn-12-224.rdu.redhat.com [10.11.12.224]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5HIJOZp007621; Wed, 17 Jun 2009 14:19:24 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 8F60E508283; Wed, 17 Jun 2009 12:19:23 -0600 (MDT) To: gdb-patches@sourceware.org Subject: Re: [RFC] [1/2] First cut at multi-executable support. References: <200906151621.57104.pedro@codesourcery.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Wed, 17 Jun 2009 18:19:00 -0000 In-Reply-To: <200906151621.57104.pedro@codesourcery.com> (Pedro Alves's message of "Mon\, 15 Jun 2009 16\:21\:55 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (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: 2009-06/txt/msg00442.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> All-in-all, what do you think of this, and the patch below? I think it is unbelievably awesome. Pedro> There's certainly scope of a lot of goodies to be added on top Pedro> of this, like extending thread control support (threads groups, itsets Pedro> or whatever); better support for symbol scoping a-la HPD's ## syntax Pedro> would be great too; Making the breakpoints module smarter about Pedro> that also would be nice. ... sharing objfiles across inferiors would be nice. It seems to me that this would be important for capping memory use when there are many inferiors. I wonder if this makes sense with the aspace/sspace stuff, given that an objfile now has a symbol space. When gdb sees a new inferior, does it immediately read its debuginfo? This seems like another possible performance problem; lazily reading it would be friendlier. In a scenario like the "make" case, I would assume that most inferiors will not actually require any user attention, and time and memory spent on their debuginfo is just wasted. I saw this in the output: [Thread debugging using libthread_db enabled] process 16875 is executing new program: /bin/true (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program exited normally. make[2]: Leaving directory `/home/pedro/gdb/sspaces/build/gdb/gdbserver' Program exited normally. Program exited normally. Program exited normally. make[1]: Leaving directory `/home/pedro/gdb/sspaces/build/gdb' Program exited normally. I think the "(no debugging symbols found)" thing has been addressed. At least, there was a patch. "Program exited normally." could also use some love... at least some info about the program, and maybe removing the excess newlines? I see in many places that we pass an address_space and a CORE_ADDR together, e.g.: +insert_single_step_breakpoint (struct address_space *aspace, CORE_ADDR next_pc) Does a CORE_ADDR make sense without an address_space? I'm curious whether you considered putting the address_space into CORE_ADDR, or making a new type holding both. +#define exec_bfd current_symbol_space->ebfd +#define exec_bfd_mtime current_symbol_space->ebfd_mtime +#define so_list_head current_symbol_space->so_list +#define symfile_objfile current_symbol_space->symfile_objfile_1 +#define object_files current_symbol_space->objfiles +#define current_target_sections (¤t_symbol_space->target_sections) I don't mind this kind of thing as a transitional change, to make it so a patch doesn't completely explode. But I think I'd prefer, in the long run, to replace these macros with their expansions (or maybe accessor macros taking current_symbol_space as an argument) everywhere. What do you think? Also, I am curious about the relationship between the current inferior and the current symbol space. I guess whenever the current inferior changes, the current inferior space must as well? + ui_out_table_header (uiout, 1, ui_left, "current", ""); For some reason I did not think of leaving the header empty when I did this for "info inferiors". I like this better... since you're also touching print_inferior, how about just making that change? I can't really comment on the rest of the patch. I skimmed it but I don't know the original code well enough. Nothing stood out as bad. Tom