From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14162 invoked by alias); 18 Oct 2005 20:00:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14111 invoked by uid 22791); 18 Oct 2005 20:00:12 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 18 Oct 2005 20:00:12 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id j9IJxKSu006915; Tue, 18 Oct 2005 21:59:20 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j9IJxJAo030593; Tue, 18 Oct 2005 21:59:19 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j9IJxJn2022154; Tue, 18 Oct 2005 21:59:19 +0200 (CEST) Date: Tue, 18 Oct 2005 20:00:00 -0000 Message-Id: <200510181959.j9IJxJn2022154@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: brobecker@adacore.com, gdb-patches@sources.redhat.com In-reply-to: <20051018191208.GA19167@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 18 Oct 2005 15:12:08 -0400) Subject: Re: Question regarding storing/restoring data during inferior function call References: <20051018184607.GO1034@adacore.com> <20051018191208.GA19167@nevyn.them.org> X-SW-Source: 2005-10/txt/msg00154.txt.bz2 > Date: Tue, 18 Oct 2005 15:12:08 -0400 > From: Daniel Jacobowitz > > Right now, the inferior function call is made AT_ENTRY_POINT. One > > way to solve my problem that might work is to make the call ON_STACK. > > Not sure if that's allowed on this chip. But this way, I can > > dynamically create a small piece of code that does the branch to the > > target function, which would implicitly cause the BSP update that > > we're currently doing ourselves. This does open a whole can of worms, > > though, as I think I'll need to revisit the entire dummy frame unwinder, > > won't I? > > Maybe, maybe not. Might be the easiest answer. I'd suspect ia64 > dislikes executable stacks, though. Can you (ew) poke the necessary > code into the entry point, assuming it is small enough? If it's just a > jump to register... On PA-RISC the C startup code provided some help here by providing some of the code to do the branch with setting up the registers correctly. I think libgcc also had some code to deal with it. Perhaps there is some magic help on ia64 too? Mark