From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5259 invoked by alias); 9 May 2012 06:21:56 -0000 Received: (qmail 5251 invoked by uid 22791); 9 May 2012 06:21:55 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 06:21:42 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SS0HL-0006Bm-G7 from Maciej_Rozycki@mentor.com ; Tue, 08 May 2012 23:21:39 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 23:21:39 -0700 Received: from [172.30.1.173] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 9 May 2012 07:21:36 +0100 Date: Wed, 09 May 2012 06:21:00 -0000 From: "Maciej W. Rozycki" To: Joel Brobecker CC: Mark Kettenis , Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. In-Reply-To: <20120508204257.GC15555@adacore.com> Message-ID: References: <20120503214933.GJ15555@adacore.com> <20120504205818.GT15555@adacore.com> <201205042118.q44LIh3p018153@glazunov.sibelius.xs4all.nl> <201205051144.q45Bitv4006357@glazunov.sibelius.xs4all.nl> <20120508160542.GB15555@adacore.com> <20120508204257.GC15555@adacore.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: 2012-05/txt/msg00254.txt.bz2 On Tue, 8 May 2012, Joel Brobecker wrote: > > You set bp_addr to SP here, so you rely on the stack pointer to have > > been implicitly adjusted down below the current frame [...] > > I was actually confused, as I thought that SP pointed to the first > unused slot in the stack. Correct, but stack grows downwards. So SP points to the end of the first unused slot. This is best shown with an illustration, e.g. for 32 bits: | | +12 + + | . . . | +8 + + | current | +4 + + | frame | 0 SP --> +-----------+ | free | -4 + + | . . . | -8 + + | | -12 For example for a nested o32 function at SP + 0 you'll have the next frame's $a0 argument save slot. This is really no different to how some architectures with hardware stack support interpret the SP register, e.g. Intel pieces like 8080 or x86 or DEC VAX. > I will make the changes that you suggest and re-test. Great! > One thing that just occured to me while driving home is why not > also use the AT_ENTRY_POINT approach. I figured that there must > have been a reason why we used AT_SYMBOL instead of AT_ENTRY_POINT. > But then, there is your comment that makes me think that the symbol > isn't usually defined, which means that most of (all?) the time, > we actually end up using AT_ENTRY_POINT. Do we know of any reason > why AT_ENTRY_POINT would not work? I'd assume that as long as the > object format is ELF, we'd have one, and so we could use that as > well. I mentioned that in one of the replies -- there was a comment originally that stated that AT_ENTRY_POINT wouldn't work if it was located in a ROM. With software breakpoints that is, but support for hardware breakpoints is not mandatory in MIPS processors (and I think we don't use them for internal breakpoints anyway). The comment was removed with the addition of AT_SYMBOL. Presumably that magic symbol would be arranged by a ROM image generation toolkit. As I say, I've never actually encountered it. > Geee, are we ever going to reach a conclusion on this discussion? :-/ Well, we'll die off eventually, so certainly there's some finite limit. Maciej