Mail Archives: djgpp-workers/2001/08/01/08:11:24
> > Instead of modifying allot of the GCC files to include the crt0 startup
flag
> > I hacked crt1.c so that what ever I built GCC (except redir) it would
> > include the unixy sbrk. After building GCC I thought I would re-build
make
> > from the ground up for regression testing with the latest LIBC and the
> > regression testing did not find any changes compared to the previous
build
> > that I had not allready seen.
> >
> > The crash still occured in gcc1.exe, even with the re-built GCC and
make.
>
> So do I understand correctly that Make, either rebuilt with the Unixy
> sbrk flag set in its main function, or linked with hacked up crt1.c which
> makes Unixy sbrk the default, does not crash? And that cc1.exe, even
> after rebuilding it, still crashes with the same traceback which shows
> address wrap-around?
I think you are correct in spotting Make does not crash with the Unixy sbrk
flag set. Let me run a series of tests again with the following combination,
this may take a few days:
1) Make & GCC - no Unixy SBRK, no malloc_debug
2) Make & GCC - no Unixy SBRK, malloc_debug set to 4 for both
3) Make & GCC - Unixy SBRK set, no malloc_debug
4) Make & GCC - Unixy SBRK set, malloc_debug set to 4 for make only
5) Make & GCC - Unixy SBRK set, malloc_debug set to 4 for both make and GCC
Are there any other combinatios that would help give more info?
This may take me a three or four days to complete as I need build GCC and
Make 4 times to get the combinations required. I will double check the
correct exe's are installed before before running the tests.
> > What next? Any other tests or suggestions?
>
> I'm guessing that somehow the Unixy sbrk flag is not being set in
> cc1.exe. To see if this is so, please run the rebuilt cc1.exe under GDB,
> put a breakpoint on the function called `start' (that's the entry point
> to every DJGPP program), and when the breakpoint breaks, please print the
> value of __crt0_startup_flags and see if the Unixy sbrk bit is set.
Both make.exe and cc1.exe have _crt0_startup_flags set to 0x800 (2048).
Command prompt info from the GDB session is:
DJGPP_204 D:\dj204\gnu\make-3.791>gdb make.exe
....CUT GNU gdb 5.0 info...
(gdb) break main
Breakpoint 1 at 0xd8fc: file main.c, line 807.
(gdb) run
Starting program: d:/dj204/gnu/make-3.791/make.exe
Breakpoint 1, main (argc=1, argv=0xc62f0, envp=0xc56b8) at main.c:807
807 make up for the dumb default shell. */
(gdb) print _crt0_startup_flags
$1 = 2048
(gdb)
DJGPP_204 D:\dj204\lib\gcc-lib\djgpp\2.953>gdb cc1.exe
....CUT GNU gdb 5.0 info...
(gdb) break main
Breakpoint 1 at 0xc4e5
(gdb) run
Starting program: d:/dj204/lib/gcc-lib/djgpp/2.953/cc1.exe
Breakpoint 1, 0xc4e5 in main ()
(gdb) print _crt0_startup_flags
$1 = 2048
(gdb)
> Also, please make sure that the cc1.exe binary which gets run and crashes
> when you try to rebuild Make is the same binary you built with the
> hacked up version of crt1.c. (Sorry for asking the obvious ;-)
It's the only one that is on the DJGPP directory on the Windows 2000 PC.
> > Should I now try to get RHIDE to
> > rebuild and then test it on Win2000 and wait to see if RHIDE shows
different
> > symptoms or different issues?
>
> I'd suggest to stay with GCC for now. Adding RHIDE to the equation would
> force us deal with too many unknowns.
I get the feeling that I am starting to go arround in circles, but sometimes
this is required in order to double check the test and results the first
time were not a one off.
- Raw text -