svn commit: r352623 - in head/sys: amd64/amd64 kern

[Warner Losh]

On Mon, Sep 23, 2019, 10:28 PM Mark Johnston <markj at 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 <markj at 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 <markj at 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

>