From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ud+YBt2Z2WLuLRgAWB0awg (envelope-from ) for ; Thu, 21 Jul 2022 14:24:29 -0400 Received: by simark.ca (Postfix, from userid 112) id 0E3231E5EA; Thu, 21 Jul 2022 14:24:29 -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=vWNWU1uV; 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 8DA2C1E21F for ; Thu, 21 Jul 2022 14:24:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C923F384B0D4 for ; Thu, 21 Jul 2022 18:24:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C923F384B0D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658427865; bh=5aq6ttIv7lgwy+xFUho9AvgoqH5TDMbAmUdI+kO9FiE=; 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=vWNWU1uVEWYv4/mq5FK8pnpuBIfByfqM/C/OvvZFnz3gLuPGyW1ajKd8LoHJLOJBP GGZzrRBVA33GFsHdsxbxGUaBKJqxvKUhIldlRonIV/5UNy6nXz0XOfxQLRpmH5PrgD GVHVLwlzRt6bXmoWcmO/D+bQ1pm8sW12a5RVr8Q4= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 9C214384BC02 for ; Thu, 21 Jul 2022 18:24:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C214384BC02 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56424) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEaqE-0000Ls-27; Thu, 21 Jul 2022 14:24:06 -0400 Received: from [87.69.77.57] (port=4662 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 1oEaqD-0001c4-E7; Thu, 21 Jul 2022 14:24:05 -0400 Date: Thu, 21 Jul 2022 21:23:58 +0300 Message-Id: <835yjqmiip.fsf@gnu.org> To: Pedro Alves In-Reply-To: <7b3aa811-a2a8-3b3f-7a6f-40196e4e6901@palves.net> (message from Pedro Alves on Thu, 21 Jul 2022 19:15:17 +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> <83a692mkj7.fsf@gnu.org> <7b3aa811-a2a8-3b3f-7a6f-40196e4e6901@palves.net> 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 19:15:17 +0100 > > >> 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? > > What other code are you talking about? struct packed is used in GDB's internal > structures. Nothing outside GDB ever sees it. GDB doesn't export a C api. > And if it did, we probably wouldn't use struct packed in exported structures. If this is supposed to be based on our vigilance and manual prevention of exporting it, I think it's fragile and not very reliable. If we forget or miss something, we get a subtly broken build. > >>> 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? Can you answer this question, please? What I'm actually asking is whether there's any alternative which would avoid overriding the defaults in this matter. > > In any case, I'm very uneasy about changes that break ABI > > compatibility between parts of a program. > > But no ABI compatibility is broken. But it could be, even if today it isn't.