From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id C2342388A00C for ; Thu, 2 Apr 2020 13:57:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C2342388A00C Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-67-VoYSVZV6OzC4K38ySswUsg-1; Thu, 02 Apr 2020 09:56:58 -0400 X-MC-Unique: VoYSVZV6OzC4K38ySswUsg-1 Received: by mail-ed1-f70.google.com with SMTP id n15so2780615edq.6 for ; Thu, 02 Apr 2020 06:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k/nwb2N/TcyjHP2zM8YsR0bc/fh4qxt/S+0H3H6SQGY=; b=EVibJGdamJnQ8hgagyNoA30Ey28VEG9flaKac7V/LjTxlqMAuMKOi/yinTKXAmxSzW uMZp9M36vloRnbmzu8bBRatu3RhZl4KHtGVnYiUPquCOcAdFcBTEuB97+CQALeQ2+9ce EC3CUNjs6OHxi8kkbPlt7HsiQTXnqC2kftUoXmZh8wmxMGc8PjxAkDoba8EwllK9OZar OQ3YhXG92e5X6sxV58SgTqj0wqygGulmnolnub3fatoPvgIsPb0/OIgmbWIp+vOK0j9+ vbh2eK6GfT9lemZnzEcw/0p9UCi8TwfKbtIZjBy8yPg61ji/8wn5KSl8veYgisbpyNIP 84QA== X-Gm-Message-State: AGi0Pub4lfafgmrZLIP+Bz4a1n7DTrzxjRPsZE0arJjc9nbUEHklEWo6 iFsBaXTCy2WVW0u3DhfaSaJ1StlqzJmSQb3xKMiBVJsgthBhSV3qaXdpE7i5Jni9N2R0lQDWhgo QjgpZLlfdCJ91bN5Mu3h9/w== X-Received: by 2002:a50:c850:: with SMTP id s16mr3056501edg.90.1585835817213; Thu, 02 Apr 2020 06:56:57 -0700 (PDT) X-Google-Smtp-Source: APiQypLKC8c9+NNHmMhJ0PZkWnLIK3Da9VQ57oWZ3QbM+9Wn/j22VMhI9/imalV5gQa/InMaqBno5A== X-Received: by 2002:a50:c850:: with SMTP id s16mr3056486edg.90.1585835816914; Thu, 02 Apr 2020 06:56:56 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id s10sm1116741ejf.88.2020.04.02.06.56.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 06:56:55 -0700 (PDT) Subject: Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries To: Simon Marchi , gdb-patches@sourceware.org References: <20200316170845.184386-1-simon.marchi@polymtl.ca> <20200316170845.184386-7-simon.marchi@polymtl.ca> <0b76517a-f6dd-0aa8-17fb-ce5a9accbf42@redhat.com> Cc: Simon Marchi , Jon Turney From: Pedro Alves Message-ID: Date: Thu, 2 Apr 2020 14:56:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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 13:57:03 -0000 On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote: > On 2020-04-01 5:36 p.m., Pedro Alves wrote: >> On 3/16/20 5:08 PM, Simon Marchi via Gdb-patches wrote: >>> +bool >>> +is_linked_with_cygwin_dll (bfd *abfd) >>> +{ >>> + /* The list of DLLs a PE is linked to is in the .idata section. See: >>> + >>> + https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section >>> + */ >>> + asection *idata_section = bfd_get_section_by_name (abfd, ".idata"); >>> + if (idata_section == nullptr) >>> + return false; >>> + >>> + /* Find the virtual address of the .idata section. We must subtract this >>> + from the RVAs (relative virtual addresses) to obtain an offset in the >>> + section. */ >>> + bfd_vma idata_addr = >>> + pe_data (abfd)->pe_opthdr.DataDirectory[PE_IMPORT_TABLE].VirtualAddress; >> >> = on next line. Unless it doesn't fit, then let's ignore. > > Yes it fits. >>> + >>> + /* Map the section's data. */ >>> + bfd_size_type idata_size; >>> + const gdb_byte *const idata_contents >>> + = gdb_bfd_map_section (idata_section, &idata_size); >>> + if (idata_contents == nullptr) >>> + { >>> + warning (_("Failed to get content of .idata section.")); >>> + return false; >>> + } >>> + >>> + const gdb_byte *iter = idata_contents; >>> + const gdb_byte *end = idata_contents + idata_size; >>> + const pe_import_directory_entry null_dir_entry = { 0 }; >>> + >>> + /* Iterate through all directory entries. */ >>> + while (true) >>> + { >>> + /* Is there enough space left in the section for another entry? */ >>> + if (iter + sizeof (pe_import_directory_entry) > end) >>> + { >>> + warning (_("Failed to parse .idata section: unexpected end of " >>> + ".idata section.")); >>> + break; >>> + } >>> + >>> + pe_import_directory_entry *dir_entry = (pe_import_directory_entry *) iter; >> >> Is 'iter' guaranteed to be sufficiently aligned? Recall that this is >> host-independent code. > > I admit I haven't thought about that. Within the PE file, the data of sections is > aligned on at least 512 bytes. See "FileAlignment" here: > > https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#optional-header-windows-specific-fields-image-only Ah, good. Sounds like the data structures were designed for memory mapping. Which isn't that surprising. > > 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. Thanks, Pedro Alves