From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22368 invoked by alias); 11 May 2007 17:32:19 -0000 Received: (qmail 22359 invoked by uid 22791); 11 May 2007 17:32:18 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 May 2007 17:32:16 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id A68A94B267; Fri, 11 May 2007 12:32:14 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 746EE4B262; Fri, 11 May 2007 12:32:14 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HmYyU-0006Rd-1r; Fri, 11 May 2007 13:32:14 -0400 Date: Fri, 11 May 2007 17:32:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: Emi SUZUKI , gdb-patches@sourceware.org Subject: Re: [rfc] [2/4] SPU overlay support: The SPU target part Message-ID: <20070511173213.GC22529@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , Emi SUZUKI , gdb-patches@sourceware.org References: <20070510215500.GC3187@caradoc.them.org> <200705102220.l4AMK6Ug007110@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705102220.l4AMK6Ug007110@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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/msg00189.txt.bz2 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. > > 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. -- Daniel Jacobowitz CodeSourcery