From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23763 invoked by alias); 2 Jun 2009 11:06:48 -0000 Received: (qmail 23753 invoked by uid 22791); 2 Jun 2009 11:06:47 -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 mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Jun 2009 11:06:37 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.14.3/8.13.8) with ESMTP id n52B5ihi557152 for ; Tue, 2 Jun 2009 11:05:44 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 n52B5iqW3092488 for ; Tue, 2 Jun 2009 13:05:44 +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 n52B5iHq002398 for ; Tue, 2 Jun 2009 13:05:44 +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 n52B5hvH002367; Tue, 2 Jun 2009 13:05:43 +0200 Message-Id: <200906021105.n52B5hvH002367@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 02 Jun 2009 13:05:43 +0200 Subject: Re: [RFC,v2] Yank out target_ops->to_sections To: pedro@codesourcery.com (Pedro Alves) Date: Tue, 02 Jun 2009 11:06:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200905291513.42076.pedro@codesourcery.com> from "Pedro Alves" at May 29, 2009 03:13:41 PM 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-06/txt/msg00015.txt.bz2 Pedro Alves wrote: > I've been thinking for a while that the exec_ops target > should be pushed whenever we have any kind of file loaded (main > executable or dynamic shared module) that we can read memory > from. It implements the file_stratum after all, and target.h says: > > file_stratum, /* Executable files, etc */ > ^^^ I agree, and I like the approach in your v3 patch :-) > Here's a stripped down version of what I've got here currently: > > /* A symbol space represents a symbolic view of an address space. It > holds all the data associated with a non-running-yet program (main > executable, main symbols), and when an inferior is running and is > bound to it, includes the list of its mapped in shared libraries. > > In the traditional debugging scenario, there's a 1-1 correspondence > among symbol spaces, inferiors and address spaces, like so: > > sspace1 (prog1) <--> inf1(pid1) <--> aspace1 Thanks for the detailed description! This makes sense to me. > There still needs to be a global somewhere, there's no way around it, > but, it will be the "current_symbol_space", not the target sections. > This global is then switched whenever we need to switch context > --- switch thread, insert breakpoints, or by user command, to e.g., > prepare to start a new inferior --- in a sense, this structure holds > the globals that currently form a "prototype" for an inferior. This is the one part I'm not sure I agree with. I would have hoped we could actually get *rid* of all those globals, at least as far as the GDB core is concerned. (There may be globals in the UI code where it makes sense, to represent conceptually global settings at the the UI level like the notion of the "selected frame". But all of GDB's core should IMO be fully parameterized and not rely on globals. I'd expect this could be achieved by passing "inferior" or "thread" arguments to some of the central functions ...) > > 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 ... > > I think that historically, it was the other way around. They were never > added in the beggining, and when shared libraries support for core > files was added to GDB, the corresponing targets that supported it > were adjusted to pass a target_ops pointer. > > We've currently got more use for the target sections (trust-readonly-sections, > for once), so I think we should always add the sections. I've done a bit > of history digging. Looking at gdb 3.98's sources, and I see in solib.c: Thanks for doing this research! You've convinced me it should be fine to unconditionally add solib target sections. > solib-irix.c: solib_add ((char *) 0, 0, (struct target_ops *) 0, auto_solib_add); > > I can't see a native .mt file pulling this in. It's a target property: mips*-sgi-irix5*) # Target: MIPS SGI running Irix 5 gdb_target_obs="mips-tdep.o mips-irix-tdep.o solib.o solib-irix.o" ;; mips*-sgi-irix6*) # Target: MIPS SGI running Irix 6.x gdb_target_obs="mips-tdep.o mips-irix-tdep.o solib.o solib-irix.o" ;; > This shared library support can't be being used with core inferiors, since > irix_solib_create_inferior_hook always wants to resume the target. Hmm, good point. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com