From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22548 invoked by alias); 10 May 2007 22:20:25 -0000 Received: (qmail 22536 invoked by uid 22791); 10 May 2007 22:20:24 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 May 2007 22:20:20 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4AMKFOs186686 for ; Thu, 10 May 2007 22:20:15 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 v8.3) with ESMTP id l4AMKFQX3166372 for ; Fri, 11 May 2007 00:20:15 +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 l4AMKEJK007279 for ; Fri, 11 May 2007 00:20:14 +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 l4AMK6Ug007110; Fri, 11 May 2007 00:20:11 +0200 Message-Id: <200705102220.l4AMK6Ug007110@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 11 May 2007 00:20:05 +0200 Subject: Re: [rfc] [2/4] SPU overlay support: The SPU target part To: drow@false.org (Daniel Jacobowitz) Date: Thu, 10 May 2007 22:20:00 -0000 From: "Ulrich Weigand" Cc: emi-suzuki@tjsys.co.jp (Emi SUZUKI), gdb-patches@sourceware.org In-Reply-To: <20070510215500.GC3187@caradoc.them.org> from "Daniel Jacobowitz" at May 10, 2007 05:55:00 PM X-Mailer: ELM [version 2.5 PL2] 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: 2007-05/txt/msg00177.txt.bz2 Daniel Jacobowitz wrote: > (I'm not sure how this ends up detecting an overlay return stub, but > I'll take your word for it.) On the SPU, every register is a 16-byte vector register, and that includes the "link register" 0. As addresses are only 32 bit (actually only 18 bit), only the first of four 32-bit slots in the link register is used to hold the return address. However, the whole 128-bit register is always saved/restored on the stack. This makes it possible to use the remaining slots to hold additional information needed to handle return jumps crossing an overlay boundary. In those cases, the slots are set up to hold: [0] Return stub entry point in the overlay manager [1] Partition number of the overlay section to be returned to [2] Actual return address in the (restored) overlay section Thus, when the normal function return is executed, control will "return" to the overlay manager, which can examine the remaining slots to determine which overlay section to swap in, and then transfer control to the actual return address. What the PC unwinder code does when it sees an unwound link register of that form is to set the PC to the value in slot 2 of the link register, instead of slot 0 as usual. Note that there is no stack frame associated with the return stub at all. > This is clever, but kind of sneaky. We show signal return trampolines > and dummy call trampolines, so I'm not sure why it's necessary to > hide overlay return stubs. Do you think this is more useful than > confusing? Both signal return and dummy call trampolines are entities the user actually knows about and wants to see. The overlay mechanism is supposed to be fully transparent to the user; I'd compare the overlay call and return stubs to things like PLT stubs in ELF -- we don't show those either. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com