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
