From owner-freebsd-current Fri Apr 25 10:28:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA28741 for current-outgoing; Fri, 25 Apr 1997 10:28:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA28719; Fri, 25 Apr 1997 10:27:54 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03675; Fri, 25 Apr 1997 10:24:27 -0700 From: Terry Lambert Message-Id: <199704251724.KAA03675@phaeton.artisoft.com> Subject: Re: Minor fix to ld To: dfr@nlsystems.com (Doug Rabson) Date: Fri, 25 Apr 1997 10:24:27 -0700 (MST) Cc: terry@lambert.org, jdp@freebsd.org, current@freebsd.org In-Reply-To: from "Doug Rabson" at Apr 25, 97 06:04:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > While I was writing my new kernel linker, I noticed that the > > > relocation_info structures for the members of linker sets had r_length set > > > to zero (indicating byte sized relocations) when the objects being > > > relocated were 32bit. The code in ld.so has a hack (see the definition of > > > REL_SIZE in ld/i386/md.c) to work around this. It would be nice to have > > > correct relocations though and I think this patch does the job: > > > > Raising the object compatability red flag... > > Since it only appears to happen for shared libraries and since ld.so has a > hack to make it completely ignore the r_length field, I am not too worried > about object compatability... OK; provisionally withdrawn (pending an answer to John's question about how you are making it happen...). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.