From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28272 invoked by alias); 24 May 2019 08:57:21 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 28264 invoked by uid 89); 24 May 2019 08:57:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=targeting X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 May 2019 08:57:20 +0000 Received: by mail-wm1-f68.google.com with SMTP id e19so1421220wme.1 for ; Fri, 24 May 2019 01:57:20 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4eeb:42ff:feef:f164? ([2001:8a0:f913:f700:4eeb:42ff:feef:f164]) by smtp.gmail.com with ESMTPSA id y132sm2537353wmd.35.2019.05.24.01.57.17 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 01:57:17 -0700 (PDT) Subject: Re: [PATCH 00/19] libctf, and CTF support for objdump and readelf To: Nick Alcock , Joseph Myers References: <20190430225706.159422-1-nick.alcock@oracle.com> <8736lvwr9p.fsf@esperi.org.uk> Cc: binutils@sourceware.org From: Pedro Alves Message-ID: <3ce5d56c-8cb1-7d66-f3aa-53e53050baf9@redhat.com> Date: Fri, 24 May 2019 08:57:00 -0000 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: <8736lvwr9p.fsf@esperi.org.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00337.txt.bz2 On 5/3/19 3:23 PM, Nick Alcock wrote: > >> * Use of elf.h. Non-ELF hosts won't have such a header. You should be >> working with the existing include/elf/*.h definitions of ELF data >> structures in binutils. > This is all for build hosts that aren't ELF, right? I don't think we can > reasonably expect ctf_open() or ctf_fdopen() to work for anything but > raw CTF files on non-ELF hosts, given that by their very nature these > functions are getting CTF data out of ELF sections, and non-ELF formats > don't necessarily support anything like the named section concept ELF > has got at all. > > The only other ELF-specificity is looking up types by symbol table > offset. Again, I don't know enough about non-ELF platforms to know if > this concept is even practical there, which would mean the data object > and function info sections would be empty on such hosts, and > ctf_lookup_by_symbol(), ctf_func_info() and ctf_func_args() would not > function or would be excluded from the set of exported symbols entirely. > > This would reduce libctf's utility, but not eliminate it: external > systems can still look up types by name or CTF type ID even if they > can't do it by symbol. Even if you only want to support CTF on ELF containers, a cross binutils build hosted on e.g., Windows, targeting an ELF port, should still be able to use the CTF. That's why it is important to not rely on host headers for ELF definitions. It wasn't clear to me from your remarks above whether the cross use case is considered? Thanks, Pedro Alves