From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67629 invoked by alias); 24 May 2019 16:19:51 -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 67621 invoked by uid 89); 24 May 2019 16:19:51 -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=golden, awesome, H*f:sk:87o93rb, H*RU:209.85.221.67 X-HELO: mail-wr1-f67.google.com Received: from mail-wr1-f67.google.com (HELO mail-wr1-f67.google.com) (209.85.221.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 May 2019 16:19:50 +0000 Received: by mail-wr1-f67.google.com with SMTP id t4so2333440wrx.7 for ; Fri, 24 May 2019 09:19:49 -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 i25sm3666229wmb.46.2019.05.24.09.19.46 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 09:19:46 -0700 (PDT) Subject: Re: [PATCH 00/19] libctf, and CTF support for objdump and readelf To: Nick Alcock References: <20190430225706.159422-1-nick.alcock@oracle.com> <8736lvwr9p.fsf@esperi.org.uk> <3ce5d56c-8cb1-7d66-f3aa-53e53050baf9@redhat.com> <87o93rbzz8.fsf@esperi.org.uk> Cc: Joseph Myers , binutils@sourceware.org From: Pedro Alves Message-ID: <2ee54d46-0657-6601-ca69-e2aa447085f4@redhat.com> Date: Fri, 24 May 2019 16:19: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: <87o93rbzz8.fsf@esperi.org.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00348.txt.bz2 On 5/24/19 5:04 PM, Nick Alcock wrote: > On 24 May 2019, Pedro Alves spake thusly: >> 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? > > My v2 posting (already out) and v3 (to be posted today, with a > bfdization layer that actually works and a bunch of interface changes to > make it more useful, and an example use in objdump) appear in my testing > to work on mingw, at least. I think that's a non-ELF-capable host. Yes, mingw/Windows uses COFF/PE, not ELF. > > Avoiding relying on host ELF headers is also important because the ELF > header I was unthinkingly relying on isn't portable outside glibc on > Linux and perhaps Solaris, and that's definitely not portable enough. > > (We do still *need* a few lines of stuff from ELF headers, because the > low-level symbol lookup parts of libctf cannot rely on having a bfd > available, so we have to do symbol walkiing by hand -- but we don't need > the host to provide those few lines, and we do use BFD to get section > content etc when possible now.) Awesome. Sorry, I'm way behind on the lists. If everything works in a cross endianness setting too (e.g., big endian host x little endian target) then you're golden. :-) Thanks, Pedro Alves