From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id C82423846457 for ; Wed, 21 Apr 2021 03:19:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C82423846457 Received: by mail-il1-x132.google.com with SMTP id y10so11927064ilv.0 for ; Tue, 20 Apr 2021 20:19:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q/Ta8IklrHcJvJ12ZO5KeOzEtmrzwq+zlgI3lQOwFAA=; b=Xy38Y93j6ghElI2pu8f7N5G3U+GHQuYaULe982zg3ODxxHxss8RaG0Ft9yknVGjbPc gyZUQ8ncibVeKvZFw69udFaP+UB9lU5A50oM8y4ARxohTmD1LNKUhQF5lT+fmwOut/t2 XK657Px8kxB7z7BUKmJyDXt6F4k65QyJ0sz74hmlu5aQotoZygBJJxt4FRex9HbTnRlm ajwVzzv4TB64/fVakIyP2fZcnqitTLAYG0XXbvFY1sypgnN01Ofe94wElwfjV3fZhS7m uoOfy8p8RJsMCBTxJNkJ84tDYI5lwfEg5pvS0P2YbK8XorGN/BIWXXLCop64Yvjgksmm AC8g== X-Gm-Message-State: AOAM533/nF9yyBbC8rUiShEuMu0q5uBgeFJE1DcSfxSsKvgytsrRaCij NAc2spH+oDFWZX5VD4pU3ckMXdjUGuv0LWkDeNE= X-Google-Smtp-Source: ABdhPJyshS8Cj5IuUYq5UkS/L7Fblwrhi+vB9RnGkh23SbiSuEmff+fBdpPHlvZEuYxEaUemwyWmUfnQilTJ+tx9biw= X-Received: by 2002:a05:6e02:80b:: with SMTP id u11mr25102934ilm.153.1618975185342; Tue, 20 Apr 2021 20:19:45 -0700 (PDT) MIME-Version: 1.0 References: <20210419072902.GB9028@arm.com> In-Reply-To: From: Peng Yu Date: Tue, 20 Apr 2021 22:19:33 -0500 Message-ID: Subject: Re: Best reference for understanding ELF format To: "Carlos O'Donell" Cc: Jeffrey Walton , libc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: 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: Wed, 21 Apr 2021 03:19:51 -0000 On Tue, Apr 20, 2021 at 11:51 AM Carlos O'Donell wrote: > > On Tue, Apr 20, 2021 at 12:39 PM Jeffrey Walton via Libc-help > wrote: > > > > On Tue, Apr 20, 2021 at 12:29 PM Peng Yu via Libc-help > > wrote: > > > ... > > > People don't usually directly call ld to generate object, executable > > > or shared library files. > > > > > > 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. > > > > I think Clang can produce object files directly. Clang has an > > integrated assembler. > > Conceptually the point is the same though. > > The compiler relies on an assembler and static linker to generate the > object files. > > Whether that assembler is a library and the invocation is a library > call, or it's a secondary process via a pipe, the concept being > discussed is the same. > > The compiler itself (language front end, I think the "front end" is actually the cc1 program which is not exposed to PATH by default for gcc. In my system, it is the following one, which transforms a .c file to a .s file. /usr/lib/gcc/x86_64-linux-gnu/10/cc1 Then the .s file is processed by as, to generate a .o file. Then, the final a.out file is generated from the .o file by ld. The command gcc is just a wrapper of the three programs (cc1/as/ld). The following is a minimal work example that demonstrates this. $ cat main.c #include int main() { puts("Hello World!"); return 0; } $ /usr/lib/gcc/x86_64-linux-gnu/10/cc1 -quiet main.c -o main.s $ as -o main.o main.s $ ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/x86_64-linux-gnu/crtn.o main.o -lc > or driver) doesn't produce > ELF format object files. Technical clarity around these distinctions > helps at a later stage when we're trying to explain other concepts > where the distinction matters or where the distinction is muddled e.g. > LTO, ThinLTO etc. As these (LTO, ThinLTO) specific to the llvm pipeline? -- Regards, Peng