DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=nfDPvFE/ZZVNMUVvi1Y3LbwY1o0S/w7T4Xn1uCnnSlcBqKig+ZJI6
	0EIsi9j4sZtt9N5XuPHO5gFVBc6Mcdi60eBMITSMCi80h7moJPjcgZGLiBAFmRxt
	IEnBDbHalNeijAf2vz3UrkN8GQmImCBry/fojSoE89cmlg2Hk+LdHQ=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Sun, 18 Aug 2019 13:57:39 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Agner Fog <agner@agner.org>
Cc: cygwin@cygwin.com
Subject: Re: Clang is using the wrong memory model
Message-ID: <20190818115739.GD11632@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: Agner Fog <agner@agner.org>, cygwin@cygwin.com
References: <024ce5b5-6024-b371-e382-5eef5d1d4a90@agner.org> <075477ca-e031-39ea-3dfe-bc8bc2fc8fa6@agner.org> <20190816082603.GR11632@calimero.vinschen.de> <8d594f4d-17e0-447a-8b18-1ed620815e0f@agner.org> <20190816095200.GU11632@calimero.vinschen.de> <2024f551-66e6-47c5-a0b6-2dfa735a690d@agner.org> <20190816111133.GV11632@calimero.vinschen.de> <6008d30a-cd6c-5449-2933-a041e804856c@agner.org> <20190817081605.GX11632@calimero.vinschen.de> <17081147-f46a-51bf-65e9-3df7748b1780@agner.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="8rwPx/46nQniO+If"
Content-Disposition: inline
In-Reply-To: <17081147-f46a-51bf-65e9-3df7748b1780@agner.org>
User-Agent: Mutt/1.11.3 (2019-02-01)

--8rwPx/46nQniO+If
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 18 08:04, Agner Fog wrote:
> Thanks a lot for your help in clarifying this.
>=20
> When I complained here about the wasteful 64-bit addresses you said that =
it
> was an LLVM issue.

I never said anything like that.  The issue is that your clang
linux->cygwin cross compiler uses the wrong model, that's all.  That's
a bug in clang or whatever it's using under the hood.  Clang should
follow what GCC does for years, using the medium model on Cygwin.

> When I complained to LLVM they said it was a Cygwin
> issue, and that you were using the wrong memory model.
>=20
> All this confusion is due to a terrible lack of documentation of everythi=
ng.
> I had to do a lot of reverse engineering to figure out what is happening.
> What I have found out so far is listed below. Much of this is undocumente=
d.
> Obviously, I would like to know if any or this is wrong or if specific
> documentation is available other than the SysV ABI and Windows ABI:
>=20
> * Cygwin is using its own loader which is different from the Windows load=
er.

Nope, Cygwin uses the Windows loader.

> * The Cygwin loader emulates the behavior of Linux shared objects. This
> includes the ability to directly access a variable inside a DLL

See above.

> * Access to a variable in a different DLL requires a 64-bit address. This=
 is
> obtained by using the medium memory model with a gcc or Clang compiler.

ACK

[...]

To me, the only interesting thing is that clang continues to use the
medium memory model *by default*.  It doesn't make sense if package
maintainers and devs building something on Cygwin have to care for
memory models all of a sudden.  The default should just work.

If you want to use the small model in your own projects, great, if it
works for you.  If the medium model is wasteful in clang, that's a clang
optimization problem, not a Cygwin problem.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--8rwPx/46nQniO+If
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1ZPTMACgkQ9TYGna5E
T6D08BAAi4Ku6fh5JO71bC0SPInBqOzlfStLX0pj1mMcAYwm+z/DDOBYp8J0nCRB
umM7wFhYGc2qKZAMvCvB8b3u2pbxQqlZg2Wxd/rvJlDTuhnVWglrU4Rb4+8aN25M
z+W7M928x0vjDJpyeSOUr7A1KLyzMKvHQ1keJ4jts+LETOWPAI/gJK0mGsezWtGz
8NZgrR5U3siJ0C02QF69pMeGwn53n7bMHcjtTzKJ2vVvNroe2qcB1T1RxL8R9GBE
5/HcwqQ31ZpcJwhbLPbKj7yjOE62FwTlv+CsidnlvD4Ej8Tj192sPYxEWKNfaKt8
yIT31Ubc6hJCA5BLAgDMi+ep3b2L3wjmouiSRt83RObY8sJMGupVL6UFN6u6uJV0
22gpUJdDyVb6OvtnSkeUgzyg7M9Cq+HDKORHIVy1hhiD0DRyqgA3zKam2b2K2e/+
U8mSb8l9VO6oxfHpRACe3Qyw9369OiUO2d5GKDUCZc+FuLeQC6ygBcw3No7Xyw1E
WvlsJzK5hv4GszyBtrXWtj6rzwte+pZMoCRN+GDQzCm+ZaWXrivE534Hdbm+1dBt
YbYWpI5+bKYmWqomvD+j/F3WeMecpABXGoLwD3LIoQm8ezFyJ6qrVi98MDFmEl4S
VLX9LkB3TN6KntiIuKYz/LglfQeOzLoXss6rS9jswN0zljylCns=
=B9Ns
-----END PGP SIGNATURE-----

--8rwPx/46nQniO+If--