lkml.org 
[lkml]   [2003]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: common RODATA in vmlinux.lds.h (2.5.59)
    From
    Date
    Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> writes:
    > > Actually as far as I can see, my suggested alternative is _less_ complex
    > > than the current RODATA.
    >
    > I don't see that. Your suggestion has two macros, RODATA_CONTENTS and
    > RODATA_SECTION, and arch/*/vmlinux.lds.S would use one or the other.

    Well, actually I was also suggesting that there really shouldn't be
    RODATA_SECTION at all, and every linker script should just use
    RODATA_CONTENTS embedded in an existing section of their choice or in a
    trivial .rodata section, e.g:

    .rodata { RODATA_CONTENTS }

    > Surely you agree that all arch/*/vmlinux.lds.S using the same one would be
    > simpler?

    No, in fact I don't think it would -- your suggestion is that there
    should be a single macro affected by all sorts of `magic defines' that
    somehow change its behavior (e.g. LOAD_OFFSET, and the
    output-memory-area defines you mentioned to solve my output memory
    region problem). This sort of structure seems very confusing to me,
    even if it's superficially simpler (by having only a `single macro').

    Not having the macro(s) create output sections makes the result a _lot_
    easier to understand, since there's not all this behind-the-scenes
    tweaking going on by the macro, it's all pretty straight-forward.

    > I suppose the major reasons for multiple output sections is consistency
    > with the default ld script

    Why is this important?

    > and alignment in particular.

    This is more important problem with my scheme:

    > the only way to ensure that in your solution is . = ALIGN(x) beforehand,
    > where it's however necessary to know the requirements of __ksymtab. This
    > means magic numbers which are not even constant for different archs and of
    > course it's also fragile, if someone changes the struct which is put into
    > __ksymtab, they most likely don't remember to change all the magic numbers
    > in arch/*/vmlinux.lds.S.

    I see your point, but is this really a problem in practice? I suspect
    that about 99% of the time you can get away with simply being a bit
    conservative, e.g., aligning to an 8- or 16-byte boundary (I would be
    very surprised if there's an arch that aligns structs more than that,
    for obvious reasons).

    > You want to use sections as an abstraction for different parts of the
    > image, like text/rodata vs data.

    Um, no I don't. I just want to control where the output sections go,
    e.g., into RAM or ROM, and how the load-time and run-time addresses are
    related. Most of the time I don't care what the output sections are,
    as long as I can control their disposition.

    > However, let me claim the sections are not the right tool for the job,
    > instead that's why ELF segments exist. Just declaring two MEMORY
    > regions, e.g. rom/ram and putting text/rodata sections into rom, the
    > rest into ram will give you a vmlinux with two segments, exactly what
    > you need. (There's two ways to do that, using MEMORY or PHDRS -
    > whatever works better for you)

    I'm not sure what you mean by `segments' (the GNU ld linker script
    documentation is dreadful), but I'll try to look them up and see if they
    can help me solve my problem.

    > All of this can, AFAICS, be nicely handled by additional
    > "{TEXT,RODATA,DATA}_MEM" macros which allow the arch to specify
    > regions as necessary.

    That sounds clumsy to me, because it adds lots of `parameters' to the
    common macros -- I'd prefer a solution where the macros can be as much
    of a black-box as possible -- but it will probably work.

    Thanks,

    -Miles
    --
    Fast, small, soon; pick any 2.
    -
    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.027 / U:0.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site