From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 7C413388A01C for ; Thu, 2 Apr 2020 14:18:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7C413388A01C Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 032EHnBo022374 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Apr 2020 10:17:54 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 032EHnBo022374 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A68671E581; Thu, 2 Apr 2020 10:17:49 -0400 (EDT) Subject: Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries To: Simon Marchi , Pedro Alves , 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:17:48 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 2 Apr 2020 14:17:49 +0000 X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, 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:18:01 -0000 On 2020-04-02 10:08 a.m., Simon Marchi wrote: > 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. Scratch that again. I now realized that bfd_get_section_contents uses a user-provided buffer, unlike bfd_get_full_section_contents. I am not sure yet what I'm going to use. Simon