From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by sourceware.org (Postfix) with ESMTPS id 87CC1383A37F for ; Thu, 21 Jul 2022 18:38:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 87CC1383A37F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f42.google.com with SMTP id z13so3463538wro.13 for ; Thu, 21 Jul 2022 11:38:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ok1TSTTYX0rMf0XscnhLZxIPGdZiTl6iOFflSPWmMdk=; b=mHY1ZundtvzgenrKgM3ib9scTD61XhuNptPoQJnChmwhKnC4i1zsIU344qPq6u/HyY XU2Tpw5B/G4GV+ieIK5kL/ddxIscUh2Xf10lwWIhRw4DVXR4ALp8eZQHJHQUHQ9gSMAl HnSy1KaWLWqMFkzTAizvr3rLcD6YJaafv+/khhFzrIRMLcmazxvnMuMmSoVq4GrUKdyT qo2+tYnsabFzOdokZkQ29wjTqgfEX+ne5fXgY0ia7t3QfIvib9EmEs00I5vXca6oF6P6 S4Dtmqx9xbWS1xdqfyzLIHKIoHKUxbOdf+/1XxWyt5Xy3+OXG7Xp2uK/vCFZ1yDr0QHE 9xzg== X-Gm-Message-State: AJIora+V4SbnD4Pye6mhB4YTsKc8z+rlCPsxaSrVGAS9UJDoPB+UxXXg 1msVG6Zy2QLgQPdzyg5PtygAZpLwKPk= X-Google-Smtp-Source: AGRyM1vx0VERCrXu6pfp6VpoDPGJdUFYH8sGVZ0fkOttxqv9pIZZuoNWRwMZ0AqPs7plYnA5sp/yTw== X-Received: by 2002:adf:f04e:0:b0:21e:48df:a13d with SMTP id t14-20020adff04e000000b0021e48dfa13dmr7771302wro.278.1658428736036; Thu, 21 Jul 2022 11:38:56 -0700 (PDT) Received: from ?IPv6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id p2-20020a056000018200b0021e2ae4014fsm824739wrx.35.2022.07.21.11.38.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jul 2022 11:38:54 -0700 (PDT) Subject: Re: [PATCH 1/3] struct packed: Use gcc_struct on Windows To: Eli Zaretskii Cc: gdb-patches@sourceware.org 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> <834jzamiaw.fsf@gnu.org> From: Pedro Alves Message-ID: Date: Thu, 21 Jul 2022 19:38:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <834jzamiaw.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2022 18:39:00 -0000 On 2022-07-21 7:28 p.m., Eli Zaretskii wrote: >> 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? Well, we use bit fields in structs that need to be as small as possible. But using bit fields is problematic in cases that lead to data races. Instead of fixing the problem in every stop that might need it, we added struct packed, to abstract it out. Keeping the type as small is possible is part of the point, otherwise we wouldn't have struct packed at all. > 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. > I'm sorry, but that doesn't make sense. This is used in GDB internals. There's no ABI worry here. Every compilation of every C++ file in GDB sees the same struct packed definition. It must, otherwise, it would be a C++ ODR violation, meaning we'd have an invalid C++ program. Please stop worrying about ABI compatibility here. It's not relevant here.