On Mon, Sep 23, 2019, 10:28 PM Mark Johnston <ma...@freebsd.org> wrote:
> On Mon, Sep 23, 2019 at 10:13:14PM +0200, Warner Losh wrote: > > On Mon, Sep 23, 2019, 9:06 PM Mark Johnston <ma...@freebsd.org> wrote: > > > > > On Mon, Sep 23, 2019 at 11:28:52AM -0700, Conrad Meyer wrote: > > > > Hi Mark, > > > > > > > > On Mon, Sep 23, 2019 at 7:14 AM Mark Johnston <ma...@freebsd.org> > wrote: > > > > > > > > > > Author: markj > > > > > Date: Mon Sep 23 14:14:43 2019 > > > > > New Revision: 352623 > > > > > URL: https://svnweb.freebsd.org/changeset/base/352623 > > > > > > > > > > Log: > > > > > Use elf_relocaddr() when handling R_X86_64_RELATIVE relocations. > > > > > > > > > > This is required for DPCPU and VNET data variable definitions to > > > work when > > > > > KLDs are linked as DSOs. R_X86_64_RELATIVE relocations should > not > > > appear > > > > > in object files, so assert this in elf_relocaddr(). > > > > > > > > Is the goal to eventually link amd64 KLDs as DSOs? I might be > > > > confusing the terminology, but I believe amd64 .ko's today are > > > > unlinked ordinary object files, rather than shared objects. (I > > > > believe they use kern/link_elf_obj.c rather than kern/link_elf.c > > > > today.) > > > > > > > > If so: great! > > > > > > That's right, and that is indeed my goal. At least, I would like to > > > make the option available; with my patch set, it is possible to specify > > > the format at both the per-module and global levels. There are several > > > in-tree modules (some of the HighPoint RAID drivers, if you're curious) > > > that cannot be linked as DSOs because they contain a non-PIC blob, and > > > for now lld refuses to link them into a DSO. > > > > > > > That problem might be better solved by removing the highpount driver > since > > they are old and abandon ware these days. I'm serious here, old stuff > with > > low value getting in the way might be better off in our rearview > mirror... > > Well, there are at least four drivers. I'm not sure which, if any, are > actively used these days, though some of them have gotten vendor updates > in the past several years. In any case, handling the issue involved > adding a single line to each driver's makefile, so I don't feel too > oppressed. > At least 3 of the 4 are so old as to be irrelevant by any standard... and the 4th is teetering on the edge as well. Warner > _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
