Hi All,
The new common definition of RODATA for linker scripts
(in include/asm-generic/vmlinux.lds.h) is causing me some
amount of pain, at least on the m68knommu architecture.
The problem is that on the m68knommu arch linker script
it fundamentaly groups everything into 2 memory regions,
one for flash and one for ram. Each section is then
directed to the appropriate memory region, eg:
.text : {
*(.text)
} > flash
With the way the RODATA define is setup I cannot do this.
It contains definitions for a number of complete sections.
Anyone got any ideas on the best way to fix this?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On Wed, 22 Jan 2003, Greg Ungerer wrote:
> The new common definition of RODATA for linker scripts
> (in include/asm-generic/vmlinux.lds.h) is causing me some
> amount of pain, at least on the m68knommu architecture.
>
> The problem is that on the m68knommu arch linker script
> it fundamentaly groups everything into 2 memory regions,
> one for flash and one for ram. Each section is then
> directed to the appropriate memory region, eg:
>
> .text : {
> *(.text)
> } > flash
>
> With the way the RODATA define is setup I cannot do this.
> It contains definitions for a number of complete sections.
>
> Anyone got any ideas on the best way to fix this?
First of all, asm-generic/vmlinux.lds.h is there to share common code
where possible, so if it's not possible, you still have the option of
having your own special code in arch/$(ARCH)/vmlinux.lds.S
Having said that, you could add
#define TEXT_MEM > flash
at the beginning of arch/m68knommu/vmlinux.lds.S
and
#ifndef TEXT_MEM
#define TEXT_MEM
#endif
at the beginning of include/asm-generic/vmlinux.lds.h and then change
.text : {
*(.text)
- }
+ } TEXT_MEM
Would that work for you?
--Kai
Hi Kai,
Kai Germaschewski wrote:
> First of all, asm-generic/vmlinux.lds.h is there to share common code
> where possible, so if it's not possible, you still have the option of
> having your own special code in arch/$(ARCH)/vmlinux.lds.S
And that is exactly what I have done as an immediate fix.
It would be nice if all architectures could use this
common code. Saves me having to specifically fix m68knommu
linker script when ever things inside RODATA change.
> Having said that, you could add
>
> #define TEXT_MEM > flash
>
> at the beginning of arch/m68knommu/vmlinux.lds.S
>
> and
>
> #ifndef TEXT_MEM
> #define TEXT_MEM
> #endif
>
> at the beginning of include/asm-generic/vmlinux.lds.h and then change
>
> .text : {
> *(.text)
> - }
> + } TEXT_MEM
>
> Would that work for you?
Yep, I would be happy with that.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
Hiya Miles,
Miles Bader wrote:
> Yeah, the new generic RODATA stuff is way broken on the v850 too.
>
> Besides the over-eager use of sections, it also assumes that C symbol
> names map one-to-one with `linker symbol' names, which isn't true with
> the default v850 compiler.
>
> Here's my local rewrite of include/asm-generic/vmlinux.lds.h, which
> works on the v850, and seems like it should be usable by other systems
> as well.
>
> It does two things:
[snip]
>
> What do you think of this?
I like it. Looks like an ideal solution, keeps a bunch of
stuff common, but is a lot more flexible in terms of output
sections (and their regions) .
> [To be honest, I think the stuff with `LOAD_OFFSET' is a bit of a waste;
> it seems cleaner to just have archs define their own sections as
> appropriate, and use RODATA_CONTENTS directly -- it's the input sections
> and related symbols that are always changing (and so better centralized),
> after all, not the output sections.]
Agree 100%.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On Wed, Jan 22, 2003 at 01:32:10PM +0900, Miles Bader wrote:
>
> [To be honest, I think the stuff with `LOAD_OFFSET' is a bit of a waste;
> it seems cleaner to just have archs define their own sections as
> appropriate, and use RODATA_CONTENTS directly -- it's the input sections
> and related symbols that are always changing (and so better centralized),
> after all, not the output sections.]
There were some reports of failed boots that boiled down to
mis-alignment of a single section.
With your suggestion we will end up in the same problem.
__start_ksymbtab will in some cases have a value less than the actual
start of the first symbol.
Sam
On 22 Jan 2003, Miles Bader wrote:
> Yeah, the new generic RODATA stuff is way broken on the v850 too.
Yup, I actually noticed when looking things over, sorry about that.
> (1) Separates the RODATA stuff into two macros, an input-sections-and-
> symbols macro, RODATA_CONTENTS, which can be put into any
> appropriate section, and a RODATA_SECTION macro, which simply
> defines an appropriate section using that. I guess most archs
> could just use RODATA_SECTION in the same way they use `RODATA'
> now, but the v850 uses RODATA_CONTENTS instead.
>
> This assumes that the original division into lots of little
> output sections was gratuitous, and that putting everything into
> a single section is OK.
>
> [You might notice that this follows the macro scheme already used
> by the v850's vmlinux.lds.S file]
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 idea behind the cleanup is two-fold:
o Make it easier to add e.g. special sections like __ksymtab and friends.
o Make the building of vmlinux more consistent, i.e. share a common way
where possible and explicitly document places where archs need to do
things differently. Today, there's a lot of differences between archs,
most of them I think just for historical grown-with-time reasons.
A reason to use sections of their own for e.g. __ex_table, __ksymtab etc.
is also to get alignment right without magic numbers in vmlinux.lds.S.
One example of the inconsistency is e.g. the _etext symbol. For v850 it
includes .rodata, exception table etc. So if calculating _etext - _stext,
one gets a wrong impression of the code size, and generic code which
assumes that there's code between _stext and _etext (kernel/extable.c)
obviously uses a wrong assumption.
> (2) Adds a `CSYM' macro which is used for every symbol name that is
> exported to C. By default this just expands to its argument, but
> an arch may define `C_SYMBOL_PREFIX' in order to add a prefix to
> all C symbols.
>
> What do you think of this?
I definitely agree with (2), with (1) only if there's a good reason.
--Kai
Sam Ravnborg <[email protected]> writes:
> > [To be honest, I think the stuff with `LOAD_OFFSET' is a bit of a waste;
> > it seems cleaner to just have archs define their own sections as
> > appropriate, and use RODATA_CONTENTS directly -- it's the input sections
> > and related symbols that are always changing (and so better centralized),
> > after all, not the output sections.]
>
> There were some reports of failed boots that boiled down to
> mis-alignment of a single section.
> With your suggestion we will end up in the same problem.
> __start_ksymbtab will in some cases have a value less than the actual
> start of the first symbol.
Then it would seem an alignment directive should probably be included
before __start_ksymbtab (and possibly other places). [but I can't see
what it has to do with having separate sections or not.]
-Miles
--
"Most attacks seem to take place at night, during a rainstorm, uphill,
where four map sheets join." -- Anon. British Officer in WW I
Kai Germaschewski <[email protected]> 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.
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?
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).
> 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).
-Miles
--
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."
Hi Kai,
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.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On 22 Jan 2003, Miles Bader wrote:
> Kai Germaschewski <[email protected]> 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
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
Kai Germaschewski <[email protected]> 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/*/vmlinux.lds.S 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:
.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.
Hi Kai,
Kai Germaschewski wrote:
[snip]
> 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)
I can see your point here. So as long as we can get the sections
within RODATA placed into the right segment then we can still do
what we need. That will be good enough for me in the m68knommu case.
[snip]
>>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.
Oddly enough (or perhaps not :-) this is virtually the method I
currently use in the m68knommu vmlinux.lds.S to allow it to link
for both flash+ram or ram-only operation - depending on a CONFIG_
option.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com