From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17599 invoked by alias); 6 Jul 2009 07:08:43 -0000 Received: (qmail 17577 invoked by uid 22791); 6 Jul 2009 07:08:39 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Jul 2009 07:08:25 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 040C8290025; Mon, 6 Jul 2009 09:08:23 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3CPqBRhjitc; Mon, 6 Jul 2009 09:08:22 +0200 (CEST) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id 12F8C29001B; Mon, 6 Jul 2009 09:08:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by filtered-province.act-europe.fr (Postfix) with ESMTP id DE875166523; Mon, 6 Jul 2009 09:08:21 +0200 (CEST) Received: from province.act-europe.fr ([127.0.0.1]) by localhost (province.act-europe.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWzDnUGEKQCB; Mon, 6 Jul 2009 09:08:21 +0200 (CEST) Received: from [IPv6:::1] (province.act-europe.fr [10.10.0.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by province.act-europe.fr (Postfix) with ESMTPSA id 4230A1664F4; Mon, 6 Jul 2009 09:08:21 +0200 (CEST) Cc: gdb-patches@sourceware.org Message-Id: From: Tristan Gingold To: Mark Kettenis In-Reply-To: <200907031648.n63Gm7Wn019605@brahms.sibelius.xs4all.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [RFA Darwin]: Add push_dummy_call for i386 Date: Mon, 06 Jul 2009 07:08:00 -0000 References: <20090703155152.GA76089@ulanbator.act-europe.fr> <200907031648.n63Gm7Wn019605@brahms.sibelius.xs4all.nl> X-IsSubscribed: yes 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: 2009-07/txt/msg00127.txt.bz2 On Jul 3, 2009, at 6:48 PM, Mark Kettenis wrote: >> Date: Fri, 3 Jul 2009 17:51:52 +0200 >> From: Tristan Gingold >> >> Hi, >> >> Darwin i386 ABI is slightly different from the SVR4 one. In >> particular >> stack alignment is 16. As a consquence, i386 Darwin can't use the >> standard >> i386-tdeo.c push_dummy_call and this patch provides a Darwin >> version of this >> call. >> >> Regtested on i386 Darwin. >> Tristan. > > Tristan, can you provide unified diffs instead of context diffs? > It's much easier to read the unified ones. Sure, I can ;-) >> + static inline int >> + i386_m128_p (struct type *type) >> + { >> + return TYPE_CODE (type) == TYPE_CODE_ARRAY && TYPE_VECTOR (type) >> + && TYPE_LENGTH (type) == 16; >> + } > > Any reason why this function must be inline? Ever since the bright > folks in the ISO committee decided to adpot different rules for things > like static inline and extern inline than GCC, the use of inline makes > me nervous. And I believe modern compilers are very well capable > themselves of deciding if static functions should be inlined or not. I will remove the inline. >> + /* Check whether TYPE must be 16-byte-aligned when passed as a >> + function argument. 16-byte vectors, _Decimal128 and >> structures or >> + unions containing such types must be 16-byte-aligned; other >> + arguments are 4-byte-aligned. */ > > Hmm, this function actually returns the alignment (as a number of > bytes), but the comment suggests it's a predicate. Can you adjust the > comment? Sure. >> + static int >> + i386_darwin_arg_type_alignment (struct type *type) >> + { >> + type = check_typedef (type); >> + /* Passing arguments. >> + 5. The caller places 64-bit vectors (__m64) on the >> parameter area, >> + aligned to 8-byte boundaries. > > "on the parameter area"? Probably a type. I quoted LowLevelABI.pdf. What is wrong in this sentence ? (Keep in mind that I am not a native english speaker!) >> >> + for (write_pass = 0; write_pass < 2; write_pass++) >> + { >> + int args_space = 0; >> + int nbr_m128 = 0; > > nbr_m128? Is that supposed to mean number of m128's? If so, would > you be so kind to reanem this variable num_m128? Ok. >> >> *************** i386_darwin_init_abi (struct gdbarch_inf >> *** 127,133 **** >> tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset; >> tdep->sc_num_regs = i386_darwin_thread_state_num_regs; >> >> ! tdep->jb_pc_offset = 20; >> >> set_solib_ops (gdbarch, &darwin_so_ops); >> } >> --- 255,266 ---- >> tdep->sc_reg_offset = i386_darwin_thread_state_reg_offset; >> tdep->sc_num_regs = i386_darwin_thread_state_num_regs; >> >> ! tdep->jb_pc_offset = 48; >> ! >> ! /* Although the i387 extended floating-point has only 80 >> significant >> ! bits, a `long double' actually takes up 128, probably to >> enforce >> ! alignment. */ >> ! set_gdbarch_long_double_bit (gdbarch, 128); > > This is true for the 32-bit Darwin ABI as well? This is true only for the i386 Darwin ABI. Darwin strictly follows the SVR4 ABI for x86_64. Tristan.