From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15520 invoked by alias); 11 May 2007 19:09:35 -0000 Received: (qmail 15505 invoked by uid 22791); 11 May 2007 19:09:33 -0000 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.31) with ESMTP; Fri, 11 May 2007 19:09:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4BJ9Sfk209622 for ; Fri, 11 May 2007 19:09:28 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 l4BJ9SvN4108308 for ; Fri, 11 May 2007 21:09:28 +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 l4BJ9SRh022940 for ; Fri, 11 May 2007 21:09:28 +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 l4BJ9SKO022937; Fri, 11 May 2007 21:09:28 +0200 Message-Id: <200705111909.l4BJ9SKO022937@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 11 May 2007 21:09:28 +0200 Subject: Re: [rfc] [2/4] SPU overlay support: The SPU target part To: drow@false.org (Daniel Jacobowitz) Date: Fri, 11 May 2007 19:09:00 -0000 From: "Ulrich Weigand" Cc: emi-suzuki@tjsys.co.jp (Emi SUZUKI), gdb-patches@sourceware.org In-Reply-To: <20070511173213.GC22529@caradoc.them.org> from "Daniel Jacobowitz" at May 11, 2007 01:32:13 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/msg00207.txt.bz2 Daniel Jacobowitz wrote: > On Fri, May 11, 2007 at 12:20:05AM +0200, Ulrich Weigand wrote: > > 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 > > Clever. Could we have a comment about this in GDB somewhere? > Apologies if there was one; I didn't see it. Sure, I'll add a comment. > > > 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. > > Well, they never end up on the stack. We would if they did. But this > isn't a big issue to me; I'd be very confused if I stepi'd a > return instruction and ended up somewhere other than the function > listed in the backtrace, but my use of GDB is probably not typical. The return stub isn't on the stack either. We'd have to manufacture an extra zero-sized stack frame between caller and callee, with special unwind rules to be able to continue the backtrace. I guess this would be possible somehow, but I still don't see that this would provide any benefit to most users ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com