From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id E2216388A01B for ; Thu, 2 Apr 2020 14:08:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E2216388A01B Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 9438D27CEA6; Thu, 2 Apr 2020 10:08:34 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wOxzIBd1-OtP; Thu, 2 Apr 2020 10:08:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 6B58527CEA5; Thu, 2 Apr 2020 10:08:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 6B58527CEA5 X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iKgaqpGjgc6z; Thu, 2 Apr 2020 10:08:34 -0400 (EDT) Received: from [10.0.0.11] (unknown [192.222.164.54]) by mail.efficios.com (Postfix) with ESMTPSA id 35A0C27CCCF; Thu, 2 Apr 2020 10:08:33 -0400 (EDT) Subject: Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries To: Pedro Alves , Simon Marchi , gdb-patches@sourceware.org Cc: Jon Turney References: <20200316170845.184386-1-simon.marchi@polymtl.ca> <20200316170845.184386-7-simon.marchi@polymtl.ca> <0b76517a-f6dd-0aa8-17fb-ce5a9accbf42@redhat.com> <9e593882-37cd-c730-9cde-75af5df820c4@efficios.com> <673bf7c4-4ff2-fb63-f37a-4da961edac68@redhat.com> From: Simon Marchi Message-ID: Date: Thu, 2 Apr 2020 10:08:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <673bf7c4-4ff2-fb63-f37a-4da961edac68@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 02 Apr 2020 14:08:36 -0000 On 2020-04-02 10:03 a.m., Pedro Alves wrote: > On 4/2/20 3:01 PM, Simon Marchi wrote: >> On 2020-04-02 9:56 a.m., Pedro Alves wrote: >>> On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote: >>>> However, when BFD maps the file/section data in memory for GDB to read, is that mapping >>>> guaranteed to be sufficiently aligned as well? >>> >>> I think so. If bfd heap allocates, then memory will be aligned to the word size at >>> least. If bfd mmaps, then memory will be aligned to page size. And then if the >>> data structures are aligned, we should be good. >> >> Following this message from Tom [1], I'm going to change the code to use >> bfd_get_full_section_contents and store the data into a pre-allocated gdb::byte_vector. >> Does that change anything? > > I don't think it does. Err, just to make a correction: bfd_get_full_section_contents allocates the memory itself and returns a pointer, so I won't use gdb::byte_vector. Since BFD does the allocation itself, then we can say it's responsible for returning a properly aligned buffer. Simon