This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
broken strlen (Re: strange bootstrapping problems on i386-sequent-sysv4)
- To: gcc-bugs at gcc dot gnu dot org
- Subject: broken strlen (Re: strange bootstrapping problems on i386-sequent-sysv4)
- From: Marco Franzen <marcof at thyron dot com>
- Date: Fri, 24 Mar 2000 18:55:50 GMT
I have now tried snapshot gcc_ss_2000_03_13. It still does not bootstrap, but
now I know why.
WRT my previous posting (17th of March), the change to 2.95.2's configure to
include NO_SYS_SIGLIST is not necessary anymore for this snapshot, so that you
can forget about that patch.
As turned out, the root of the problem is strlen in the vendor's C library! It
can read beyond the terminating 0, causing a SIGSEGV from time to time
(apparently if the next memory page is not assigned to the process, see the
debug session below).
I tried to get around this by bootstrapping with an existing gcc-2.8.1. First
I tried -fhosted (which I hoped would make strlen predefined), but cc1 kept
crashing in the vendor's strlen, called from gcc/tree.c. With
-Dstrlen=__builtin_strlen, I was able to work around this, but then it crashed
later when strlen was called by (the vendor-supplied) doprnt, called from
fprintf, when writing debug (-g) output.
I wonder why other applications (including earlier gcc versions) have no
problem with this. It might have to do with the way memory is allocated
and/or whether the beginning of strings is aligned. (Maybe a change to
obstack?)
Of course, this version of strlen is broken, and it is not the application's
fault. However, libiberty could supply a version of strlen (probably calling
__builtin_strlen for later stages and using some trivial implementation for
non-GNU compilers). I have no idea, though, how `configure' could reliably
check for this bug (mmap, sbrk?).
Has anybody heard of this kind of bug before (on any platform)? Is it common
and worth working around in GCC/libiberty/autoconf? If so, a similar bug with
other functions like strcpy might be rife too, but the next case would be
easier to solve once a framework is there.
BTW, why is __builtin_strlen (&co) not built in under the name strlen (etc,
resp) if -fhosted is given (or defaulted)?
================================================================
gnu@bucks$ debug stage1/cc1 parse-scan.i -quiet -g -O3 -W -Wall -Wtraditional -W -Wall -version -fpreprocessed -o /var/tmp/ccOwVlTk.s
New program cc1 (process p1) created
debug> run
GNU C version 2.96 20000313 (experimental) (i386-sequent-sysv4) compiled by GNU C version 2.8.1.
In file included from ./parse-scan.y:107:
lex.c: In function `java_read_char':
lex.c:206: warning: implicit declaration of function `__filbuf'
SIGNALED 11 (segv) in p1 [strlen()]
0xbffcc19d (strlen+73:) movl (%edx),%eax
debug> stack
Stack Trace for p1, Program cc1
[12] strlen(0xbf409ff1) [0xbffcc19d]
[11] _doprnt(0x82cf2ee,0x80474b0,0x82f94f8) [0xbffd0588]
[10] fprintf(0x82f94f8,0x82cf2e2,0x82cede5,0x23e,0x82ced80,0xbf409ff1,0x23e) [0xbffd6619]
[9] dwarfout_line(filename=0xbf409ff0,line=574) [dwarfout.c@5622]
[8] output_source_line(file=0x82f94f8,insn=0xbf3fd240) [final.c@3023]
[7] final_scan_insn(insn=0xbf3fd240,file=0x82f94f8,optimize=3,prescan=0,nopeepholes=0) [final.c@2277]
[6] final(first=0xbf453300,file=0x82f94f8,optimize=3,prescan=0) [final.c@2010]
[5] rest_of_compilation(decl=0xbfdcbe80) [toplev.c@3747]
[4] finish_function(nested=0) [c-decl.c@6491]
[3] yyparse() [c-parse.c@312]
[2] compile_file(name="C") [toplev.c@2451]
[1] main(argc=14,argv=0x8047b74,0x8047bb0) [toplev.c@4924]
[0] _start() [0x804903d]
debug> print ((char*)0xbf409ff1)[0]
47 (or '/')
debug> print ((char*)0xbf409ff1)[1]
112 (or 'p')
debug> print ((char*)0xbf409ff1)[2]
97 (or 'a')
debug> print ((char*)0xbf409ff1)[3]
114 (or 'r')
debug> print ((char*)0xbf409ff1)[4]
115 (or 's')
debug> print ((char*)0xbf409ff1)[5]
101 (or 'e')
debug> print ((char*)0xbf409ff1)[6]
45 (or '-')
debug> print ((char*)0xbf409ff1)[7]
115 (or 's')
debug> print ((char*)0xbf409ff1)[8]
99 (or 'c')
debug> print ((char*)0xbf409ff1)[9]
97 (or 'a')
debug> print ((char*)0xbf409ff1)[10]
110 (or 'n')
debug> print ((char*)0xbf409ff1)[11]
46 (or '.')
debug> print ((char*)0xbf409ff1)[12]
121 (or 'y')
debug> print ((char*)0xbf409ff1)[13]
0
debug> print ((char*)0xbf409ff1)[14]
0
debug> print ((char*)0xbf409ff1)[15]
Error: Got only 0 out of 1 bytes from address 0xbf40a000
Error: Evaluation of ((char*)0xbf409ff1)[15] failed
debug> dis -c 55 strlen
debug: internal error - cannot recover
sig=11 pc=0xbffcc158 sp=0x80475b4 r0=0x80475e8 code=0x04 (page fault) code_data=0 fa=0
gnu@bucks$ # debug has problems with gcc-compiled code
gnu@bucks$ cat strlen.c
int main (int argc, char *argv[]) { return strlen (argv[0]); }
gnu@bucks$ cc -g strlen.c -o strlen
gnu@bucks$ debug ./strlen
New program strlen (process p1) created
debug> stop main
EVENT [1] assigned
debug> run
STOP EVENT TRIGGERED: main in p1 [main() in strlen.c]
1: int main (int argc, char *argv[]) { return strlen (argv[0]); }
debug> stop strlen
EVENT [2] assigned
debug> run
STOP EVENT TRIGGERED: strlen in p1 [strlen()]
0xbffcc154 (strlen+0:) movl 0x4(%esp,1),%edx
debug> dis -c55 strlen
Disassembly for p1, Program strlen
0xbffcc154 (strlen+0:) movl 0x4(%esp,1),%edx
0xbffcc158 (strlen+4:) movl (%edx),%eax
0xbffcc15a (strlen+6:) addl $0x4,%edx
0xbffcc15d (strlen+9:) leal 0xfefefeff(%eax),%ecx
0xbffcc163 (strlen+15:) notl %eax
0xbffcc165 (strlen+17:) andl %eax,%ecx
0xbffcc167 (strlen+19:) testl $0x80808080,%ecx
0xbffcc16d (strlen+25:) jne 0x5e <bffcc1cd> [strlen]
--> 0xbffcc16f (strlen+27:) movl (%edx),%eax
when called from tree.c, it crashed here
0xbffcc171 (strlen+29:) addl $0x4,%edx
0xbffcc174 (strlen+32:) leal 0xfefefeff(%eax),%ecx
0xbffcc17a (strlen+38:) notl %eax
0xbffcc17c (strlen+40:) andl %eax,%ecx
0xbffcc17e (strlen+42:) testl $0x80808080,%ecx
0xbffcc184 (strlen+48:) jne 0x47 <bffcc1cd> [strlen]
0xbffcc186 (strlen+50:) movl (%edx),%eax
0xbffcc188 (strlen+52:) addl $0x4,%edx
0xbffcc18b (strlen+55:) leal 0xfefefeff(%eax),%ecx
0xbffcc191 (strlen+61:) notl %eax
0xbffcc193 (strlen+63:) andl %eax,%ecx
0xbffcc195 (strlen+65:) testl $0x80808080,%ecx
0xbffcc19b (strlen+71:) jne 0x30 <bffcc1cd> [strlen]
--> 0xbffcc19d (strlen+73:) movl (%edx),%eax
when called from doprnt from fprintf, it crashed here
0xbffcc19f (strlen+75:) addl $0x4,%edx
0xbffcc1a2 (strlen+78:) leal 0xfefefeff(%eax),%ecx
0xbffcc1a8 (strlen+84:) notl %eax
0xbffcc1aa (strlen+86:) andl %eax,%ecx
0xbffcc1ac (strlen+88:) testl $0x80808080,%ecx
0xbffcc1b2 (strlen+94:) jne 0x19 <bffcc1cd> [strlen]
0xbffcc1b4 (strlen+96:) movl (%edx),%eax
0xbffcc1b6 (strlen+98:) addl $0x4,%edx
0xbffcc1b9 (strlen+101:) leal 0xfefefeff(%eax),%ecx
0xbffcc1bf (strlen+107:) notl %eax
0xbffcc1c1 (strlen+109:) andl %eax,%ecx
0xbffcc1c3 (strlen+111:) testl $0x80808080,%ecx
0xbffcc1c9 (strlen+117:) jne 0x2 <bffcc1cd> [strlen]
0xbffcc1cb (strlen+119:) jmp 0x8b <bffcc158> [strlen]
0xbffcc1cd (strlen+121:) notl %eax
0xbffcc1cf (strlen+123:) testb %al,%al
0xbffcc1d1 (strlen+125:) je 0xe <bffcc1e1> [strlen]
0xbffcc1d3 (strlen+127:) incl %edx
0xbffcc1d4 (strlen+128:) testb %ah,%ah
0xbffcc1d6 (strlen+130:) je 0x9 <bffcc1e1> [strlen]
0xbffcc1d8 (strlen+132:) shrl $0x10,%eax
0xbffcc1db (strlen+135:) incl %edx
0xbffcc1dc (strlen+136:) testb %al,%al
0xbffcc1de (strlen+138:) je 0x1 <bffcc1e1> [strlen]
0xbffcc1e0 (strlen+140:) incl %edx
0xbffcc1e1 (strlen+141:) leal 0xfc(%edx),%eax
0xbffcc1e4 (strlen+144:) subl 0x4(%esp,1),%eax
0xbffcc1e8 (strlen+148:) ret
0xbffcc1e9 (strlen+149:) nop
0xbffcc1ea (strlen+150:) nop
0xbffcc1eb (strlen+151:) nop
0xbffcc1ec (__filbuf+0:) pushl %edi
debug>
-----------------------------------------------------------------
This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email
is strictly prohibited.
If you have received this email in error, please notify the
Thyron IT Administrator on +44 (0)1923 236 050 or
send an email to mail-admin@thyron.com.
Thank You