X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Message-ID: <505D5014.6000708@iki.fi>
Date: Sat, 22 Sep 2012 08:43:48 +0300
From: Andris Pavenis <andris DOT pavenis AT iki DOT fi>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: gcc behaviour if djgpp.env is not available.
References: <201208302244 DOT 31877 DOT juan DOT guerrero AT gmx DOT de> <50420942 DOT 7090804 AT iki DOT fi> <d1600e79-e7b5-4284-a1dd-96abb6788e3f AT a1g2000vbk DOT googlegroups DOT com>
In-Reply-To: <d1600e79-e7b5-4284-a1dd-96abb6788e3f@a1g2000vbk.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

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