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/