From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3035 invoked by alias); 9 Sep 2014 11:39:04 -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 3026 invoked by uid 89); 9 Sep 2014 11:39:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp10.uk.ibm.com Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 09 Sep 2014 11:39:02 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 9 Sep 2014 12:38:58 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 9 Sep 2014 12:38:54 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id E64131B08070 for ; Tue, 9 Sep 2014 12:39:57 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s89BcsHp46596218 for ; Tue, 9 Sep 2014 11:38:54 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s89Bcr38023422 for ; Tue, 9 Sep 2014 05:38:54 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id s89BcpNI023387; Tue, 9 Sep 2014 05:38:51 -0600 Message-Id: <201409091138.s89BcpNI023387@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 09 Sep 2014 13:38:51 +0200 Subject: Re: eliminate deprecated_insert_raw_breakpoint. what's left. To: peterschauer@gmx.net (Peter Schauer) Date: Tue, 09 Sep 2014 11:39:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org (GDB Patches) In-Reply-To: <201409090016.s890G2eg007026@licht.localdomain> from "Peter Schauer" at Sep 09, 2014 02:16:02 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14090911-4966-0000-0000-00000145A13A X-SW-Source: 2014-09/txt/msg00221.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? > 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. 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. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com