On Tuesday 10 April 2007 21:07, James Simmons wrote:
> I tracked it down to way ash was hanging at start up. It was setjmp.
> Looking into the problem was uClibc was set to USE_FPU. This caused a
> lookup. So I disabled USE_FPU in uClibc but I'm getting
>
> arm-linux-uclibc-ld: ERROR:
> /home/jsimmons/work/ems2/iabuild/root/ems2-boot-tools/lib/gcc/arm-linux-uclibc/3.4.3/libgcc.a(_dvmd_lnx.o)
>
> uses hardware FP, whereas ld-uClibc-0.9.27.so uses software FP
>
> I tried several options to build the toolchain but no luck. This is using
> gcc-3.4.3 with uClibc 0.9.27. Anyone know how to fix this?
I have another report of setjmp acting wrongly (corrupting memory!),
on another architecture:
On Monday 12 March 2007 03:09, Franklin wrote:
> Recently I'm playing embedded system running on mpc8349 (powerpc).
> I built the toolchain myself, including glibc-2.4, binutils-2.17 and gcc-4.1.1
> Then I downloaded the busybox 1.4.1 and built it. However, when running
> starting script, it shown the following messages and the system was unusable:
Franklin did really amazing debugging run, which I unfortunately cannot
reproduce
here (it's too big). Here what he finally found:
On Thursday 15 March 2007 02:15, Franklin wrote:
> Denis Vlasenko's messages:
> > Hi,
> >
> > setjmp is "magic". It marks the point (CPU state) to which you
> > can return later with longjmp (by reloading CPU state into CPU).
> > (more info on their manpages)
> >
> > However, this does not explain how mark->stackp managed to
> > mysteriously change to NULL here:
....
> > What I am trying to understand - whether setjmp corrupts
> > mark->stackp by using wrong stack slot (fetching mark and using
> > it as a pointer to something else).
> >
> > Indirect way to test this theory:
> >
> > struct stackmark {
> > + char BOGOBUFFER[16];
> > struct stack_block *stackp;
> > char *stacknxt;
> > size_t stacknleft;
> > struct stackmark *marknext;
> > };
> >
> > This will make stackp inaccessible by just storing a word at *mark.
>
> Aha!
>
> BOGOBUFFER was cleared, and stackp was protected. :-)
Are these setjmp problems known?
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
