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

From: Kai Germaschewski (kai@tp1.ruhr-uni-bochum.de)
Date: Wed Jan 22 2003 - 11:35:42 EST


On Wed, 22 Jan 2003, Greg Ungerer wrote:

> Kai Germaschewski wrote:
> > Yes, I saw it, but on the other hand I'd like to avoid introducing
> > complexity which isn't really needed. 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 (Note that sections
> > like .rodata1 will be discarded when empty).
>
> The reason we tend to group all these things together is that logically
> that is the way they are layed out between flash and ram (and running
> the kernel code in flash is really the case that is interresting here).
> Where you have the text and rodata parts resident in flash (and this is
> where they stay), and the data and bss in ram (but they start in flash
> and are copied on start up to ram). So 2 very different memory regions
> involved, not just one contiguous blob like on most VM architectures.
>
> So to build a flash image most people just objcopy out the
> text and the data (and init really too) sections and cat them
> together and that is the binary image that you program into
> your flash. If you have lots of sections this makes this
> extraction and concatentation process just plain ugly. And when
> you add new sections your flash building needs to know about
> them and handle them.

Let me just point to the other reply I just wrote. I think you're using
the wrong tool and should use ELF segments instead, that's what they're
there for in the first place. If you base your flash building on segments,
there should be no need for it to know about sections at all.

--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/



This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:29 EST