Re: Weird workaround necessary for mescc-lib on ARM

[Danny Milosavljevic]

Some preliminary findings:

mescc-lib/$ ../pre-inst-env mescc -m 32 -c -D HAVE_CONFIG_H=1 -I ../lib -I 
include -I ../include -I ../include/linux/arm -static -nostdinc -nostdlib 
-fno-builtin -marm -o crt1.o ../lib/linux/arm-mes-mescc/crt1.c 
#adapted for gdb --args /home/dannym/src/mes/bin/mes --no-auto-compile -e main 
-L /usr/local/share/guile/site/2.2 -C /usr/local/lib/guile/2.2/site-ccache 
/home/dannym/src/mes/scripts/mescc.scm -- -m 32 -c -D HAVE_CONFIG_H=1 -I ../lib 
-I include -I ../include -I ../include/linux/arm -static -nostdinc -nostdlib 
-fno-builtin -marm -o crt1.o ../lib/linux/arm-mes-mescc/crt1.c
[...]
#0  0x00024720 in __assert_fail (s=0x26814 "!\"alloc: out of memory\"")
    at ../lib/mes/__assert_fail.c:31
#1  0x000151d4 in alloc (n=3) at src/mes.c:71
#2  0x000222f0 in make_bytes (s=0xe52b3e3 "", length=1) at src/string.c:73
#3  0x0002240c in make_string (s=0xe52b3e3 "", length=1) at src/string.c:90
#4  0x0001f538 in unreadchar (c=-1) at src/posix.c:79
#5  0x00020d98 in reader_read_identifier_or_number (c=-1) at src/reader.c:107
#6  0x00021034 in reader_read_sexp_ (c=255, a=1) at src/reader.c:155
#7  0x0002122c in read_env (a=1) at src/reader.c:192
[...]
#2972 0x00020a38 in read_input_file_env_ (e=15726357, a=1) at src/reader.c:35
[...]
#5698 0x00020a38 in read_input_file_env_ (e=15726357, a=1) at src/reader.c:35
[...]
#21527 0x00020a38 in read_input_file_env_ (e=15726357, a=1) at src/reader.c:35
[...]
#40874 0x00020a38 in read_input_file_env_ (e=15726357, a=1) at src/reader.c:35
[...]
^C
(gdb) print peekchar()
$1 = -1

With conditional breakpoint:
(gdb) b reader.c:108
(gdb) cond 1 c == -1 && i == 1
(gdb) bt
#0  reader_read_identifier_or_number (c=-1) at src/reader.c:108
#1  0x00021034 in reader_read_sexp_ (c=255, a=1) at src/reader.c:155
#2  0x0002122c in read_env (a=1) at src/reader.c:192
#3  0x00020a28 in read_input_file_env_ (e=13635, a=1) at src/reader.c:35
#4  0x00020a80 in read_input_file_env (a=9001) at src/reader.c:43
#5  0x0001ac18 in eval_apply () at src/mes.c:1120
#6  0x0001eab0 in main (argc=31, argv=0xbefff004) at src/mes.c:1871

Also checked lib/mes/fdgetc.c . 

Could it be that ungetc tries to unget EOF?  In that case the man page
of ungetc says that it will cast it to unsigned char (and thus it will
actually unget 255).

pgpGRnn1h7J0G.pgp
Description: OpenPGP digital signature