Stephen Giandomenico's Blog: echo

Good news (i.e. progress):

Those last few errors are resolved, and Squawk now builds and deploys to the Luminary Micro Development Kit board.  I have console out, and thereby basic debug information.

For those interested:
The strsignal function seems to be one of those non-standard, standard functions, which fortunately had been implemented for another port of Squawk.  Yay for "cut & paste".
As for the memory overlap error, I believe it had to do with the ".ARM.exidx" section being implicitly allocated at a location already occupied by other data.  That then was a simple matter of allocating the region explicitly.

Bad news (i.e. TODO):

Not all stdlib functions seem to be working.  Specifically, I've tried malloc, calloc, printf, and fprintf.  Of those, only malloc returns normally (I have yet to identify whether or not it works correctly).  The others do not return at all; instead causing Squawk to halt abruptly.  I've done minimal implementations for all the underlying functions, like _sbrk, but according to a lack of print statements, they do not appear to be being called (in case you're wondering, I'm using a printf-like statement to do all my debug printing, which does in fact work).  And preliminary research has thus far yielded no useful information, nor records of similar experiences.

So tomorrow's agenda: research, experiment, scratch my head, and research some more.  That said, I am still hopeful that I will be able to get this all working in the very near future, i.e. before I leave.

---

Update 8/12/09: so it seems that the functions that fail do so by immediately dropping into the FaultISR, and I haven't the faintest idea why.  I've seen references to increasing the stack size, but that seems to have no effect.  And I can't get the embedded gdb working either; all I get is this most-informative message:

(gdb) Remote communication error: No error.

Real useful.  Back to the drawing board (or Google).