From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8E7+A3ab2WK5LhgAWB0awg (envelope-from ) for ; Thu, 21 Jul 2022 14:31:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 0DF2F1E5EA; Thu, 21 Jul 2022 14:31:18 -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=IDx1XDEC; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 B23031E21F for ; Thu, 21 Jul 2022 14:31:17 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D2DF8383A37A for ; Thu, 21 Jul 2022 18:31:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D2DF8383A37A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658428276; bh=cWVMg9gmSAjwVGUblUYf+DWFCfN0z40pl0aBoYDY6sA=; 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=IDx1XDEC8QGK4yu/ZhVWneC4cwLBITQfWB6hniynsXHcdBB/N/prThZnNtiHYDQFN afK2+NdGDKBZ19rCAH1eI8+rFwMUUuos9qG6dwPd7Axc78801LQgypnyBNytCHKVlR 9JtJZ2ma/8hBZd4l1ET6T2ayGKv3I2Kx3qfjsuGk= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 9C1D3383A37A for ; Thu, 21 Jul 2022 18:30:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C1D3383A37A Received: from fencepost.gnu.org ([2001:470:142:3::e]:56452) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEauk-00011x-JN; Thu, 21 Jul 2022 14:28:46 -0400 Received: from [87.69.77.57] (port=4949 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 1oEauj-0006yE-W3; Thu, 21 Jul 2022 14:28:46 -0400 Date: Thu, 21 Jul 2022 21:28:39 +0300 Message-Id: <834jzamiaw.fsf@gnu.org> To: Pedro Alves In-Reply-To: <0bcdc048-ae9c-2f54-2450-66c13a62267c@palves.net> (message from Pedro Alves on Thu, 21 Jul 2022 19:18:20 +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> <0bcdc048-ae9c-2f54-2450-66c13a62267c@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:18:20 +0100 > > On 2022-07-21 6:40 p.m., Eli Zaretskii wrote: > >> Cc: gdb-patches@sourceware.org > >> From: Pedro Alves > > >> Because without it the struct won't really be packed. > > > > Can you tell why is that necessary? > > Somehow I missed this question. It is necessary because that's the whole > point of "struct packed". To wrap some other type and pack it. We use it > in some size-sensitive structures, to make them are as small as possible. > This is described in the gdbsupport/packed.h header. You mean, this part: /* Each instantiation and full specialization of the packed template defines a type that behaves like a given scalar type, but that has byte alignment, and, may optionally have a smaller size than the given scalar type. This is typically used as alternative to bit-fields (and ENUM_BITFIELD), when the fields must have separate memory locations to avoid data races. */ I don't think I see the rationale here, except "make them as small as possible". Is that the reason? If so, what would happen if the size is somewhat larger? If the only result is less efficient GDB, I'd be happier if we sustained the efficiency hit, but stayed compatible to the ABI.