Date: Sat, 28 Oct 1995 02:10:02 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Peter Wemm <peter@freebsd.org> Cc: CVS-commiters@freebsd.org, cvs-usrbin@freebsd.org Subject: Re: cvs commit: src/usr.bin/symorder symorder.c Message-ID: <1970.814842602@critter.tfs.com> In-Reply-To: Your message of "Sat, 28 Oct 1995 05:27:21 MST." <199510281227.FAA08026@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> peter 95/10/28 05:27:21 > > Modified: usr.bin/symorder symorder.c > Log: > symorder appears to have been designed to run on executable files > only, as it payes no attention to the relocation table (which > references the symbols). > > As a result, running "symorder -c" to clean up the visibility of a LKM > ".o" file (as is done in the new bsd.kmod.mk) totally screws up the > relocation table, making the LKM file unloadable. (ld: bogus > relocation record) Darn, I should have thought of that. > This is a pretty crude fix - I've changed symorder so that when > running in "cleanup" mode, it disables the reordering which was > screwing up the relocation table. I'm sure there is a better fix, but > I didn't have the energy. Feel free to fix this hack, probably by > renumbering the symbol indexes in the relocation table. This is perfectly sensible. The order of symbols in a .o is completely insignificant. Thanks Peter! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1970.814842602>