file is attach
wrong (other) results
I don't see any garbage but the backspace act (almost) like {cursor right}
I can send a strace but I'm not sure if it is usefulprobably stupid suggestion but if the is a complex problem isn't wise to first find out where the problem start? I can try to use a newer uclibc on my crosscompiler (0.9.28.3 is the latest I get working) ? if its a NOMMU problem then it should be able to reproduce But I'm afraid that its a combination between my target(arm), toolchain and something else > -----Oorspronkelijk bericht----- > Van: Denys Vlasenko [mailto:[EMAIL PROTECTED] > Verzonden: zondag 17 februari 2008 16:12 > Aan: Martinb_ARM_NOMMU_KISSDVD > CC: [email protected] > Onderwerp: Re: Command line editing give a wrong result for me on > hush shell 1.9.1 > > > On Sunday 17 February 2008 00:45, Martinb_ARM_NOMMU_KISSDVD wrote: > > The lineedit.s is attach > > > > and if i do the: > > > > > - if (num <= 4) { > > > + if (0) { > > > > its running 100% like it should (also the home and end key) > > Thanks for fixing this last part , i now can use hush and remove the old > > lash from rom > > so printf(("\b\b\b\b" + 4) - num) is compiled into: > > .LC0: > .ascii "\b\b\b\b\000" > .align 2 > ... > #APP > # HERE > ldr r0, .L27+8 @ tmp90, > rsb r0, r4, r0 @, num, tmp90 > ldmfd sp!, {r4, r5, lr} @ > b printf @ > ... > .L27: > .word ptr_to_statics > .word .LC1 > .word .LC0+4 <====== third word > .word .LC2 > > Let's see: > > ldr r0, .L27+8 > > loads third 32 bit word from .L27. This word seems to correctly > point to four bytes past the beginning of "\b\b\b\b" string. > > But since we see garbage instead of correct output, > I guess the value in this word (.word .LC0+4) gets trashed > by the time we reach "ldr r0, .L27+8"! We get a pointer to garbage, > and we output garbage. > > I looked at the file and I cannot see where that happens, > but it definitely happens. This is not good. > > I am not happy. Just removing if() doesn't fix the problem > of something corrupting memory. > > Just in case I read the code incorrectly (it seems to be ok, > but maybe I can't read ARM?), let's try to fool gcc into > producing a bit different code? > > can you try re-phrasing the code as follows: > > if (cmdedit_x >= num) { > const char *bbbb = "\b\b\b\b"; > cmdedit_x -= num; > if (num <= 4) { > bbbb -= num; > asm volatile("# HERE"); > printf(bbbb); > return; > } > printf("\033[%uD", num); > return; > } > > run test it and also send me the result of "make libbb/lineedit.s" > again. > > > I will do some more extensive testing and wil give a shout to > the list if i > > find something else > > > > > > just for my information i was looking in > > > http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/busybox_1_8_st able/libbb > /lineedit.c?rev=20160&view=markup Doesn't work here too. Try http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/libbb/lineedit.c?rev=21 021&view=markup > to find when this code was edit (and why) but the cvs is not giving me te > results > is it broken? > > one more question for the list: > is the job control option of any use for a NOMMU system? (i understand its > use, but im not sure if its of any use for nommu) Job control is useful on NOMMU. It is just harder to implement there. Well, on NOMMU running "command &" is easy to implement, but, for example, making "{ command; command2; } &" work correctly would be much more difficult. -- vda
lineedit.s.bz2
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
