Re: common RODATA in vmlinux.lds.h (2.5.59)

[Kai Germaschewski]

On 22 Jan 2003, Miles Bader wrote:

> Kai Germaschewski <[e-mail]> writes:
> > Yes, I saw it, but on the other hand I'd like to avoid introducing
> > complexity which isn't really needed.
> 
> 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. 
Surely you agree that all arch/*/vmlinux.lds.S using the same one would be 
simpler?

> It seems to me that the absolutely most straight-forward solution is to
> have a single macro that groups input sections and symbol defs, and is
> simply embeddable into any old output section, i.e. RODATA_CONTENTS
> (note that it's actually shorter than RODATA).  Is there some reason
> why multiple output sections are actually necessary?

I suppose the major reasons for multiple output sections is consistency 
with the default ld script, and alignment in particular. Note that

	. = __start___ksymtab
	*(__ksymtab)

is broken when . isn't aligned to the requirements of *(__ksymtab) already 
- 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.

Using sections allows to do instead:

	__ksymtab : {
		__start___ksymtab = . ;
		*(__ksymtab)
	}

which will align things correctly without further tricks.

You want to use sections as an abstraction for different parts of the 
image, like text/rodata vs data. 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)

> Also, I've found that defining symbols outside the sections, like RODATA
> does, to be somewhat dangerous, and have had much better luck defining
> them inside the sections whenever possible (sometimes it isn't, of
> course, but none of the RODATA symbols appear to have any problems).

Yes, you're right on that one, it's already fixed in -mm, the mainline 
fix has to wait for Linus' return ;)

> > So the important question is:  Is there a reason that v850 does things
> > differently, or could it just as well live with separate .text and
> > .rodata sections.
> 
> It's not that it _needs_ to group things inside a single output section
> (though often doing so is just simpler), but it _does_ need more control
> over the output sections than is provided by the current RODATA macro:
> at least, it needs to be able to specify which memory regions the
> various sections go, sometimes at separate link- and run-time addresses
> (i.e., a "> MEM AT> OTHER_MEM" directive following each output section).

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

--Kai