From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vapier@gentoo.org>
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
 by sourceware.org (Postfix) with ESMTP id 1B7163850402
 for <libc-help@sourceware.org>; Tue, 20 Apr 2021 17:55:26 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1B7163850402
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 325E2335DB8;
 Tue, 20 Apr 2021 17:55:25 +0000 (UTC)
Date: Tue, 20 Apr 2021 13:55:24 -0400
From: Mike Frysinger <vapier@gentoo.org>
To: noloader@gmail.com
Cc: libc-help <libc-help@sourceware.org>
Subject: Re: Best reference for understanding ELF format
Message-ID: <YH8VjHiUQbQkG8vb@vapier>
Mail-Followup-To: noloader@gmail.com, libc-help <libc-help@sourceware.org>
References: <CABrM6wkDtmBSf6=3BO52TGZVHUrgoeEasaaPGjXpyx31O3MTNQ@mail.gmail.com>
 <YHkIwxqM8FjVe4wR@vapier>
 <CABrM6w=+4UVf0h7ZyOPBE6rxEMoL5+eLrm6Nu7whPGPZhho+jw@mail.gmail.com>
 <20210419072902.GB9028@arm.com>
 <CABrM6wmsJK_Kit-0_ztWHTjaLj=3c6OZ3W-kdFcTOr5B=0QVYQ@mail.gmail.com>
 <YH7UxO8OZLWAljgc@vapier>
 <CABrM6wn4R0MG-rFF-gvJCYi-pt-mCc=RE9RsCYG2pkKNu6iDCw@mail.gmail.com>
 <YH7iv67L1p6bYIcu@vapier>
 <CABrM6wmXAu8ff=yOgGZzcG8THjuyTkRToSXNQ+AJ-Txg5hq72w@mail.gmail.com>
 <CAH8yC8=5f2vbP4NtHs6Zt2tTQnJG60z2Pdbep4QZ404iiQvr4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAH8yC8=5f2vbP4NtHs6Zt2tTQnJG60z2Pdbep4QZ404iiQvr4w@mail.gmail.com>
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 <libc-help.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-help/>
List-Help: <mailto:libc-help-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-help>,
 <mailto:libc-help-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 17:55:28 -0000

On 20 Apr 2021 12:39, 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.

the assembler is a distinct project from clang.  they're both under the llvm
umbrella, but still distinct.  that clang has an option to statically link a
tool into itself rather than invoke it via fork+exec+pipes is a bit immaterial
to the overall division of duties.  i could statically link a C library into
clang too, but i wouldn't claim that clang provides a C library.
-mike