> mkedwards has these scripted up at:
> https://github.com/mkedwards/crosstool-ng/tree/master/scripts/build/companion_libs
>
> We should add these in upstream. I'd rather focus on GCC first, get
> that out as a prototype, then add GDB.
I tried tried mkedwards's extention. The GDB-cross can build
On Mon, Oct 24, 2011 at 2:09 PM, Zhenqiang Chen
wrote:
> Summary:
> * Exercise crosstool-ng and summarize the gaps.
>
> Details:
> * Exercise crosstool-ng
> (1) Sync with lp:~linaro-toolchain-dev/crosstool-ng/linaro.
> (2) Try to config linux-host-baremental-target an
> mingw32-host-baremental-t
On Tue, Oct 25, 2011 at 9:42 AM, Bruno Niklaus wrote:
> hi@all
> i try to build the linaro-gcc on a ubuntu host 11.10 32 bit for a cortex a9.
> but it doenst build to the end.
> this is the first time ever i try to build a toolchain on my own, so excuse
> me if its just a beginner-mistake.
> someb
hi@all
i try to build the linaro-gcc on a ubuntu host 11.10 32 bit for a cortex a9.
but it doenst build to the end.
this is the first time ever i try to build a toolchain on my own, so excuse
me if its just a beginner-mistake.
somebody has any idea?
configured like this
*./configure --target=arm
On 24 October 2011 20:05, Michael K. Edwards wrote:
> The calling convention for makecontext() isn't just an issue for standards
> lawyers, it's an actual problem on ARM, especially on hard-float systems.
> According to the standard, "The application shall ensure that the value of
> argc matches t
The calling convention for makecontext() isn't just an issue for standards
lawyers, it's an actual problem on ARM, especially on hard-float systems.
According to the standard, "The application shall ensure that the value of
argc matches the number of arguments of type int passed to func; otherwise,
==Progress===
* Some upstream patch review.
* Spent time looking at LP 836588 which is a case where CSE removes a
particular label access in one case but doesn't remove it from the
list of things in the constant pool which is quite bizarre. Will
probably need some help with looking into this one.
Continued looking at my constant reuse optimization. I've identified a
couple of hundred optimization opportunities in the whole of gcc itself,
which is fewer than I had hoped. There are almost no opportunities when
compiling for size as constants are always loaded from a constant pool
in that
At the moment ARM eglibc doesn't support the functions declared
in ucontext.h: getcontext(), setcontext(), swapcontext() and
makecontext(). Instead you get implementations which always
fail and set errno to ENOSYS.
QEMU uses these functions to implement coroutines. Although there
is a fallback imp
