Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Jun 2018 16:21:56 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Bryan Drewery <bdrewery@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r335746 - head/bin/sh
Message-ID:  <20180628153835.J1605@besplex.bde.org>
In-Reply-To: <201806272136.w5RLanc3016284@repo.freebsd.org>
References:  <201806272136.w5RLanc3016284@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Jun 2018, Bryan Drewery wrote:

> Log:
>  Stop building intermediate .o files.
>
>  These are not used to link the final tool anymore.  At some point in the past
>  the suffix rules changed to not link these in.  The original reason for this in
>  r19176 is unclear but seems to be related to mkdep.  The .depend handling is
>  still broken here as it is for all build tool patterns like this.

It was to give reproducible builds.  The default .c rule still causes all
compilers to build a temporary .o file in /tmp (or $TMPDIR).  aout put the
name of the object file in the executable.  This is useful for debugging,
but is broken in elf.  Even compiling with -g doesn't keep the names of
object files.

I don't remember needing to fix this for normal programs.  bsd.prog.mk
never used the default .c rule AFAIR.  This is partly so that mkdep works/
worked.  It only directly generates/generated dependencies associated with
the .c.o rule.

Example of aout nm -n output:

XX 00001020 F /usr/lib/scrt0.o

File name symbol.

XX 00001020 T start
XX 00001090 F /var/tmp/cc0189221.o

This one from building with cc -o foo foo.c.

XX 00001090 t ___gnu_compiled_c
XX 00001090 t gcc2_compiled.
XX 0000109c T _main
XX 00001140 T ___do_global_dtors
XX 00001140 F __main.o
XX 00001168 T ___do_global_ctors
XX 000011c0 T ___main

End of main program/object file.

XX 000011e0 T _atexit
XX 000011e0 F _exit.o
XX 000011e0 F atexit.o
XX 00001250 T _wait
XX 00001250 F wait.o
XX ...

There is an F symbol for every library file linked.  This is most useful
for determining where the functions came from, especially without full
debugging symbols.

The F symbols are badly sorted (by name after number), so they are
often after the first function name in each file, especially for library
functions whose name starts with an underscore.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180628153835.J1605>