public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Peng Yu <pengyu.ut@gmail.com>
Cc: libc-help <libc-help@sourceware.org>
Subject: Re: Best reference for understanding ELF format
Date: Tue, 20 Apr 2021 14:01:13 -0400	[thread overview]
Message-ID: <YH8W6SQ1wSxFUJCQ@vapier> (raw)
In-Reply-To: <CABrM6wmXAu8ff=yOgGZzcG8THjuyTkRToSXNQ+AJ-Txg5hq72w@mail.gmail.com>

On 20 Apr 2021 10:12, Peng Yu via Libc-help wrote:
> On 4/20/21, Mike Frysinger <vapier@gentoo.org> wrote:
> > On 20 Apr 2021 08:40, Peng Yu via Libc-help wrote:
> >> On 4/20/21, Mike Frysinger <vapier@gentoo.org> 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

  parent reply	other threads:[~2021-04-20 18:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  3:38 Peng Yu
2021-04-16  3:47 ` Mike Frysinger
2021-04-17 12:31   ` Peng Yu
2021-04-19  7:29     ` Szabolcs Nagy
2021-04-19  7:53       ` Florian Weimer
2021-04-20  1:58       ` Peng Yu
2021-04-20  7:08         ` tomas
2021-04-20 13:19         ` Mike Frysinger
2021-04-20 13:40           ` Peng Yu
2021-04-20 14:18             ` Mike Frysinger
2021-04-20 15:12               ` Peng Yu
2021-04-20 16:39                 ` Jeffrey Walton
2021-04-20 16:51                   ` Carlos O'Donell
2021-04-21  3:19                     ` Peng Yu
2021-04-20 17:55                   ` Mike Frysinger
2021-04-20 18:01                 ` Mike Frysinger [this message]
2021-04-20  8:14     ` Jeffrey Walton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YH8W6SQ1wSxFUJCQ@vapier \
    --to=vapier@gentoo.org \
    --cc=libc-help@sourceware.org \
    --cc=pengyu.ut@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).