From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117328 invoked by alias); 30 Aug 2019 15:16:42 -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 117319 invoked by uid 89); 30 Aug 2019 15:16:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=thereby, H*x:2.5, H*UA:2.5 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2019 15:16:41 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7UF81QV121195 for ; Fri, 30 Aug 2019 11:16:40 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2uq5xy0vk1-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Aug 2019 11:16:39 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Aug 2019 16:16:37 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 30 Aug 2019 16:16:34 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x7UFGXgm32571434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Aug 2019 15:16:33 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BFD7842042; Fri, 30 Aug 2019 15:16:33 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AB29042045; Fri, 30 Aug 2019 15:16:33 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.145.27.37]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 30 Aug 2019 15:16:33 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 1AB17D802F0; Fri, 30 Aug 2019 17:16:33 +0200 (CEST) Subject: Re: [PATCH] s390: Implement 'type_align' gdbarch method To: tdevries@suse.de (Tom de Vries) Date: Fri, 30 Aug 2019 15:16:00 -0000 From: "Ulrich Weigand" Cc: arnez@linux.ibm.com (Andreas Arnez), gdb-patches@sourceware.org, tom@tromey.com (Tom Tromey) In-Reply-To: <58a64dce-9855-c43b-43f9-f93fdd31ab73@suse.de> from "Tom de Vries" at Aug 27, 2019 01:29:22 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 19083015-0020-0000-0000-00000365B1EF X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19083015-0021-0000-0000-000021BB0F57 Message-Id: <20190830151633.1AB17D802F0@oc3748833570.ibm.com> X-SW-Source: 2019-08/txt/msg00655.txt.bz2 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.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com