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>