Messages in this thread | | | Subject | Re: common RODATA in vmlinux.lds.h (2.5.59) | From | Miles Bader <> | Date | 22 Jan 2003 15:23:48 +0900 |
| |
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.
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." - 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/
| |