This is the mail archive of the
mailing list for the Cygwin project.
Re: New Cygwin family member
On Feb 5 22:14, Yaakov wrote:
> On Tue, 5 Feb 2013 21:04:11 -0500, Chris Sutcliffe wrote:
> > On 5 February 2013 12:57, Corinna Vinschen wrote:
> > > Not at all. For a start I'm planning to provide the toolchain patches
> > > and a binary cross toolchain x86_64-pc-linux -> x86_64-pc-cygwin this
> > > month.
> > For us poor schmucks stuck in the 32-bit world, I'm hoping there will
> > eventually be a 32-to-64 bit native cross compiler (i.e. a compiler
> > that will run in 32-bit Cygwin that produces 64-bit Cygwin binaries)?
> That will be possible as soon as the patches are released.
The patches will be relative to current binutils CVS / gcc SVN. I'd
love to publish the patches, but just yesterday we encountered a big
problem in terms of the auto-import mechanism which I really hope to fix
Without going into too much detail, the problem is that gcc references
external variables using pc-relative addressing with 32 bit displacement.
Only if a symbol is marked as dllimport, gcc will instead generate
indirect addressing opcodes. So, if a source uses some external
variable from a DLL, but neglects to declare it as dllimport symbol,
the following will happen:
extern char *optarg;
char *o = optarg;
This code will be translated into something along these lines:
movq optarg(%rip), %rax
The "optarg" here is a signed 32 bit displacement. However, if the
offset between executable and the exporting DLL (in this case the cygwin
DLL) is bigger than 32 bit, which is *pretty* likely, given that we
want to place our DLLs where Windows will not collide with us.
The end result is either a SEGV, if the resulting address is outside of
readable virtual mem, or an access to the wrong data.
The easy solution is to stick to the current methods and play the
"serves them right" card if they didn't declare the variable as
dllimport. However, from the POSIX POV the application didn't do
anything wrong. And apart from the fact that a SEGV in this seemingly
innocent situation is pretty mind-boggling, it's also quite annoying to
have working 32 bit code but crashing 64 bit code generated from the
That's why I hope we can come up with a better solution.
If anybody is interested in the patches in the current state, I can
send them to the list anyway, though.
> > I'm guessing we're a ways out from that point yet, but when we get to
> > the point where Cygwin is officially offered in both architectures,
> > will the ask be of the various maintainers to produce binaries for
> > both (I personally don't mind as long as the tools exist to do it).
> The problem is that not *everything* can be cross-compiled easily, if
> at all. Linux distributions generally use dedicated build
> machines/farms (e.g. koji for Fedora) for this very reason. This will
> certainly need to be addressed when the time comes.
Yeah. This will still be a heck of a lot of work. Given that "Hello
World" is barely a day old, you may understand that I didn't even dare
to call fork yet :}
Another really big problem is entirely unsolved yet: 32 and 64 bit
Cygwin processes execing each other, as well as working together.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com