Let each target handle its own initialization/finalization sequence
instead of providing one in the runtime with hooks for memory
initialization etc. This is much more flexible although it causes a
little bit of code duplication.
A few changes to make sure compiler-rt is correctly compiled (and
doesn't include host headers, for example).
This improves support for AVR, but it still doesn't work. Compiler-rt
itself doesn't really work for AVR either.
When the underlying value of an interface does not fit in a pointer, a
pointer to the value was correctly inserted in the heap. However, the
receiving method still assumed it got the underlying value instead of a
pointer to it leading to a crash.
This commit inserts wrapper functions for method calls on interfaces.
The bug wasn't obvious as on a 64-bit system, the underlying value was
almost always put directly in the interface. However, it led to a crash
on the AVR platform where pointer are (usually) just 16 bits making it
far more likely that underlying values cannot be directly stored in an
interface.
Make sure package initializers show up in backtraces, as they should. In
practice, it doesn't actually break backtraces as these functions are
usually inlined anyway, but it may help to debug an error in
initialization code.
In most cases, it's useless. But in some cases it may be critical if the
OCD server (like openocd) has a problem.
It would be nice if openocd would differentiate between stdout and
stderr, and only write errors to stderr. But sadly it doesn't.
xml.etree.ElementTree is much easier to work with. This also fixes a few
small bugs in the parser. And as an added bonus, device generation got a
lot faster: apprently etree is a lot faster than minidom.
Be more compatible with the Go toolchain by setting GOPATH in the same
way. This makes it possible to flash and run examples from the standard
GOPATH instead of only from the source tree.
This code:
foo & 0xffffff
Is equivalent to this code:
foo % 0x1000000
However, to drop the high 8 bits, this calculation was used:
foo % 0xffffff
This is far more expensive (and incorrect), as it needs an actual modulo
operation which increases code size and probably reduces speed on a
Cortex-M4 and needs library functions for a Cortex-M0 increasing code
size by a much bigger amount.
Ayke van Laethem
Ron Evans