From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id C6A3D3858025 for ; Tue, 20 Apr 2021 18:01:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C6A3D3858025 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 11202340F10; Tue, 20 Apr 2021 18:01:13 +0000 (UTC) Date: Tue, 20 Apr 2021 14:01:13 -0400 From: Mike Frysinger To: Peng Yu Cc: libc-help Subject: Re: Best reference for understanding ELF format Message-ID: Mail-Followup-To: Peng Yu , libc-help References: <20210419072902.GB9028@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 18:01:17 -0000 On 20 Apr 2021 10:12, Peng Yu via Libc-help wrote: > On 4/20/21, Mike Frysinger wrote: > > On 20 Apr 2021 08:40, Peng Yu via Libc-help wrote: > >> On 4/20/21, Mike Frysinger wrote: > >> > On 19 Apr 2021 20:58, Peng Yu via Libc-help wrote: > >> >> I found this book is quite outdated. It does not explain the current > >> >> gcc and clang. > >> > > >> > gcc & clang don't produce ELFs. > >> > >> Then what produces ELFs? gcc/clang output files in ELFs. I don't > >> understand what you mean here. > > > > that is incorrect. gcc & clang are compiler drivers & language frontends. > > they produce assembly for the assembler (which is not part of gcc or clang) > > which creates object files for the linker (which is not part of gcc or > > clang) > > which is turned into the final ELF image (e.g. program or library). > > People don't usually directly call ld to generate object, executable > or shared library files. you might not, but you are not all people. glibc def invokes it directly. > Instead, gcc/clang are called. So there is nothing wrong to say those > files are produced by gcc/clang, at least at a superficially level. > You can say that gcc/clang don't directly produce the ELF files. > Nevertheless, this doesn't add too much to the topic of this thread. you simultaneously claim you want in-depth detail for how ELFs work and how they're produced, and you don't want to understand how the toolchains work. this is like saying you want to know how the sausage is made, but you don't want to hear about the cows being slaughtered & ground up, you just want to eat the hotdog. toolchains have well segmented duties spread between projects. if you were to go ask the gcc folks about ELF relocations, they'd (correctly) tell you you're at the wrong place: you want to go ask the binutils projects instead as they produce the assembler & linker & related tools. > >> Please provide useful information instead of nonsense like this. > > > > you've been given so much already, and yet you balk at it. > > I've already give justifications why they don't satisfy the three > requirements. If there are no such resources, just say so. Don't > pretend there is one. sounds good: everything you want wrapped up in a bow doesn't exist. feel free to write it yourself and then get it published on amazon. -mike