From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8124 invoked by alias); 4 May 2012 21:34:48 -0000 Received: (qmail 8021 invoked by uid 22791); 4 May 2012 21:34:47 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 May 2012 21:34:34 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q44LY6Zo025034; Fri, 4 May 2012 23:34:06 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q44LY4Ax026920; Fri, 4 May 2012 23:34:04 +0200 (CEST) Date: Fri, 04 May 2012 21:34:00 -0000 Message-Id: <201205042134.q44LY4Ax026920@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: macro@codesourcery.com CC: brobecker@adacore.com, gdb-patches@sourceware.org In-reply-to: (macro@codesourcery.com) Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. References: <1336071802-13599-1-git-send-email-brobecker@adacore.com> <1336071802-13599-2-git-send-email-brobecker@adacore.com> 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/msg00138.txt.bz2 > Date: Thu, 3 May 2012 22:08:58 +0100 > From: "Maciej W. Rozycki" > > Joel, > > > This patch switches the mips code to use the ON_STACK method > > for function calls instead of AT_SYMBOL, which we want to remove. > > 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? The AT_SYMBOL method relies on a magic symbol being present in the binarie that's being debugged. There is no guarantee that that magic symbol is actually present in your binary. > > Another little detail on the implementation of mips_push_dummy_code. > > It starts by aligning the stack. AFAIK, the stack is supposed to > > always be aligned to at least 4 bytes (4 bytes for mips32, 8 bytes > > for mips64). So, the initial alignment shouldn't be necessary, since > > that's good enough aligment for our breakpoint instruction. But > > in the end, I chose to keep it, JIC. We could possibly change the > > code to align to 4 instead of 16 like mips_frame_align does, if > > we want to. > > 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. However > the user may have fiddled with SP, so I think it's better to stay safe > and therefore I agree it's better if we prealign the stack and avoid > crashing the debuggee in this context. Like I wrote elsewhere, the generic code that calls push_dummy_code() already alignes the stack, so it isn't necessary to do it again here. > > /* 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 resulting SIGSEGV will be recognized by GDB and handled appropriately; see infrun.c:handle_inferior_event().