From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8409 invoked by alias); 26 Nov 2012 16:05:10 -0000 Received: (qmail 8395 invoked by uid 22791); 26 Nov 2012 16:05:07 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 16:04:59 +0000 Received: from md14.u-strasbg.fr (md14.u-strasbg.fr [130.79.200.249]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id qAQG4rkm064673 ; Mon, 26 Nov 2012 17:04:53 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms15.u-strasbg.fr [130.79.204.115]) by md14.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id qAQG4qaq026482 ; Mon, 26 Nov 2012 17:04:53 +0100 Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id qAQG4qH9018614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) ; Mon, 26 Nov 2012 17:04:52 +0100 (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Maciej W. Rozycki'" Cc: "'GDB Patches'" References: <00a501cd495e$db6adea0$92409be0$@muller@ics-cnrs.unistra.fr> <002a01cd5043$a0e9f310$e2bdd930$@muller@ics-cnrs.unistra.fr> In-Reply-To: <002a01cd5043$a0e9f310$e2bdd930$@muller@ics-cnrs.unistra.fr> Subject: PING [RFC] Fix MIPS frame prologue scan problem Date: Mon, 26 Nov 2012 16:05:00 -0000 Message-ID: <005901cdcbef$c4a28560$4de79020$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-11/txt/msg00660.txt.bz2 Hi Marciej, I didn't get any answer on the question I raised=20 on the bottom of my answer to your comments. I just summarize here: 1) It's true that my pot might not be ABI complaint, but I saw several other assembly code that use the same approach (it might be really old assembler) 2) The current code in mips-tdep.c should either=20 handle the=20 add $s8, $sp, LOCALSIZE in a way similar to what I propose or otherwise at least complain about non-ABI code, no? Pierre > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pierre Muller > Envoy=E9=A0: vendredi 22 juin 2012 08:53 > =C0=A0: 'Maciej W. Rozycki' > Cc=A0: 'GDB Patches' > Objet=A0: RE: [RFC] Fix MIPS frame prologue scan problem >=20 >=20 >=20 > > -----Message d'origine----- > > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > > owner@sourceware.org] De la part de Maciej W. Rozycki > > Envoy=E9=A0: vendredi 22 juin 2012 01:12 > > =C0=A0: Pierre Muller > > Cc=A0: 'GDB Patches' > > Objet=A0: Re: [RFC] Fix MIPS frame prologue scan problem > > > > Hi Pierre, > > > > Sorry about the delay, I've been swamped with stuff recently. > Thanks for your reply. >=20 > > On Wed, 13 Jun 2012, Pierre Muller wrote: > > > > > I am trying to extend the Free Pascal compiler to support > > > MIPS architecture. > > > > > > From what I read so far, register $s8 (register number 30) can be used > > as > > > a frame register, > > > but when I set $s8 to the value of the stack pointer ($sp, register > number > > > 29) > > > I get all my locals and parameter of functions wrong. > > > > > > I traced it down to the fact that GDB seems to use a > > > 'virtual' frame pointer register called $fp, > > > but which is miscalculated in my case. > > > > > > In GCC generated code, $s8 register gets the same value as > > > $sp register, so that this problem does not show up in that case, > > > but for me, if I have a prologue that reserves 80 bytes, > > > I will typically get > > > > > > # Reserve 80 bytes for locals and area for called function parameters > > > addi $sp,$sp,-80 > > > # Save $ra and $s8 registers, there could be others... > > > sw $ra,44($sp) > > > sw $s8,40($sp) > > > # Set $s8 to function entry value of $sp > > > addi $s8,$sp,80 > > > > > > Analysis of first instruction leads to setting of > > > frame_offset to 80. > > > > > > The problem is that when the last instruction > > > is analyzed by mips32_scan_prologue, > > > it switches the frame_reg from $sp to $s8, > > > but does not modify frame_offset value. > > > This leads to a frame pointer $fp > > > being computed as $s8 + frame_offset > > > which is equal to $sp + 2*frame_offset. > > > Thus all my locals are wrong :( > > > > > > Substraction of the constant in the last addi instruction (low_word) > > > to frame_offset seems to cure my problem. > > > > Well, to put it short, you're not supposed to do that if you want to > > follow the MIPS ABI. The MIPS processor has no hardware stack and the > > software implementation of the stack has been made such that there is > > generally no need to arrange for a hard frame pointer (in a register > > separate from the stack pointer), except where dynamic stack allocation > > is used (alloca in C terms). >=20 > I tried to read several MIPS documents, > and the message was not that clear to me... >=20 > > Therefore the right place to look for how the hard frame pointer has been > > specified is the "Dynamic Allocation of Stack Space" section in Chapter 3 > > "Machine Interface" of the MIPS psABI document: > > > > "When a function requires dynamically allocated stack space it manifests a > > frame pointer on entry to the function. The frame pointer is kept in a > > callee-saved register so that it is not changed across subsequent function > > calls. Dynamic stack allocation requires the following steps. > > > > 1. On function entry, the function adjusts the stack pointer by the size > > of the static stack frame. The frame pointer is then set to this > > initial sp value and is used for referencing the static elements > > within the stack frame, performing the normal function of the stack > > pointer." > > > > So in fact both GCC and GDB are correct, you're not supposed to add a > > constant to the stack pointer when calculating the value of the frame > > pointer -- it is supposed to hold the value of the stack pointer *after* > > the frame has been allocated (in other words any frame offsets are > > non-negative). >=20 > Our current problem is that we don't yet knoow the > stacksize that we need for the function while we generate > its code, so that using a frame pointer at previous value of stack pointer > makes this > really easier for now. >=20 > > You need to adjust your code generated (BTW, note that the > > convention assumed by the ABI is to use non-trapping arithmetic; I'm > Is this the difference between > ADDI and ADDIU? > I thought it was only a signed/unsigned difference, > Do that mean that you never generate any exception if you use the U version? > I am really new to MIPS assembly... >=20 > > assuming that you deliberately want to trap on overflows to detect the > > stack pointer crossing the user/kernel segment boundary, right?). > Not really as explained above ... >=20 > > NB I suggest that you get real debug information generated as well; it > > can be stabs if DWARF-2 is too difficult to start with. The heuristic > > unwinder is really the last-chance attempt made by GDB to find its way > > around, can only be relied on when applied to conservative code and is > > best avoided if possible. >=20 > But my problem is really that > GDB found my I do generate stabs debugging information, > and give parameters and locals > offsets relative to frame pointer. >=20 > But in mips32_scan_prologue, > the first > ADDI $s8,$sp,LocalSize > instruction, > interpreted it in mips32_scan_prologue function > but ended up with a wrong position of my > non-ABI standard frame pointer > because it changed frame pointer register from sp to s8 register, > but kept frame_offset value as set by the > SUBI $sp, $sp, LocalSize > instruction > analyzed before. >=20 > Thus GDB wrongly ends up with a > frame pointer located a > value of $s8 register (as from ADDI instruction analysis) > + LocalSize (from SUBI instruction) >=20 > This means that of > $sp is say at address addr > $s8 is at addr +LocalSize > and the virtual frame pointer > $fp at $s8 + LocalSize =3D addr + 2 * LocalSize >=20 >=20 > This means that it would be better to remove > analysis of the ADDI $s8, $sp, LocalSize > than to leave the current behavior. >=20 > I think that we should either use my proposed patch, > or completely remove the analysis of this ADDI $s8, $sp, LocalSize... >=20 >=20 > > I hope this helps, good luck with your port! > > > > Maciej >=20 > Thanks, >=20 > Pierre