From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13077 invoked by alias); 24 Oct 2012 17:23:51 -0000 Received: (qmail 13068 invoked by uid 22791); 24 Oct 2012 17:23:50 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO,RP_MATCHES_RCVD 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; Wed, 24 Oct 2012 17:23:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E4DBA1C7B44; Wed, 24 Oct 2012 13:23:43 -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 pMD09DhWJKaU; Wed, 24 Oct 2012 13:23:43 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C9FCC1C7999; Wed, 24 Oct 2012 13:23:43 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 4C4B2C88A1; Wed, 24 Oct 2012 13:23:41 -0400 (EDT) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: kettenis@gnu.org Subject: amd64-windows: Fix funcall with by-pointer arguments Date: Wed, 24 Oct 2012 17:23:00 -0000 Message-Id: <1351099417-18960-1-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-10/txt/msg00466.txt.bz2 Hello, I realized a while ago that I completely misunderstood the amd64-windows API regarding arguments that are passed by pointer. The calling convention is published there: http://msdn.microsoft.com/en-us/library/zthk2dkh(v=vs.80).aspx Aggregates whose size is not 8/16/32/64 should be passed by pointer, and what that means is that the caller is expected to make a copy of the object, and pass its address as the argument. This is different from passing the argument through the stack and the stack address at the same time. In particular, when you have a function call which involves one of those by-pointer argument that follows an on-stack argument, the incorrect method would puth the by-pointer argument on the stack after the first argument, thus screwing up the offset of the first argument relative to the caller's frame address, etc. This patch series fixes the problem by: 1. Reverting the first (incorrect) attempt at handling by-pointer arguments; 2. Add handling of by-pointer arguments again. Tested on x86_64-windows with AdaCore's testsuite, and on x86_64-linux using the official testsuite.