Mail Archives: djgpp/2012/09/22/01:44:13
On 09/02/2012 01:11 AM, Juan Manuel Guerrero wrote:
> On 1 Sep., 15:22, Andris Pavenis <andris DOT pave DOT DOT DOT AT iki DOT fi> wrote:
>> On 30.8.2012 23:44, Juan Manuel Guerrero wrote:
>>
>>> I do not know if this issue has already been discused but I have noticed
>>> that the DJGPP port of gcc crashes if it does not find djgpp.env. If gcc
>>> needs to load djgpp.env and fails, would not it be better that it issues
>>> some kind of error message instead of crashing?
>>> For an user not familiar with DJGPP it would be hard to figure out
>>> what has gone wrong.
>>
>>> The output below is produced by gcc471b on WinXP after having deleted
>>> djgpp.env.
>>
>> Did some debugging (gdb xgcc.exe, command line parameters -B./
>> -print-prog-name=cc1)
>>
>> The crash is in src/crt0/crt0.S in dos_alloc_ok().
> [snip]
>
> Unfortunately I am not familiar at all with the assembler stuff
> in src/crt0/crt0.S. Have we to fix something or is there something
> brocken in gcc itself?
>
Tried to debug the issue. I was wrong. It is not crt0.S issue but
simply call to wild pointer which causes jump to pointer inside crt0.S.
The real reason is using macro GCC_DRIVER_HOST_INITIALIZATION macro before
diagnostic output is set up which results in use of uninitialized data
as the mentioned macro calls fatal_error() to report DJGPP setup error.
In upcoming GCC-4.8.0 the order is
/* Unlock the stdio streams. */
unlock_std_streams ();
gcc_init_libintl ();
diagnostic_initialize (global_dc, 0);
#ifdef GCC_DRIVER_HOST_INITIALIZATION
/* Perform host dependent initialization when needed. */
GCC_DRIVER_HOST_INITIALIZATION;
#endif
so it is not surprising that that there were no similar problems
with gcc-4.8.0 snapshots.
So the fix is to backport gcc-4.8.0 change to 4.7.
Andris
- Raw text -