Random list of problems to fix for 64 bit Cygwin

[Corinna Vinschen]

Hi,


this is just a short list of stuff which still has to be worked out for
64 bit Cygwin. This also serves as a kind of TODO list. I appreciate
any serious input.

Apart from that, there's a development branch in the CVS repo called
cygwin-64bit-branch. It contains all the code changes so far to get
64 bit Cygwin working. It's still a long way, though. I also
appreciate any help in terms of patches or reviews.

If anybody wants to take a shot on building the branch on 64 bit, I have
to say that it's not yet quite simple. So far we only have preliminary
binutils and a x86_64-pc-cygwin GCC based on GCC 4.8.0, built as Linux
cross tools. There's no libgcc or anything you can call a target lib
available yet, just bare tools.

Having said that, if anybody is interested to get the stuff and lay
hands on the 64 bit code, I can provide the rather small set of patches
plus a generic build script, or even the binaries (better: all of the
installed toolchain required) for x86_64 Fedora 17. But earliest on
Monday.

Ok, now the list. Beware, it's not pretty or, FWIW, sorted.

- How to arrange memory layout? Where to load Cygwin DLL? Where to
start the POSIX heap?

We have a 43 bit address space. Low addresses up to 0x80000000 should
be treated as taken since on some systems 64 bit Windows DLL are
loaded into the same addresses as on 32 bit systems. Plus heaps,
stacks, executable. High addresses are taken by PEB and TEB and
Windows DLLs.

On stock Windows 8, most system DLLs seem to be rebased only lazily.
Addresses of 0x1:00e00000 (added colon for readability) up to
0x1:800e3000 are used by most of them. However, the system uses a
spiffy algorithm to place the DLLs in memory, apparently, since all of
them are at addresses beyond 0x7f0:00000000 when observing running
processes.

So, in theory we could treat the area between 0x2:00000000 and, let's
say, 0x700:00000000 as our own and divide it beforehand into the
areas used for the Cygwin DLL, other Cygwin DLLs, the user heap, etc.

- Fix cygwin.din for 64 bit. Remove undefined functions. Fix DLL
address accoring to result of aforementioned mem layout problem.

- In the same vain, provide a cygwin64.sc linker script.

- sizeof(msqid_ds), sizeof(semid_ds), sizeof(shmid_ds) is different
due to time_t being different. This affects communication with
cygserver. A 64 bit cygserver must test if a client is a wow64
client and, if so, convert the 32 bit to a 64 bit *_ds struct.

- Heap info in format_process_maps must be rewritten to fetch the
heap information from the target process. The reason is outlined
in fhandler_process.cc, about line 570.
Alternatively: Drop printing Windows heap info?

- How to propagate cygheap info from a 64 bit parent to a 32 bit
child and vice versa on spawn/exec? Different size of types
(pointers, HANDLE, long) as well as different cygheap addresses are
to be taken into account.

- Make sure shared data contains no pointers only offsets, if at all.

- Check *all* FOO_printf calls for matching type definitions on both
platforms in the format string.

- Fix gendef, gentls_offsets, dllfixdbg to work on 64 bit.

Right now I can't come up with more, but there is more for sure.


Corinna