From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31876 invoked by alias); 3 May 2012 21:50:01 -0000 Received: (qmail 31854 invoked by uid 22791); 3 May 2012 21:50:00 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 May 2012 21:49:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 44A721C634B; Thu, 3 May 2012 17:49:46 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bL972xo-F7Yz; Thu, 3 May 2012 17:49:46 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 103FA1C6289; Thu, 3 May 2012 17:49:45 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A0C0B145616; Thu, 3 May 2012 14:49:33 -0700 (PDT) Date: Thu, 03 May 2012 21:50:00 -0000 From: Joel Brobecker To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. Message-ID: <20120503214933.GJ15555@adacore.com> References: <1336071802-13599-1-git-send-email-brobecker@adacore.com> <1336071802-13599-2-git-send-email-brobecker@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00106.txt.bz2 Thanks for the detailed feedback :) > Thanks for this work -- can you give me a reference to some background > information as to why exactly we want to remove the AT_SYMBOL method? I do not have a specific reference. Only the fact that it's always been a method that we wanted to deprecate and then remove support for... > For the record: the respective ABIs mandate that the stack is aligned > to 8 bytes for 32-bit targets and to 16 bytes for 64-bit targets. Ah, that explains why mips_frame_align aligned to 16 bytes boundaries... I googled that question instead of looking that information up in my manuals - my bad. > There's one fundamental problem with this change -- software breakpoints > must not be used unconditionally, because some configurations do not > expect or support them. I think that we will be fine, because the code is not actually inserting the breakpoint, merely reserving the room for it on the stack. Later on, the target layer then inserts the breakpoint for us, using the appropriate method. If you're connected to a board via JTAG, it should do the right thing. > I can address all these microMIPS issues if you like as I'm likely > more familiar with that stuff, I'd feel more comfortable if you did. I think I understand a little better what you mean by microMIPS, although I thought it was what the code called mips16. But I realize now that it's something different, because IIRC you can switch between mips16 and mips32 by simply using odd addresses (or not). > > @@ -6906,10 +6936,8 @@ mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) > > > > /* MIPS version of CALL_DUMMY. */ > > > > - /* NOTE: cagney/2003-08-05: Eventually call dummy location will be > > - replaced by a command, and all targets will default to on stack > > - (regardless of the stack's execute status). */ > > - set_gdbarch_call_dummy_location (gdbarch, AT_SYMBOL); > > + set_gdbarch_call_dummy_location (gdbarch, ON_STACK); > > + set_gdbarch_push_dummy_code (gdbarch, mips_push_dummy_code); > > set_gdbarch_frame_align (gdbarch, mips_frame_align); > > > > set_gdbarch_convert_register_p (gdbarch, mips_convert_register_p); > > So what if the stack pages are indeed not executable (their page entries > have the XI aka Execute Inhibit bit set)? The only time when we are executing an instruction on the stack is when the function being called returns and hits the breakpoint. IIRC, there has been some testing done against this situation, and things just worked. I suspect that we get a trap, and that trap correctly gets interpreted. I can see ourselves receiving a signal instead, but I think this can also be correctly interpreted. Maybe we'll have to make some adjustement to GDB's core, but I'd rather fix that if I have a way to reproduce and therefore test... Cheers, -- Joel