Re: a.out.h for 64-bit Cygwin?

2013-03-11 Thread Ken Brown

On 3/10/2013 4:52 PM, Corinna Vinschen wrote:

On Mar 10 09:06, Ken Brown wrote:

On 3/10/2013 7:18 AM, Corinna Vinschen wrote:

On Mar  9 22:43, Ken Brown wrote:

It may be too soon to expect this to work, but I'm trying to build
emacs for 64-bit Cygwin.  Part of the build process involves direct
manipulation of a .exe file, based on the structures defined in
/usr/include/a.out.h.  I'm wondering whether this file needs to be
updated before it will work with 64-bit .exe files.


Yes, absolutely!

It's not very tricky.  AFAIK only a single header part is different, the
one called IMAGE_OPTIONAL_HEADER in MSDN.  Given the age of a.out.h,
there are also a couple of defines missing, all of them are documented
in MSDN and available in the Mingw headers.  Patches most welcome.


OK, I'll work on this.  One question: Is it OK for a.out.h to
include windows.h so that I can use macros like WORD, DWORD,... as
in the Mingw headers?  Or is it better to just use standard types as
in the current a.out.h?


No, we shouldn't include windows.h.  Some of the values are already
defined using another name in a.out.h, see I386MAGIC, DOSMAGIC, or
NT_SIGNATURE.

I'm pretty open to add definitions for other values, as long as they
either match the already used naimg scheme, or, if they are entirely
new, are similar, but not exactly named like the original Windows
definitions.  I don't think anything speaks against adding stuff like

   #define AMD64MAGIC 0x8664
   [...]
   #define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
   [...]
   #define IMG_SUBSYS_NATIVE 1


OK, my patch is attached.  I'm also attaching the program I used to test 
it, based on the emacs code I sent in my first post.  (And I'm able to 
build 64-bit emacs with this patch.)


It turned out that the most important thing I had to do was change most 
occurrences of unsigned long to uint32_t to keep DWORDs from 
becoming 64 bits wide on AMD64.


Ken

#include stdio.h
#include unistd.h
#include assert.h
#include fcntl.h
#include a.out.h

typedef struct
{
  FILHDR file_header;
  PEAOUTHDR file_optional_header;
  SCNHDR section_header[32];
} exe_header_t;

static exe_header_t *
read_exe_header (int fd, exe_header_t * exe_header_buffer)
{
  int i;
  int ret;

  assert (exe_header_buffer != 0);

  ret = lseek (fd, 0L, SEEK_SET);
  assert (ret != -1);

  ret =
read (fd, exe_header_buffer-file_header,
  sizeof (exe_header_buffer-file_header));
  assert (ret == sizeof (exe_header_buffer-file_header));

  assert (exe_header_buffer-file_header.e_magic == 0x5a4d);
  assert (exe_header_buffer-file_header.nt_signature == 0x4550);
#ifdef __x86_64__
  assert (exe_header_buffer-file_header.f_magic == 0x8664);
#else
  assert (exe_header_buffer-file_header.f_magic == 0x014c);
#endif
  assert (exe_header_buffer-file_header.f_nscns  0);
  assert (exe_header_buffer-file_header.f_nscns =
  sizeof (exe_header_buffer-section_header) /
  sizeof (exe_header_buffer-section_header[0]));
  assert (exe_header_buffer-file_header.f_opthdr  0);

  ret =
read (fd, exe_header_buffer-file_optional_header,
  sizeof (exe_header_buffer-file_optional_header));
  assert (ret == sizeof (exe_header_buffer-file_optional_header));

#ifdef __x86_64__
  assert (exe_header_buffer-file_optional_header.magic == 0x020b);
#else
  assert (exe_header_buffer-file_optional_header.magic == 0x010b);
#endif
  for (i = 0; i  exe_header_buffer-file_header.f_nscns; ++i)
{
  ret =
read (fd, exe_header_buffer-section_header[i],
  sizeof (exe_header_buffer-section_header[i]));
  assert (ret == sizeof (exe_header_buffer-section_header[i]));
}

  return (exe_header_buffer);
}

int
main ()
{
  int fd;
  exe_header_t exe_header_buffer;

  printf (Type PEAOUTHDR has size %u bytes.\n, sizeof (PEAOUTHDR));
  fd = open (/bin/ls.exe, O_RDONLY);
  assert (fd = 0);
  read_exe_header (fd, exe_header_buffer);
}
--- a.out.h.orig2013-03-11 05:25:59.339893700 -0400
+++ a.out.h 2013-03-11 12:03:48.509132100 -0400
@@ -1,6 +1,6 @@
 /* a.out.h
 
-   Copyright 1997, 1998, 1999, 2001 Red Hat, Inc.
+   Copyright 1997, 1998, 1999, 2001, 2013 Red Hat, Inc.
 
 This file is part of Cygwin.
 
@@ -14,10 +14,13 @@
 #ifdef __cplusplus
 extern C {
 #endif
+
+#include stdint.h
+
 #define COFF_IMAGE_WITH_PE
 #define COFF_LONG_SECTION_NAMES
 
-/*** coff information for Intel 386/486.  */
+/*** coff information for Intel 386/486 and AMD64.  */
 
 
 /** FILE HEADER **/
@@ -25,9 +28,9 @@
 struct external_filehdr {
   short f_magic;   /* magic number */
   short f_nscns;   /* number of sections   */
-  unsigned long f_timdat;  /* time  date stamp*/
-  unsigned long f_symptr;  /* file pointer to symtab   */
-  unsigned long f_nsyms;   /* number of symtab entries */
+  uint32_t f_timdat;   /* time  date stamp*/
+  uint32_t f_symptr;   /* file pointer to symtab   */
+  

Re: a.out.h for 64-bit Cygwin?

2013-03-11 Thread Corinna Vinschen
On Mar 11 12:13, Ken Brown wrote:
 On 3/10/2013 4:52 PM, Corinna Vinschen wrote:
 No, we shouldn't include windows.h.  Some of the values are already
 defined using another name in a.out.h, see I386MAGIC, DOSMAGIC, or
 NT_SIGNATURE.
 
 I'm pretty open to add definitions for other values, as long as they
 either match the already used naimg scheme, or, if they are entirely
 new, are similar, but not exactly named like the original Windows
 definitions.  I don't think anything speaks against adding stuff like
 
#define AMD64MAGIC 0x8664
[...]
#define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
[...]
#define IMG_SUBSYS_NATIVE 1
 
 OK, my patch is attached.  I'm also attaching the program I used to
 test it, based on the emacs code I sent in my first post.  (And I'm
 able to build 64-bit emacs with this patch.)
 
 It turned out that the most important thing I had to do was change
 most occurrences of unsigned long to uint32_t to keep DWORDs
 from becoming 64 bits wide on AMD64.
 
 Ken

Hi Ken.  Thanks for the patch, but I guess you misunderstood me
concerning the names of the defines:

  #define  I386MAGIC   0x14c
  #define I386PTXMAGIC 0x154
  #define I386AIXMAGIC 0x175
 +#define IMAGE_FILE_MACHINE_I386 0x014c
 +#define IMAGE_FILE_MACHINE_AMD64 0x8664
 +#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
 +#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
 +#define IMAGE_SIZEOF_STD_OPTIONAL_HEADER 28
 +#define IMAGE_SIZEOF_NT_OPTIONAL32_HEADER 224
 +#define IMAGE_SIZEOF_NT_OPTIONAL64_HEADER 240
 +#define IMAGE_SUBSYSTEM_NATIVE 1
 +#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2
 +#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3

The idea was to use names different from the original Windows defines.
IMAGE_FILE_MACHINE_I386 already exists as I386MAGIC, so the AMD64
definition should follow the lead:

  #define   AMD64MAGIC  0x8664

And the IMAGE_foo definitions would collide with Windows if the
Windows headers are included as well, so we should better use
IMG_foo rather than IMAGE_foo.

The rest of the patch looks good to me.  I'm just wondering what to
do with the mix of `unsigned {short,long}' and uint32_t.  Wouldn't
it be better if we replace all unsigned short with uint16_t and all
unsigned long with uintptr_t?


Corinna

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


Re: a.out.h for 64-bit Cygwin?

2013-03-11 Thread Corinna Vinschen
On Mar 11 18:43, Corinna Vinschen wrote:
 On Mar 11 12:13, Ken Brown wrote:
  OK, my patch is attached.  I'm also attaching the program I used to
  test it, based on the emacs code I sent in my first post.  (And I'm
  able to build 64-bit emacs with this patch.)
  
  It turned out that the most important thing I had to do was change
  most occurrences of unsigned long to uint32_t to keep DWORDs
  from becoming 64 bits wide on AMD64.
  
  Ken
 
 Hi Ken.  Thanks for the patch, but I guess you misunderstood me
 concerning the names of the defines:
 
   #defineI386MAGIC   0x14c
   #define I386PTXMAGIC   0x154
   #define I386AIXMAGIC   0x175
  +#define IMAGE_FILE_MACHINE_I386 0x014c
  +#define IMAGE_FILE_MACHINE_AMD64 0x8664
  +#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
  +#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
  +#define IMAGE_SIZEOF_STD_OPTIONAL_HEADER 28
  +#define IMAGE_SIZEOF_NT_OPTIONAL32_HEADER 224
  +#define IMAGE_SIZEOF_NT_OPTIONAL64_HEADER 240
  +#define IMAGE_SUBSYSTEM_NATIVE 1
  +#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2
  +#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3
 
 The idea was to use names different from the original Windows defines.
 IMAGE_FILE_MACHINE_I386 already exists as I386MAGIC, so the AMD64
 definition should follow the lead:
 
   #define AMD64MAGIC  0x8664
 
 And the IMAGE_foo definitions would collide with Windows if the
 Windows headers are included as well, so we should better use
 IMG_foo rather than IMAGE_foo.
 
 The rest of the patch looks good to me.  I'm just wondering what to
 do with the mix of `unsigned {short,long}' and uint32_t.  Wouldn't
 it be better if we replace all unsigned short with uint16_t and all
 unsigned long with uintptr_t?

If that's not clear, I mean the unsigned long's which are still unsigned
long after your patch, because they are 32 bit on i686 and 64 bit on
x86_64...


Corinna

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


Re: a.out.h for 64-bit Cygwin?

2013-03-11 Thread Ken Brown

On 3/11/2013 1:43 PM, Corinna Vinschen wrote:

On Mar 11 12:13, Ken Brown wrote:

On 3/10/2013 4:52 PM, Corinna Vinschen wrote:

No, we shouldn't include windows.h.  Some of the values are already
defined using another name in a.out.h, see I386MAGIC, DOSMAGIC, or
NT_SIGNATURE.

I'm pretty open to add definitions for other values, as long as they
either match the already used naimg scheme, or, if they are entirely
new, are similar, but not exactly named like the original Windows
definitions.  I don't think anything speaks against adding stuff like

   #define AMD64MAGIC 0x8664
   [...]
   #define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
   [...]
   #define IMG_SUBSYS_NATIVE 1


OK, my patch is attached.  I'm also attaching the program I used to
test it, based on the emacs code I sent in my first post.  (And I'm
able to build 64-bit emacs with this patch.)

It turned out that the most important thing I had to do was change
most occurrences of unsigned long to uint32_t to keep DWORDs
from becoming 64 bits wide on AMD64.

Ken


Hi Ken.  Thanks for the patch, but I guess you misunderstood me
concerning the names of the defines:


Yes, I did misunderstand.  Re-reading what you wrote, it was quite clear.


The rest of the patch looks good to me.  I'm just wondering what to
do with the mix of `unsigned {short,long}' and uint32_t.  Wouldn't
it be better if we replace all unsigned short with uint16_t and all
unsigned long with uintptr_t?


Yes, that's much better.  I also changed a couple of occurrences of 
`short' (without `unsigned') that should have been unsigned to begin with.


A revised patch is attached.

Ken
--- a.out.h.orig2013-03-11 05:25:59.339893700 -0400
+++ a.out.h 2013-03-11 15:05:56.968204200 -0400
@@ -1,6 +1,6 @@
 /* a.out.h
 
-   Copyright 1997, 1998, 1999, 2001 Red Hat, Inc.
+   Copyright 1997, 1998, 1999, 2001, 2013 Red Hat, Inc.
 
 This file is part of Cygwin.
 
@@ -14,22 +14,25 @@
 #ifdef __cplusplus
 extern C {
 #endif
+
+#include stdint.h
+
 #define COFF_IMAGE_WITH_PE
 #define COFF_LONG_SECTION_NAMES
 
-/*** coff information for Intel 386/486.  */
+/*** coff information for Intel 386/486 and AMD64.  */
 
 
 /** FILE HEADER **/
 
 struct external_filehdr {
-  short f_magic;   /* magic number */
-  short f_nscns;   /* number of sections   */
-  unsigned long f_timdat;  /* time  date stamp*/
-  unsigned long f_symptr;  /* file pointer to symtab   */
-  unsigned long f_nsyms;   /* number of symtab entries */
-  short f_opthdr;  /* sizeof(optional hdr) */
-  short f_flags;   /* flags*/
+  uint16_t f_magic;/* magic number */
+  uint16_t f_nscns;/* number of sections   */
+  uint32_t f_timdat;   /* time  date stamp*/
+  uint32_t f_symptr;   /* file pointer to symtab   */
+  uint32_t f_nsyms;/* number of symtab entries */
+  uint16_t f_opthdr;   /* sizeof(optional hdr) */
+  uint16_t f_flags;/* flags*/
 };
 
 /* Bits for f_flags:
@@ -50,6 +53,16 @@
 #defineI386MAGIC   0x14c
 #define I386PTXMAGIC   0x154
 #define I386AIXMAGIC   0x175
+#define AMD64MAGIC 0x8664
+
+#define IMG_NT_OPTIONAL_HDR32_MAGIC 0x10b
+#define IMG_NT_OPTIONAL_HDR64_MAGIC 0x20b
+#define IMG_SIZEOF_STD_OPTIONAL_HEADER 28
+#define IMG_SIZEOF_NT_OPTIONAL32_HEADER 224
+#define IMG_SIZEOF_NT_OPTIONAL64_HEADER 240
+#define IMG_SUBSYSTEM_NATIVE 1
+#define IMG_SUBSYSTEM_WINDOWS_GUI 2
+#define IMG_SUBSYSTEM_WINDOWS_CUI 3
 
 /* This is Lynx's all-platform magic number for executables. */
 
@@ -70,14 +83,14 @@
 
 typedef struct
 {
-  unsigned short magic;/* type of file 
*/
-  unsigned short vstamp;   /* version stamp*/
-  unsigned longtsize;  /* text size in bytes, padded to FW 
bdry*/
-  unsigned longdsize;  /* initialized data   
*/
-  unsigned longbsize;  /* uninitialized data 
*/
-  unsigned longentry;  /* entry pt.
*/
-  unsigned long text_start;/* base of text used for this file */
-  unsigned long data_start;/* base of data used for this file=
+  uint16_t magic;  /* type of file */
+  uint16_t vstamp; /* version stamp*/
+  uint32_t tsize;  /* text size in bytes, padded to FW bdry*/
+  uint32_t dsize;  /* initialized data   */
+  uint32_t bsize;  /* uninitialized data */
+  uint32_t entry;  /* entry pt.*/
+  uint32_t text_start; /* base of text used for this file */
+  uint32_t data_start; /* base of data used for this file=
  */
 }
 AOUTHDR;
@@ -103,16 +116,16 @@
 
 struct external_scnhdr {
   

Re: GCC 4.7 and dependencies

2013-03-11 Thread Dave Korn
On 11/03/2013 23:40, Yaakov (Cygwin/X) wrote:
 JonY, Achim, and others,
 
 I have updated .cygport and patch files for GCC and its dependencies:
 
 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc

  I'm trying to look at this, but all I get is errors:

 $ git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc4
 Cloning into gcc4...
 fatal: The remote end hung up unexpectedly

 $

  Is there something wrong with the format of the git: URL I'm using?

cheers,
  DaveK



Re: [ITA] mpfr (libmpfr-devel / libmpfr4)

2013-03-11 Thread Dave Korn
On 10/03/2013 15:43, Achim Gratz wrote:

 - TLS disabled since it doesn't work with current gcc

  I just debugged that over on the mpfr list.  It can be made to work by
adding LDFLAGS=-shared-libgcc to your configure line.

  (I'm going to patch upstream GCC to make that the default, and I'm also
rolling a 4.7.2-2 with that patch included.)

cheers,
  DaveK



Re: GCC 4.7 and dependencies

2013-03-11 Thread Cygwin/X
On Tue, 12 Mar 2013 00:57:45 +, Dave Korn wrote:
  I have updated .cygport and patch files for GCC and its dependencies:
  
  http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
 
   I'm trying to look at this, but all I get is errors:
 
  $ git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc4

That was a typo in gitweb; the correct URL is:
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc


Yaakov


Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)

2013-03-11 Thread Cygwin/X
On Sun, 10 Mar 2013 16:36:05 +0100, Achim Gratz wrote:
 Packages orphaned by David Billinghurst.
 
 - no update due to compatibility issues with existing applications

GCC 4.8 uses isl/cloog-isl for Graphite, which require GMP 5.x.  So we
need to update now; packages which depend on libgmp3 will be rebuilt in
due course.  Can you please spin 5.1.1 instead and rebuild the other
packages?


Yaakov



Re: [ITA] mpclib (mpclib-devel / libmpc1 / libmpc3)

2013-03-11 Thread Cygwin/X
On Sun, 10 Mar 2013 16:50:04 +0100, Achim Gratz wrote:
 - provide libmpc1 for compatibility with existing packages (the old
   package pinned the library version to -1 even though the API version
   was -3), the actual library content is identical

This was a mistake then; please don't propagate it any further.
libmpc1 should be left as is, and will be able to be removed from the
distro once all cross-GCCs are updated.


Yaakov


Re: GCC 4.7 and dependencies

2013-03-11 Thread Cygwin/X
On Mon, 11 Mar 2013 18:40:55 -0500, Yaakov (Cygwin/X) wrote:
 JonY, Achim, and others,
 
 I have updated .cygport and patch files for GCC and its dependencies:
 
 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc

I forgot to mention that this requires cygport git master.


Yaakov