This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Random list of problems to fix for 64 bit Cygwin


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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]