Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Aug 2004 09:15:31 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        "David O'Brien" <obrien@FreeBSD.org>
Cc:        current@FreeBSD.org
Subject:   New ld(1) changed behavior (was: Re: bin/70392: NO_DYNAMICROOT + savecore -z dumps core)
Message-ID:  <20040813061531.GC52735@ip.net.ua>
In-Reply-To: <20040813022719.MGWH14383.out010.verizon.net@pool-70-17-33-167.pskn.east.verizon.net>
References:  <20040813022719.MGWH14383.out010.verizon.net@pool-70-17-33-167.pskn.east.verizon.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--UPT3ojh+0CqEDtpF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 12, 2004 at 09:27:19PM -0500, Skip Ford wrote:
>=20
> Statically linking savecore (NO_DYNAMICROOT) causes conflict:
>=20
> /usr/bin/ld: Warning: size of symbol `compress' changed from 4 in savecor=
e.o to 27 in /usr/lib/libz.a(compress.o)
> /usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in /u=
sr/lib/libz.a(compress.o)
>=20
> 'compress' is an integer in savecore.o and a function in compress.o.
> The resulting binary dumps core when run with compression (-z).
>=20
> Not sure if the conflict is valid or a toolchain problem, but renaming
> the int works around the problem.
>=20
Another option is to staticize this variable, but I'm not yet
sure if this new behavior of ld(1) is correct.  It doesn't
exhibit in 4.x, with the same situation regarding the "compress"
variable/function.  I was looking for a possible explanation of
why this could be happening, and I hope I found why, but I'd
need a confirmation from those more familiar with the linker
rules.  Here's the hopefully relevant information from ld.info:

    `int i;'
          A common symbol.  If there are only (one or more) common
          symbols for a variable, it goes in the uninitialized data
          area of the output file.  The linker merges multiple common
          symbols for the same variable into a single symbol.  If they
          are of different sizes, it picks the largest size.  The
          linker turns a common symbol into a declaration, if there is
          a definition of the same variable.

So if I interpret this correctly, it means that linker should
convert a common from savecore.o to a reference to "compress"
(a definition) from libz.a.  But in 4.x, when you statially
link savecore, it puts "compress" from savecore.o into the BSS
section:

: # make -DNOMAN -DNOSHARED
: Warning: Object directory not changed from original /usr/src/sbin/savecore
: cc -O -pipe     -c savecore.c
: cc -O -pipe      -static -o savecore savecore.o -lz
: # nm savecore.o /usr/lib/libz.a savecore |grep -w compress
: 00000004 C compress
: compress.o:
: 000000a0 T compress
: 081754e0 B compress

In 5.x, a linker does this (for the reference):

: # make -DNOMAN -DNOSHARED
: Warning: Object directory not changed from original /usr/src/sbin/savecore
: cc -O -pipe -march=3Dpentiumpro -Wsystem-headers -Werror -Wall -Wno-forma=
t-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-=
type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninit=
ialized -c savecore.c
: cc -O -pipe -march=3Dpentiumpro -Wsystem-headers -Werror -Wall -Wno-forma=
t-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-=
type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninit=
ialized  -static -o savecore savecore.o -lz
: /usr/bin/ld: Warning: size of symbol `compress' changed from 4 in savecor=
e.o to 48 in /usr/lib/libz.a(compress.o)
: /usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in /u=
sr/lib/libz.a(compress.o)
: # nm savecore.o /usr/lib/libz.a savecore |grep -w compress
: 00000004 C compress
: compress.o:
: 000000c0 T compress
: 08051d60 T compress

If my assumptions are correct, then certainly, staticizing the
"compress" (and other now common globals in savecore.c) would
be a right solution.  Rebuilding the world with -DNOSHARED
globally is also recommended, to find other possible problems.


Cheers,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer

--UPT3ojh+0CqEDtpF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFBHFyDqRfpzJluFF4RAp7bAJ92bgzhZdU1lEUo7gHxmjoocyqB1QCfcMjq
6Om5fIiDAeOM9sGIi0YKRzw=
=uM8u
-----END PGP SIGNATURE-----

--UPT3ojh+0CqEDtpF--



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