Message ID | 1528928623-27479-1-git-send-email-simon.marchi@ericsson.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 45573 invoked by alias); 13 Jun 2018 22:24:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 44842 invoked by uid 89); 13 Jun 2018 22:24:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: sesbmg23.ericsson.net Received: from sesbmg23.ericsson.net (HELO sesbmg23.ericsson.net) (193.180.251.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jun 2018 22:24:27 +0000 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.A8.31551.789912B5; Thu, 14 Jun 2018 00:24:08 +0200 (CEST) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSHC023.ericsson.se (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 14 Jun 2018 00:24:07 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Jun 2018 00:24:07 +0200 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 14 Jun 2018 00:24:07 +0200 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from elxacz23q12.ericsson.se (192.176.1.89) by BYAPR15MB2389.namprd15.prod.outlook.com (2603:10b6:a02:8c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Wed, 13 Jun 2018 22:24:02 +0000 From: Simon Marchi <simon.marchi@ericsson.com> To: <gdb-patches@sourceware.org> CC: Tom Tromey <tom@tromey.com>, Simon Marchi <simon.marchi@ericsson.com> Subject: [PATCH] default_type_align: Use type_length_units Date: Wed, 13 Jun 2018 18:23:43 -0400 Message-ID: <1528928623-27479-1-git-send-email-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: AM5PR0402CA0004.eurprd04.prod.outlook.com (2603:10a6:203:90::14) To BYAPR15MB2389.namprd15.prod.outlook.com (2603:10b6:a02:8c::29) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 25f9af12-8bf8-420c-8db5-08d5d17c5f1e X-MS-TrafficTypeDiagnostic: BYAPR15MB2389: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Forefront-PRVS: 07025866F6 Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2018 22:24:02.8459 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 25f9af12-8bf8-420c-8db5-08d5d17c5f1e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2389 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes |
Commit Message
Simon Marchi
June 13, 2018, 10:23 p.m. UTC
The type alignment value is returned in 8-bit-bytes instead of target memory addressable units. For example, on a target with 16-bit-bytes where sizeof(int) == 1 (one addressable unit), alignof(int) currently returns 2. After, this patch, it returns 1. gdb/ChangeLog: * arch-utils.c (default_type_align): Use type_length_units. --- gdb/arch-utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:
Simon> The type alignment value is returned in 8-bit-bytes instead of target
Simon> memory addressable units. For example, on a target with 16-bit-bytes
Simon> where sizeof(int) == 1 (one addressable unit), alignof(int) currently
Simon> returns 2. After, this patch, it returns 1.
Simon> * arch-utils.c (default_type_align): Use type_length_units.
This certainly is correct according to the comment in gdbtypes.h:
/* * Return the alignment of the type in target addressable memory
units.
However, I was curious to know what DWARF specifies, to see whether
dwarf2read was doing this as well. But DWARF seems pretty silent on
this topic:
A debugging information entry may have a DW_AT_alignment attribute
whose value of class constant is a positive, non-zero, integer
describing the alignment of the entity.
So maybe this is depending on what your compiler does? I think I did
not really consider this issue too deeply when writing the alignment
support :(
Another possible issue is that gdbtypes.c:type_align uses TYPE_LENGTH in
one spot but I suppose it ought to use type_length_units if this patch
goes in.
Tom
On 2018-06-14 12:59, Tom Tromey wrote: > This certainly is correct according to the comment in gdbtypes.h: > > /* * Return the alignment of the type in target addressable memory > units. > > However, I was curious to know what DWARF specifies, to see whether > dwarf2read was doing this as well. But DWARF seems pretty silent on > this topic: > > A debugging information entry may have a DW_AT_alignment attribute > whose value of class constant is a positive, non-zero, integer > describing the alignment of the entity. > > So maybe this is depending on what your compiler does? I think I did > not really consider this issue too deeply when writing the alignment > support :( From what I remember, nothing is well defined in DWARF regarding non-8-bit-bytes. In the past, I have contributed fixes for such architectures based on how things work with our (Ericsson) internal compiler, and nobody complained so far. There is a BoF at Cauldron though to talk about how to make the non-8-bit-bytes support more "official" and testable [1], if you're interested! Our compiler doesn't emit DW_AT_alignment AFAIK, so I don't know what it would emit. But it would make sense if it was in addressable memory units, just like type sizes. > Another possible issue is that gdbtypes.c:type_align uses TYPE_LENGTH > in > one spot but I suppose it ought to use type_length_units if this patch > goes in. This use seems related to C++, and our compiler is C only, so I can't test that. But it would make sense, I can include that change if you prefer. Simon [1] https://gcc.gnu.org/wiki/cauldron2018#Non-8-bit-byte_architecture_support_BoF
>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
Simon> This use seems related to C++, and our compiler is C only, so I can't
Simon> test that. But it would make sense, I can include that change if you
Simon> prefer.
Yeah, I think it would be best to either change both or change neither
(and update the comment).
Tom
diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c index 76bc16f..a65f01f 100644 --- a/gdb/arch-utils.c +++ b/gdb/arch-utils.c @@ -994,7 +994,7 @@ default_in_indirect_branch_thunk (gdbarch *gdbarch, CORE_ADDR pc) ULONGEST default_type_align (struct gdbarch *gdbarch, struct type *type) { - return TYPE_LENGTH (check_typedef (type)); + return type_length_units (check_typedef (type)); } void