From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eliz@gnu.org>
Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92])
 by sourceware.org (Postfix) with ESMTPS id 9C1D3383A37A
 for <gdb-patches@sourceware.org>; 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 <eliz@gnu.org>)
 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 <eliz@gnu.org>)
 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>
From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@palves.net>
Cc: gdb-patches@sourceware.org
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>
 <a5f58990-3586-ebd1-2998-f4aec7b935db@palves.net> <83a692mkj7.fsf@gnu.org>
 <0bcdc048-ae9c-2f54-2450-66c13a62267c@palves.net>
X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF,
 RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS,
 TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gdb-patches@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2022 18:30:58 -0000

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 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 <pedro@palves.net>
> 
> >> 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.