28 Nov
2017
28 Nov
'17
8:09 p.m.
On Tue, Nov 28, 2017 at 1:41 PM, Warner Losh <imp(a)bsdimp.com> wrote:
There is, perhaps, some debugging value in embedding ident strings in
object code: one can see which versions of which sources were used to
construct a given binary. I suspect the incremental value of such things is
diminishing with faster computers and fast (relatively) compilation; it's
easier to simply construct a binary from known versions of source files
than to extrapolate versions of files from a known binary. I can't think of
a great use case for embedding copyright data into an object file, however.
- Dan C.
On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd(a)gmail.com> wrote:
I think perhaps we are talking past one another.
You had written '(because main can't return)' and it seems (if you'll
forgive me putting words in your mouth, so to speak) that you either
intended to say that _exit() can't return, or that main can't return *in
this context* (because it invoked exit). Exit obviously cannot return, as
you and I both explicitly mentioned, but I was addressing the comment that
*main* cannot return. main() absolutely can return, just not _here_.
This is much smaller than the binary for the assembler program I posted for
On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh
<imp(a)bsdimp.com> wrote:
Ture but completely irrelevant. If exit happens, the process is done. main
isn't going to return because control never returns back to main. That's
what makes the messages completely bogus. Execution simply stops. _exit()
doesn't cause main() to return to _start(), the process stops executing at
that point.
Ah, the tyranny of static analysis tools... _exit(0) should be marked
such that the tools know it does not return. This means the /*NOTREACHED*/
isn't needed. And since there's no real exit path out of main, the return
(0) is equally bogus (because main can't return). Yet lint and other tools
have ushered in this insanity.
Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
is called as this calls the exit system call, which cannot -- by definition
-- return. But main() itself can return to whatever calls it (usually
`start`, I'd imagine). For that matter, I'm not aware of any prohibition
against calling `main()` recursively.
macOS earlier
in this thread: the result there was much larger (but due to
the requirement to have a non-empty data segment in the executable; this
ends up being page-aligned and filled with zeros).
Contrast that with FreeBSD's /usr/bin/true:
Ah yes, I read the source, but hadn't checked the final binary... Most of
the data seems to be other things... It used to get the copyright data
with gcc a long time ago...
-r-xr-xr-x 1 root wheel 4624 Nov 20 11:56
/usr/bin/true
text data bss dec hex filename
1540 481 8 2029 0x7ed /usr/bin/true
which is little more than return(0), but also has a fair amount of
copyright and SCCS data.
Is the copyright data actually present in the object file? I see some RCS
$Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
/usr/bin/true on my system.