From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32646 invoked by alias); 9 Sep 2014 00:16:21 -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 32634 invoked by uid 89); 9 Sep 2014 00:16:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 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.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Sep 2014 00:16:18 +0000 Received: from licht.localdomain ([62.158.10.31]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mc9U3-1XhING1hNH-00JXK3; Tue, 09 Sep 2014 02:16:05 +0200 Received: from licht.localdomain (localhost.localdomain [127.0.0.1]) by licht.localdomain (8.12.8/8.12.8) with ESMTP id s890G3RF007029; Tue, 9 Sep 2014 02:16:03 +0200 Received: (from pes@localhost) by licht.localdomain (8.12.8/8.12.8/Submit) id s890G2eg007026; Tue, 9 Sep 2014 02:16:02 +0200 From: Peter Schauer Message-Id: <201409090016.s890G2eg007026@licht.localdomain> Subject: Re: eliminate deprecated_insert_raw_breakpoint. what's left. To: brobecker@adacore.com (Joel Brobecker) Date: Tue, 09 Sep 2014 00:16:00 -0000 Cc: palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org (GDB Patches) In-Reply-To: <20140908213427.GF28404@adacore.com> from "Joel Brobecker" at Sep 08, 2014 02:34:27 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/msg00209.txt.bz2 > > > > This is AIX code. Looks like this can easily be converted to a > > > momentary breakpoint? > > > > I am actually wondering whether this is still needed. It could! > > So, the first thing I wanted to do was to run the testsuite without. > > I'm currently building GDB, which is taking forever, and will then > > run AdaCore's testsuite. > > Looking at the code, it should be executed each time the SP register > gets changed, which means it should trigger when calling functions > from GDB. Deactivating exec_one_dummy_insn entirely did not result > in any regression I could notice. That was on AIX 7.1. > > That being said, I'm hesitant of removing the code regardless, > since this could only be needed in specific situations which might > not be covered by the testsuites we have. > > I was looking at how to replace that call, but I am not sure > how to fix the code up, though. Perhaps we could just write > the breakpoint instruction in by hand, rather than go through > the breakpoint module? After all, it is already doing almost > everything else by hand! > > In fact, looking at the code again now, I'm a little more tempted > to see what happens if we remove it ;-). 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. 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. 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 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. -- Peter Schauer Peter.Schauer@mytum.de