From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11521 invoked by alias); 9 Sep 2014 12:38:00 -0000 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 Received: (qmail 11509 invoked by uid 89); 9 Sep 2014 12:37:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Sep 2014 12:37:57 +0000 Received: from licht.localdomain ([62.158.11.183]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MfmWy-1Xm8pB0KSy-00NBMc; Tue, 09 Sep 2014 14:37:53 +0200 Received: from licht.localdomain (localhost.localdomain [127.0.0.1]) by licht.localdomain (8.12.8/8.12.8) with ESMTP id s89CboRF017515; Tue, 9 Sep 2014 14:37:50 +0200 Received: (from pes@localhost) by licht.localdomain (8.12.8/8.12.8/Submit) id s89CbnwW017512; Tue, 9 Sep 2014 14:37:49 +0200 From: Peter Schauer Message-Id: <201409091237.s89CbnwW017512@licht.localdomain> Subject: Re: eliminate deprecated_insert_raw_breakpoint. what's left. To: uweigand@de.ibm.com (Ulrich Weigand) Date: Tue, 09 Sep 2014 12:38:00 -0000 Cc: brobecker@adacore.com (Joel Brobecker), palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org (GDB Patches) In-Reply-To: <201409091138.s89BcpNI023387@d06av02.portsmouth.uk.ibm.com> from "Ulrich Weigand" at Sep 09, 2014 01:38:51 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1; X-SW-Source: 2014-09/txt/msg00222.txt.bz2 > Peter Schauer wrote: > > > I hope to be able to shed some light on this problem, although it > > is more than fifteen years ago that I did some work for GDB on AIX. > > > > From my notes back then, AIX 3 and AIX 4 had a very peculiar ptrace > > implementation, where the current ptrace state of the inferior process > > (including the current process registers) was maintained approximately > > 512 bytes below the current user stack pointer of the process. > > > > This resulted in problems with AIX inferior function calls. > > If the called function takes one or more large aggregate parameters > > by value, or if you pass a large amount of parameters, the ptrace > > area gets corrupted, when the dummy function call parameters are > > pushed on the user stack, due to this awkward AIX stack layout. > > Thanks for providing this background! > > > To work around this problem, the execution of a dummy instruction > > (when altering the stack pointer) caused the kernel to move the ptrace > > state area further below on the user stack, allowing GDB to write below > > the current user stack safely. > > In GDB 6.x, rs6000_push_dummy_call even secured the stack partially during > > pushing of the arguments, via an additional call of > > regcache_raw_write_signed to gdbarch_sp_regnum (gdbarch), which is > > no longer present in current versions of GDB. > > Well, I still see this: > /* Set the stack pointer. According to the ABI, the SP is meant to > be set _before_ the corresponding stack space is used. On AIX, > this even applies when the target has been completely stopped! > Not doing this can lead to conflicts with the kernel which thinks > that it still has control over this not-yet-allocated stack > region. */ > regcache_raw_write_signed (regcache, gdbarch_sp_regnum (gdbarch), sp); > > and: > /* This is another instance we need to be concerned about > securing our stack space. If we write anything underneath %sp > (r1), we might conflict with the kernel who thinks he is free > to use this area. So, update %sp first before doing anything > else. */ > > regcache_raw_write_signed (regcache, > gdbarch_sp_regnum (gdbarch), sp); > > Are there other instances where this is missing? Ok, my bad, I was looking at the wrong push_dummy_call implementation in the current GDB source. rs6000_push_dummy_call in the new rs6000-aix-tdep.c file in the current GDB source still contains the code in question from GDB 6.x, there is nothing missing. > > Executing the dummy instruction is very fragile, especially if signals > > get involved during the execution, and it didn't even help, if more > > than ~100 bytes of parameters were pushed on the user stack on AIX 4. > > Back then, there was no other choice though. > > > > Unfortunately I do not know, if this peculiar AIX stack layout is still > > used in AIX 5 or later, maybe Ulrich Weigand could tell you more about it. > > I don't know off-hand. I'll try to find out. > > > I think you could/should zap exec_one_dummy_insn, provided that you test > > a dummy function call on the oldest AIX version that GDB has to support, > > with a large aggregate parameter, which is passed by value. > > The only version I have ready access to is AIX 7.1, and on this there > are no testsuite regression (and in fact, quite a number of failures > seem to go away!) when zapping exec_one_dummy_insn. +1 for zapping exec_one_dummy_insn. > I'm not sure which versions we need to / should support in GDB; I guess > the oldest version where the OS itself is still supported by IBM is 6.1. Maybe somebody could test if zapping exec_one_dummy_insn on AIX 6.1 has any negative effect, and then be done with it. But even if that can't be tested, I am all in favour of getting rid of it, perhaps with a detailed comment in the commit message for the removal (or adding a link to this thread). -- Peter Schauer Peter.Schauer@mytum.de