lkml.org 
[lkml]   [2003]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Userspace Test Framework for module loader porting
    On Mon, 13 Jan 2003, Rusty Russell wrote:

    > > I'm also a bit worried about changing module loaders so often. Yeah,
    > > once you switch to a kernel-loader, presumably users won't be
    > > affected, but (kernel-module) developers will be.
    >
    > While ET_DYN modules are a reasonably serious win for ia64 (and
    > probably hppa) (ie. -300 lines or so), they're a minor win for alpha
    > and ppc64 (-100 lines or so), and no real change for arm, i386, ppc,
    > sparc, and sparc64. It's a lose for x86_64 (toolchain fixes, unless
    > they want to use -fPIC for modules), mips and mips64 (major toolchain
    > fixes, unless they want to use -fPIC for modules and stop using r28
    > for current inside modules).

    Hmm, what's the gain from using shared objects as opposed to relocatables
    and why is there any for non-PIC objects at all? After all, the reason
    for using shared objects is to handle shared PIC code, for which
    relocation is indeed easier to perform -- you only need to relocate the
    GOT and data sections, the latter being rare and with a limited number of
    relocation types. For non-PIC shared objects the GOT and data sections
    still need to be relocated, but text sections do as well, introducting all
    the relocation types back. The end result is almost no different from
    operating on relocatables.

    From the MIPS pov, adding non-PIC support to tools would mean defining
    R_MIPS_26 (with some effort these could mostly be avoided for modules less
    than 128kB in size), R_MIPS_32, R_MIPS_HI16 and R_MIPS_LO16 for shared
    objects. Additionally R_MIPS_64, R_MIPS_HIGHEST and R_MIPS_HIGHER for
    MIPS64. A few ABI issues should be resolved, specifically how to create
    the GOT and the dynamic section, possibly others, as the MIPS ABI
    supplement doesn't define handling of non-PIC shared objects. An
    implementation for the BFD, though likely tiresome, shouldn't be difficult
    in principle, but tricky issues may arrise due to BFD's subtleties. And
    the overall processing gain would be questionable, IMO.

    Maciej

    --
    + Maciej W. Rozycki, Technical University of Gdansk, Poland +
    +--------------------------------------------------------------+
    + e-mail: macro@ds2.pg.gda.pl, PGP key available +

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:32    [W:0.022 / U:2.752 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site