From: Agner Fog <agner@agner.org>
To: Corinna Vinschen <corinna-cygwin@cygwin.com>,
"cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Re: Clang is using the wrong memory model
Date: Fri, 16 Aug 2019 09:52:00 -0000 [thread overview]
Message-ID: <8d594f4d-17e0-447a-8b18-1ed620815e0f@agner.org> (raw)
Message-ID: <20190816095200.R-lVkme0-80_7iXOV1HKVRLCkXJUWbZLN1bHc3unSc8@z> (raw)
In-Reply-To: <20190816082603.GR11632@calimero.vinschen.de>
Thanks for your replies.
A Cygwin application with -mcmodel=small appears to work fine.
As I explained, -mcmodel=small does something else when the target is
Windows. It does not require addresses to be below 2GB, it only requires
the distance between a code section and it's data section to be below 2GB.
Your concern would be right if -mcmodel=small was doing the same thing
as it does in Linux, but this is not the case.
It does not matter where the application and the Cygwin DLL are placed
because Windows allows EXEs and DLLs to be placed at any address. There
is no static linking between an application and the Cygwin DLL, so the
distance between application and DLL does not matter.
I don't see any problem with fork() either, because there is no static
link between parent and child process. The OS puts everything in place
using virtual addresses.
Agner
On 16/08/2019 10.26, Corinna Vinschen wrote:
> On Aug 16 08:06, Agner Fog wrote:
>> Cygwin Clang is using -mcmodel=medium as default for Win64, according to my
>> tests, while the right model is -mcmodel=small
> -mcmodel=small is *only* the right model if the target is native
> Windows. If the target is a Cygwin application it *must* at least
> be compiled with -mcmodel=medium. The reason is the standarized
> memory layout of Cygwin application and DLLs.
>
>> Linux Clang with --target=x86_64-pc-cygwin gives the small memory model.
> Which is wrong.
>
>> I took this to the LLVM Bugzilla as you asked me to:
>> https://bugs.llvm.org/show_bug.cgi?id=42983
>>
>> This gave the following conclusion:
>>
>> -mcmodel=small does something different when the target is Windows. This
>> difference appears to be undocumented. The small memory model with a Linux
>> target puts everything below the 2GB limit so that 32-bit absolute addresses
>> can be used. The small memory model with a Windows target is using 32-bit
>> relative addresses instead, which is the correct thing to do in Windows.
> Yes, but not for Cygwin applications and DLLs. The reason is that Cygwin
> apps and DLLs reside in the memory beyond the first 2 Gigs in a standarized
> way so as not to collide with Windows code and datastructures. And that
> in turn was necessary to make fork() more reliable on 64 bit.
>
> Here's the memory layout:
>
> 0000:00000000 Windows
> 0000:80000000 Thread stacks
> 0001:00400000 Executable
> 0001:80000000 *The* Cygwin DLL
> 0002:00000000 Rebased Cygwin DLLs
> 0004:00000000 Unrebased Cygwin DLLs(*)
>
> 0006:00000000 Heap (up to Cygwin 3.0)
> 0008:00000000 Heap (starting with Cygwin 3.1)
>
> 0700:00000000 Top-down start address for mmaps up to Windows 8
> or up to Cygwin 3.0
> 7000:00000000 Top-down start address for mmaps starting with Windows 8.1
> and Cygwin 3.1
>
> So there's a difference between non-Cygwin (-mcmodel=small as default)
> and Cygwin (at least -mcmodel=medium).
>
>
> 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
next prev parent reply other threads:[~2019-08-16 9:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1436640898.268382790.1565602671940.JavaMail.root@zimbra54-e10.priv.proxad.net>
2019-08-12 9:45 ` Inefficient use of 64-bit addresses in Clang falk.tannhauser
2019-08-14 5:51 ` Agner Fog
2019-08-16 6:06 ` Clang is using the wrong memory model Agner Fog
2019-08-16 8:25 ` Mark Geisert
2019-08-16 8:26 ` Corinna Vinschen
2019-08-16 9:27 ` Agner Fog [this message]
2019-08-16 9:52 ` Agner Fog
2019-08-16 10:39 ` Corinna Vinschen
2019-08-16 10:50 ` Agner Fog
2019-08-16 11:25 ` Corinna Vinschen
2019-08-16 13:28 ` Kai Tietz
2019-08-17 6:59 ` Agner Fog
2019-08-17 9:48 ` Corinna Vinschen
2019-08-18 11:37 ` Agner Fog
2019-08-18 11:58 ` Corinna Vinschen
2019-08-18 18:14 ` Agner Fog
2019-08-19 8:58 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d594f4d-17e0-447a-8b18-1ed620815e0f@agner.org \
--to=agner@agner.org \
--cc=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).