lkml.org 
[lkml]   [2003]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: common RODATA in vmlinux.lds.h (2.5.59)
On 22 Jan 2003, Miles Bader wrote:

> Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> 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


-
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.055 / U:3.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site