From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id NKyCKbGP2WL5KBgAWB0awg (envelope-from ) for ; Thu, 21 Jul 2022 13:41:05 -0400 Received: by simark.ca (Postfix, from userid 112) id 99C0A1E5EA; Thu, 21 Jul 2022 13:41:05 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=KWr4Nqba; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6DEF21E13B for ; Thu, 21 Jul 2022 13:41:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 712AA38582A2 for ; Thu, 21 Jul 2022 17:41:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 712AA38582A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658425261; bh=OnEpmGs+OLK/GOIl4C4C79EE8E4dAOlny+jVyDCnd2U=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KWr4NqbaBYUOvbA2lHytXrhvKenabi/Nu4gbCXSSYL04GQC5Sore8qf+TunhfQStk bv/KmGnTJhh3kNLleXIk1NFa034/om460ARVazCHCQ0kUA3ZOXY5Q7LInX7nyuUmQr gcLUn8u/xk8S1zHe042u/tgcpXnNCBSrP8Qdg7qU= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 206FB3858C56 for ; Thu, 21 Jul 2022 17:40:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 206FB3858C56 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55970) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEaA8-0001xO-5P; Thu, 21 Jul 2022 13:40:36 -0400 Received: from [87.69.77.57] (port=1966 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEaA6-0000A5-Nm; Thu, 21 Jul 2022 13:40:35 -0400 Date: Thu, 21 Jul 2022 20:40:28 +0300 Message-Id: <83a692mkj7.fsf@gnu.org> To: Pedro Alves In-Reply-To: (message from Pedro Alves on Thu, 21 Jul 2022 18:05:55 +0100) Subject: Re: [PATCH 1/3] struct packed: Use gcc_struct on Windows References: <20220721152132.3489524-1-pedro@palves.net> <20220721152132.3489524-2-pedro@palves.net> <83h73amp19.fsf@gnu.org> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Cc: gdb-patches@sourceware.org > From: Pedro Alves > Date: Thu, 21 Jul 2022 18:05:55 +0100 > > On 2022-07-21 5:03 p.m., Eli Zaretskii wrote: > >> From: Pedro Alves > >> Date: Thu, 21 Jul 2022 16:21:30 +0100 > >> > >> The issue is that mingw gcc defaults to "-mms-bitfields", which > >> affects how bitfields are laid out. We can however tell GCC that we > >> want the regular GCC layout instead using attribute gcc_struct. > > > > Is that a good idea? It means the code emitted by GCC for this source > > file will be incompatible with any other library compiled with MinGW > > that GDB uses. So we are risking ABI incompatibilities here. Right? > > > > No. The attribute only changes the layout of that particular structure. And we are 110% sure that structure will never be passed to any other code? > > Can you tell why we must have the regular GCC layout of bitfields > > here? > > Because without it the struct won't really be packed. Can you tell why is that necessary? In any case, I'm very uneasy about changes that break ABI compatibility between parts of a program.