Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Mon, 25 Mar 2024 16:39:23 +0000
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <uts9br$16nq5$1@dont-email.me>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
 <20240320114218.151@kylheku.com>
 <20240321211306.779b21d126e122556c34a346@gmail.moc>
 <utkea9$31sr2$1@dont-email.me> <utktul$35ng8$1@dont-email.me>
 <utm06k$3glqc$1@dont-email.me> <utme8b$3jtip$1@dont-email.me>
 <utn1a0$3ogob$1@dont-email.me> <utnh5m$3sdhk$1@dont-email.me>
 <utpenn$dtnq$1@dont-email.me> <utq0gh$i9hm$1@dont-email.me>
 <utqaak$kfuv$2@dont-email.me> <20240325141628.00006170@yahoo.com>
 <utrqgp$12v02$1@dont-email.me> <20240325161117.00002318@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Mar 2024 17:39:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f53bde5462ef908e46a536c53c557cbe";
	logging-data="1269573"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19f48nYUvGtBykuMpeMqLy8"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JHYu16MwlSx4+1OwYEe6PIX2KGM=
In-Reply-To: <20240325161117.00002318@yahoo.com>
Content-Language: en-GB
Bytes: 3458

On 25/03/2024 13:11, Michael S wrote:
> On Mon, 25 Mar 2024 13:26:01 +0100
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 25/03/2024 12:16, Michael S wrote:
>>> On Sun, 24 Mar 2024 23:43:32 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> I could be  wrong here, of course.
>>>>   
>>>
>>> It seems, you are.
>>>    
>>
>> It happens - and it was not unexpected here, as I said.  I don't have
>> all these compilers installed to test.
>>
>> But it would be helpful if you had a /little/ more information.  If
>> you don't know why some compilers generate binaries that have memory
>> mapped at 0x400000, and others do not, fair enough.  I am curious,
>> but it's not at all important.
>>
> 
> I am not an expert, but it does not look like the problem is directly
> related to compiler or linker. All 32-bit Windows compilers/linkers,
> including gcc, clang and MSVC, by default put symbol ___ImageBase at
> address 4 MB. However loader relocates it to wherever it wants,
> typically much higher.
> I don't know for sure why loader does it to images generated by gcc,
> clang and MSVC and does not do it to images generated by lccwin and
> others, but I have an educated guess: most likely, these other compilers
> link by default with an option similar to Microsoft's /Fixed
> https://learn.microsoft.com/en-us/cpp/build/reference/fixed-fixed-base-address?view=msvc-170

It's all up to the options written to the EXE file headers.

By setting the same options (plus generating base-reloc tables, plus 
ensuring the code can run above 2GB), I can get the EXEs written by my 
two compilers (for C and for my language) to be loaded at a high address 
too.

My compilers don't use a linker.

Some of those options are normally used only for DLLs; they would need 
to be set for EXEs too.

This was just an experiment; I will try adding it as a formal option to 
each compiler.