Command line editing give a wrong result for me on hush shell 1.9.1

[Stig Petter Olsrød]

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
<stigpo at users.sourceforge.net> 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 (rob at sysgo.de) */
>  -       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 */
>