From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84505 invoked by alias); 24 Aug 2018 15:29:55 -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 83220 invoked by uid 89); 24 Aug 2018 15:29:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1067 X-HELO: jocasta.intra Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Aug 2018 15:29:44 +0000 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id w7OFTYZx031009 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Aug 2018 17:29:34 +0200 Received: (from john@localhost) by jocasta.intra (8.15.2/8.15.2/Submit) id w7OFTYi8031008; Fri, 24 Aug 2018 17:29:34 +0200 Date: Fri, 24 Aug 2018 15:29:00 -0000 From: John Darrington To: Simon Marchi Cc: John Darrington , gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] gdb: Added builtin types for 24 bit integers. Message-ID: <20180824152934.bvs2y2t6py4vbynn@jocasta.intra> References: <20180823173526.26144-1-john@darrington.wattle.id.au> <7b7853c6462d8806bc4a2a743330a382@polymtl.ca> <20180823200349.gxeuad3ms3c2apei@jocasta.intra> <603c98bc68bec04acb84d809c838abb0@polymtl.ca> <20180824061125.7vjvlopdx4bstg4l@jocasta.intra> <0f42f2a6bd5c76d40242043ca8b65cf3@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f42f2a6bd5c76d40242043ca8b65cf3@polymtl.ca> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-08/txt/msg00594.txt.bz2 On Fri, Aug 24, 2018 at 11:09:40AM -0400, Simon Marchi wrote: I'm not sure I understand. I was only talking about the definition of the int24_t and uint24_t types, not the handling of DW_EH_PE_udata3. From what I read, the C99 standard mandates that the 8, 16, 32 and 64 variants of the intX_t/uintX_t types exist. Other types (with other values of X) would be extensions. That's why I thought it would make sense to define that in the s12z-specific gdbarches only. In the end I don't really mind, but it just looks like the "clean" way to do it and doesn't seem really more difficult. Can you see if the attached diff (applied on top of your series) work for you? Yes, I see no reason why that shouldn't work. Like you say, C99 et. al. doesn't require uint24_t but doesn't prohibit it either. I just thought, that it makes sense to keep all these type definitions in the same place so as to avoid the next 24 bit arch having to copy this definition. But I don't have a strong opinion either way. J'