I want to confirm that Stig Petter did made the correct conclusion on this issue It is related to a bug in elf2flt this is a 3,5 year old bug! amazing that it is found after such a long time
But I’m glad to report that the suggested patch for elf2flt did fix my toolchain and now I can use the original busybox without any modification Thanks for solving this problem > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Stig Petter Olsrød > Verzonden: woensdag 20 februari 2008 21:49 > Aan: [email protected] > Onderwerp: Re: Command line editing give a wrong result for me on hush > shell1.9.1 > > > I didn't quite manage to fool the threading system, so just to make it > clear, this mail was in response to the thread started by > Martinb_ARM_NOMMU_KISSDVD martinb at zeelandnet.nl > Thu Feb 14 13:52:31 PST 2008 > with the same subject. So please have a look at that for the background. > > A patch for elf2flt to fix this issue has been submitted as issue 0002274: > > http://busybox.net/bugs/view.php?id=2274 > > Another patch to make the elf2flt -a option work for generic arm > toolchains has also been posted as issue 0002284: > > http://busybox.net/bugs/view.php?id=2284 > > -- > Stig Petter > > On Wed, Feb 20, 2008 at 8:24 PM, Stig Petter Olsrød > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > The issues you have been seeing with > > > > printf("\b\b\b\b" + (4 - num)); > > > > in lineedit.c (input_backward) is actually caused by a bug in elf2flt > > which is used as a final step of linking. So even though the gcc > > output is correct the last step messes it up. > > What happens is that gcc produces "optimized" code for "\b\b\b\b" + 4 > > - num such that the pointer is actually to the zero termination of > > "\b\b\b\b", i.e > > > > .word .LC0+4 > > > > So the relocation will be relative to .LC0, which is kind of unusual. > > All the others strings are relative to .rodata. But still gcc is doing > > OK. Then comes elf2flt and links it all together, but unfortunately > > there are more .LC0 symbols after compiling busybox. And elf2flt will > > just scan for the first symbol named .LC0 in a give section instead of > > using the information BFD supplies (which by the way points to the > > correct symbol). So every relocation that was relative to a symbol > > called .LC0 will be relative to the first .LC0 symbol and not the > > correct one. > > > > There are a total of 6 such "bad" relocations in busybox (with my > > configuration) so changing this code is not going to help much. I > > vote for fixing elf2flt ;-) > > > > -- > > Stig Petter > > > > OFF-TOPIC: Shouldn't hush deal with Ctrl-C (i.e. handle > > read_line_input() == 0)? I haven't looked at this too closely, so this > > patch might be way off, but it produces more "expected" results for > > interactive mode at least. > > =============== PATCH ========================== > > Index: shell/hush.c > > =================================================================== > > --- shell/hush.c (revision 21064) > > +++ shell/hush.c (working copy) > > @@ -1268,7 +1268,11 @@ > > * is actually being read; otherwise, we'll end up bequeathing > > * atexit() handlers and other unwanted stuff to our > > * child processes ([EMAIL PROTECTED]) */ > > - r = read_line_input(prompt_str, user_input_buf, BUFSIZ-1, > > line_input_state); > > + do { > > + // Spin until we get something other than ctrl-c > > + r = read_line_input(prompt_str, user_input_buf, > > BUFSIZ-1, line_input_state); > > + } while (r == 0); > > + > > i->eof_flag = (r < 0); > > if (i->eof_flag) { /* EOF/error detected */ > > user_input_buf[0] = EOF; /* yes, it will be truncated, > > it's ok */ > > > _______________________________________________ > busybox mailing list > [email protected] > http://busybox.net/cgi-bin/mailman/listinfo/busybox > _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
