From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45217 invoked by alias); 30 Aug 2019 15:42:25 -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 45209 invoked by uid 89); 30 Aug 2019 15:42:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:U*uweigand X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2019 15:42:24 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D444CB035; Fri, 30 Aug 2019 15:42:21 +0000 (UTC) Subject: Re: [PATCH] s390: Implement 'type_align' gdbarch method To: Ulrich Weigand Cc: Andreas Arnez , gdb-patches@sourceware.org, Tom Tromey References: <20190830151633.1AB17D802F0@oc3748833570.ibm.com> From: Tom de Vries Openpgp: preference=signencrypt Message-ID: <648deb6c-ddb5-c4bc-e799-86a7406762e8@suse.de> Date: Fri, 30 Aug 2019 15:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190830151633.1AB17D802F0@oc3748833570.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00656.txt.bz2 On 30-08-19 17:16, Ulrich Weigand wrote: > Tom de Vries wrote: > >> in the "zSeries ELF Application Binary Interface Supplement" document I >> find long double listed with 16-byte size and alignment. >> >> Likewise in the "IBM XL C/C++ for Linux on z Systems Optimization and >> Programming Guide". >> >> So I wonder, is this patch hardcoding the assumptions of a single >> compiler implementation (gcc) in gdb, thereby possibly breaking >> functionality in gdb when debugging executables generated by other >> compilers? > > This was an error in the original ABI document, unfortunately. > We are currently working on an updated ABI document that will > fix this (and several other errors). Andreas should know the > current status of this update. > > To my knowledge, every Linux on Z compiler in existance has > implemented the 8-byte alignment for long double. (This is > certainly true for GCC and LLVM; I cannot check XL C since > this is no longer supported on Linux.) > > There is in fact a good reason for having (at most) 8-byte > alignment for all standard types: the ABI only guarantees that > the incoming stack pointer is 8-byte aligned. Having any larger > alignment requirement on a standard type would basically force > compilers to implement dynamic stack realignment. > > (If I were to re-design the ABI from scratch today, that > would certainly be one of the things I'd do differently > -- but we are where we are.) I understand it now, thanks for the detailed explanation. - Tom