Re: Weird workaround necessary for mescc-lib on ARM

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

Hello Danny,

> I've merged almost everything required for ARM to mes master,
> except for the following two things:
>
> (1) ntoab: Handle LONG_MIN case.

(yeah)

> (2) This:
>
> diff --git a/src/reader.c b/src/reader.c
> index c8ecea4..8304b1f 100644
> --- a/src/reader.c
> +++ b/src/reader.c
> @@ -106,6 +106,10 @@ reader_read_identifier_or_number (int c)
>      }
>    unreadchar (c);
>    g_buf[i] = 0;
> +#if __arm__ // FIXME: workaround for mescc end of file bug
> +  if (c == -1 && i == 1)
> +    exit (0);
> +#endif
>    return cstring_to_symbol (g_buf);
>  }
>
> This is horrible, but without it, none of the mescc-lib tests pass.

Agreed, right.

> How can I best isolate what is wrong?

Hmm...I find the comment suspicious, but it has to do something with
EOF.  I'm sure it's a mixture of these ingredients

   * EOF == -1
   * readchar
   * signed/unsigned char

So we found a way to detect EOF when it's "almost too late", but we
should have seen that sooner.

Maybe if we identify/create a simple test case, we can run compile mes
with debug info and run it in gdb; break at the other EOF tests and
try to "walk up" the call chain.

As a silly thought, would it be feasible to compile mes using
-fsigned-char for ARM, and see what happens; gain more understanding
that way?

> According to the build log, reader.c is compiled by gcc:

Yes.  In a non-bootstrap build, a development build; we compile mes
using gcc

> $ /gnu/store/wlkzcpb7gkcim0gk49amyd3l6jvhvp3l-profile/bin/gcc -c -D 
> HAVE_CONFIG_H=1 -I lib -I include -I include -I include/linux/arm -static 
> -nostdinc -nostdlib -fno-builtin -marm -static -g -o reader.o src/reader.c
> $ /gnu/store/wlkzcpb7gkcim0gk49amyd3l6jvhvp3l-profile/bin/gcc -static 
> -nostdinc -nostdlib -fno-builtin -marm -static -g -L . -static -nostdlib -L 
> gcc-lib -static -g -o bin/mes-gcc crt1.o gc.o hash.o lib.o math.o mes.o 
> module.o posix.o reader.o string.o struct.o vector.o -lc -lmescc
> $ cat ./lib/tests/scaffold/01-return-0.log
> ${HOME}/src/mes/scripts/mescc: line 65:  5083 Segmentation fault      (core 
> dumped) ${SCHEME-$MES} --no-auto-compile -e main -L 
> /usr/local/share/guile/site/2.2 -C /usr/local/lib/guile/2.2/site-ccache 
> $bindir/mescc.scm $sep "$@"
>
> Also, how come the *mescc-lib* tests fail when I don't apply this workaround?
>
> I would understand if the *gcc-lib* tests had failed, but why the mescc-lib 
> tests? O_o

Ah, that's ecause mes runs mescc; during  the mescc-lib tests.

The mes src/*.c sources play no role in the gcc-lib tests; the gcc-lib
tests only test the Mes C Library.

HTH,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com