From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27614 invoked by alias); 27 May 2009 18:24:26 -0000 Received: (qmail 27538 invoked by uid 22791); 27 May 2009 18:24:21 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 May 2009 18:24:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n4RIO8oJ199998 for ; Wed, 27 May 2009 18:24:08 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4RIO8i9946430 for ; Wed, 27 May 2009 20:24:08 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4RIO7JP010280 for ; Wed, 27 May 2009 20:24:08 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n4RIO6m6010275; Wed, 27 May 2009 20:24:06 +0200 Message-Id: <200905271824.n4RIO6m6010275@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 27 May 2009 20:24:06 +0200 Subject: Re: [RFC,v2] Yank out target_ops->to_sections To: pedro@codesourcery.com (Pedro Alves) Date: Wed, 27 May 2009 18:24:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200905270030.12112.pedro@codesourcery.com> from "Pedro Alves" at May 27, 2009 12:30:11 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-05/txt/msg00586.txt.bz2 Pedro Alves wrote: > On Sunday 24 May 2009 02:35:20, Pedro Alves wrote: > > > - Again, I've moved the whole handling of unmmaped overlay > > sections to memory_xfer_partial. There used to be a bit of it in xfer_memory. > > It's now centralized, and, the memory reads are now always > > really dispatched to read directly from files --- previously, they could > > go to the core layer first (don't know if there's any target that > > mixes core debugging with overlays, but if there is, I believe > > this change is correct). > > It seems I don't have access to any target using an overlay manager. I > think Cell uses overlays? Ulrich, perhaps I could ask you the favour of > confirming that I'm not breaking anything overlay related? A genaral peek > over the patch would be much appreciated as well, of course. Your changes to overlay support look good to me, and I've verified that the patch introduces no regressions on spu-elf, including the overlay test cases. In general, I like the idea of your patch, in particular the elimination of sections from target_ops, and removal of xfer_memory. I'm not quite sure what to think of the new current_target_sections variable, in particular its interaction with target_get_section_table. Why do you need a generic fallback to current_target_sections, instead of e.g. having exec_ops implement a to_get_section_table method? How to you see this work in a multi-inferior / multi-address-space setup? Also, I'm not completely sure I understand the implications of the solib_add change. The old method allowed callers to explicitly ask that the library sections be *not* added to the section table, and several callers did that. With your patch, sections are always added. Was it always an error to not add sections? I'm not really sure why this feature was introduced ... (Maybe as a follow-on, ...) Now that we have a struct target_section_table, some of the interfaces that use two target_section pointers should be changed to take a single target_section_table pointer, perhaps? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com