X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Zt9yHO5EekPOs29Y
	0i4oECR6rHdqdvqmRLWDW3H7aoSoRIjRyegDeeQihQBQ7K9KZScLilVtA2GNJtOq
	Nwyvop/TWEhI697HblX4sPfKZP60NkyF5wayluvs+lNGTfGZEo1pmJyLfKQUHcYZ
	9nLq+naHZwFsUv7o+YTjvNFHPdk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=YvsYGz/O/fuudq5gM3pVuX
	2w1RM=; b=ISJAu16VnO7IXEJBawuww0kJ8hID6DHUPbpL/tz7J0IGwjtxlefciJ
	prFKsMTTxPzGzB9muUsnd4VS/3NNsfIqpDANeD0lXVsuTHdHAeN1L+oEEAvvSIls
	Z1tG2b/SNGTe2HsYRPAn13aCwzm/rjOlYrGefgE3ltlLWAlCjq2Is=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*c:alternative
X-HELO: gateway24.websitewelcome.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=agner.org;	 s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:	References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID	:Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:	Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe	:List-Post:List-Owner:List-Archive;	bh=wb71kSHHUNb2DwyswfAdh8gXdMCZZNb4VyFlB06eq/8=; b=XGgVTaJzrQq472/nEUWftyfJVX	iiQu8ltgMS0/XZ19RQoI/E54ML99OW32TTgcfXss/tN3y0FpCfP2a56LY1OV4q1fLL5waWhQ5/Agr	wbmCmmmC/Kb3ukhKcceyF73Fdx9XGwTsi63V4A/0uuQHv3gW9VeW+iAj4uJzc5cK4RHRkKaCLlIhb	iJ2C+8Pw24sbgw+HDEubE5Er41HYwl8c6nLVyEVhg56YiUiTBIREbto5uEvs8v1f4DWkvuUxCcqP9	LI9G50A4aCRnAk5dyQc5gLz3+X3LIlPsQRhEoOSW+3FKXz8adzYvoP9SXBoDmIVpdD60XQSjUE8gh	9DXaDdTQ==;
Subject: Re: Clang is using the wrong memory model
To: cygwin AT cygwin DOT com
References: <732305300 DOT 268416262 DOT 1565603129541 DOT JavaMail DOT root AT zimbra54-e10 DOT priv DOT proxad DOT net> <024ce5b5-6024-b371-e382-5eef5d1d4a90 AT agner DOT org> <075477ca-e031-39ea-3dfe-bc8bc2fc8fa6 AT agner DOT org> <20190816082603 DOT GR11632 AT calimero DOT vinschen DOT de> <8d594f4d-17e0-447a-8b18-1ed620815e0f AT agner DOT org> <20190816095200 DOT GU11632 AT calimero DOT vinschen DOT de> <2024f551-66e6-47c5-a0b6-2dfa735a690d AT agner DOT org> <20190816111133 DOT GV11632 AT calimero DOT vinschen DOT de>
From: Agner Fog <agner AT agner DOT org>
Message-ID: <6008d30a-cd6c-5449-2933-a041e804856c@agner.org>
Date: Sat, 17 Aug 2019 07:31:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190816111133.GV11632@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

> So errno was a bad example but you can try accessing e.g. __ctype_ptr__,
> __progname, optarg, h_errno, or use FE_DFL_ENV from another DLL, just
> for kicks.
__ctype_ptr__ is a function

h_errno works like errno with an imported function

FE_DFL_ENV is a macro

__progname and optarg are local variables to each exe or dll


Note that the 2GB limit applies to_static linking_, not to_dynamic linking_.

Allow me to explain the difference. Static linking is the linking of object files together into an EXE or DLL file. Dynamic linking is the linking between different EXE or DLL files.

Static linking is done by the linker. If function A() in a.cpp is calling function B() in b.cpp, then you can compile and link a.cpp and b.cpp together into ab.exe, using the linker. The linker will insert the relative address of B by directly modifying the call B instruction in a.o. The linker will give an error message if the address overflows beyond the 2GB limit. The same process applies when linking to a global variable in b.cpp. The call instruction always uses a 32-bit relative address. The link to a variable can use different addressing modes: 32-bit absolute address, 32-bit relative address, and 64-bit absolute address. The 32-bit absolute address can be used in Linux, but not in Win64 and MacOS. This is why the small memory model is different in Linux and Windows (64 bit).

Dynamic linking is done by the loader, not the linker. If a function in ab.exe calls function C() in C.DLL, then the process is different. D.DLL is loaded by the loader, and the address of C() is inserted into an import table. The import table contains 64-bit absolute addresses.

It is not possible to insert the address of a function or variable from a different EXE or DLL directly into a code instruction. The loader simply cannot do this, only the linker can.

This is the reason why the link to errno and other seemingly global variables are replaced by functions. errno was not a bad example, it shows how a variable in a different DLL is accessed.

gcc is using the small memory model by default in Cygwin64, and it works.

clang is using the small memory by default when cross-compiling for a Cygwin64 target from Linux, and it works.

Kai Tietz wrote:
>   Another thing, which
> cygwin depends heavily on is the pseudo-relocation stuff.  It is not
> guaranteed that code distance between DSOs are in valid range here to
> fit in a single instruction to be relocated.  So the distance allowed
> for a "small model instruction" might be in some cases even less 4 GB.
> For pseudo-relocation the large memory model is absolutely mandatory
> for bigger application.
Kai, can you please point me to a description of the DSO and pseudo-relocation. I cannot find it. But I suppose it inserts 64-bit addresses into some sort of GOT or PLT without using the traditional linker.

Agner


On 16/08/2019 13.11, Corinna Vinschen wrote:
> On Aug 16 12:38, Agner Fog wrote:
>> On 16/08/2019 11.52, Corinna Vinschen wrote:
>>> 2 GB. Think errno accessed from another DLL. Your application works only
>>> by chance.
>> Good example.
>>
>> errno appears to be a global variable for historical reasons, but errno is
>> implemented as a macro that translates to a call to the imported function
>> __errno.
>>
>> This function call goes through a 64-bit import table from cygwin1.dll
>>
>> Works fine with -mcmodel=small
>>
>> Static sharing of a global variable between exe and dll, or between
>> different dll's is not possible.
> So errno was a bad example but you can try accessing e.g. __ctype_ptr__,
> __progname, optarg, h_errno, or use FE_DFL_ENV from another DLL, just
> for kicks.
>
> Just because lots of stuff works with the small mode doesn't mean it's
> the right thing to do.  Mcmodels medium and large have been introduced
> into GCC during the Cygwin 64 bit port for a reason.
>
>
> Corinna
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple