Lua Tiny RAM
Locked
|
Hi Folks,
I'm porting eLua to the power pc for a project I'm working on. What I'm trying to figure out is why luaB_print dies when I compile with optram=yes. For example, ="hello" works fine with optram=no, but causes me trouble with optram=yes. I've traced it down to the result of hashstr in luaH_getstr. But my understanding of lua internals has hit a wall.
I will read over Bogdan's material on LTR, but if anything jumps out to those of you reading, please do let me know your theories. Thanks, Matt
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Thu, Apr 28, 2011 at 9:20 PM, Matt Wilbur <[hidden email]> wrote:
Hi Folks, How are stext and etext defined in your linker command script?
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi Bogdan,
You suspect isrotable is returning the wrong thing? I wondered about that. How do the string ro tables interact with the regular stuff? Anyhow, stext is defined to be the start of the .text section, etext near the end. My linker script is a hand-modified version of the one that comes with CodeSourcery lite for the PPC eabi.
SECTIONS { .text : { CREATE_OBJECT_SYMBOLS stext = .; __cs3_region_start_ram = .; _ftext = .; *(.cs3.region-head.ram)
ASSERT (. == __cs3_region_start_ram, ".cs3.region-head.ram not permitted"); *(.cs3.reset) __cs3_start_asm_uboot = DEFINED(__cs3_start_asm) ? __cs3_start_asm : __cs3_start_asm_uboot;
*(.text.cs3.init) *(.text .text.* .gnu.linkonce.t.*) . = ALIGN(0x4); KEEP (*crtbegin.o(.jcr)) KEEP (*(EXCLUDE_FILE (*crtend.o) .jcr))
KEEP (*crtend.o(.jcr)) . = ALIGN(0x4); *(.gcc_except_table .gcc_except_table.*) etext = . ; *(.ramtext) . = ALIGN(0x10);
} >ram On Thu, Apr 28, 2011 at 2:33 PM, Bogdan Marinescu <[hidden email]> wrote: Hi, _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
I moved it to the end of rodata where it should have been. Now it works.
Boy, do I feel dumb.
I'm still very curious about rotables, so I have some reading to do. Matt On Thu, Apr 28, 2011 at 2:40 PM, Matt Wilbur <[hidden email]> wrote: Hi Bogdan, _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Matt Wilbur
Hi,
On Thu, Apr 28, 2011 at 9:40 PM, Matt Wilbur <[hidden email]> wrote: Hi Bogdan, In short, the keys in a rotable are C strings as opposed to Lua strings in a regular table. The code had to be changed to take this into account.
This is probably why it doesn't work. Currently all the eLua linker command scripts place all the .rodata sections (which also contain the rotables) inside .text and between .stext and .etext. You could either:
- modify the linker script to include the .rodata sections (.rodata .rodata.*) between stext and etext - checkout the "ltrwork" branch. It has some improvements on the LTR mechanism; amongst other things it doesn't depend on stext and etext anymore. You could actually try this first, I doubt it would impact your port too much.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Matt Wilbur
On Thu, Apr 28, 2011 at 9:47 PM, Matt Wilbur <[hidden email]> wrote: I moved it to the end of rodata where it should have been. Now it works. No reason at all to feel dumb. That's not exactly intuitive :)
BTW, great news on the PPC port!
The "ltrwork" branch makes rotables into actual types with a header common to regular tables which is much more logical (although it increases the flash usage a bit) and can differentiate between regular tables and rotables simply by checking this common header. You might find the implementation on "master" a bit clumsy. Then again, you might find both of them clumsy :)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Apr 28, 2011 at 15:51, Bogdan Marinescu <[hidden email]> wrote:
+1 Thankssssssss
:) :) Does this mean that it will be changed/improved at any time or this is a final work ?
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Apr 28, 2011 at 10:28 PM, Dado Sutter <[hidden email]> wrote:
I think it can be regarded as "final" for now :) Actually, beside cosmetic and structural improvements, it's also quite important for the someday-to-come support for loadable binary modules. So this is mostly need-based, it might change again in the future for an yet unforseen reason.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |