[lkml]   [2003]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: common RODATA in (2.5.59)
Kai Germaschewski <> 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/*/ 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:


> Surely you agree that all arch/*/ 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/*/

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.


Fast, small, soon; pick any 2.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.076 / U:3.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site