Created attachment 41363 [details] source file describing bug Problem: long int structure members are allocated incorrect 8 bytes (as if long long), whereas retyping them with __uint32_t results in correct 4 bytes $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.4.0 (GCC) running on cygwin64 for windows 10: $ uname -a CYGWIN_NT-10.0 Caroline-2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin Source: gcc5.4.0.bug.c (attached) See definition of struct ProductId, members len, format, u.v3.edition.id How to test: 1. Edit ProductId structure members len, format declarations to either __uint32_t or unsigned long int 2. gcc -g -Wall -Wextra gcc5.4.0.bug.c -o gcc5.4.0.bug.exe 3. gdb ./gcc5.4.0.bug.exe b main b 142 run c n print *pId and you will see incorrect 8-byte values for pId->len and pId->format if you declare as unsigned long int, or you will see correct 4-byte values if you declare with __uint32_t Further tests within gdb: print sizeof(long int) print sizeof(pId->len) print sizeof(ii)
long is 64 bits on x86_64, uint32_t is (obviously) 32 bits. This is not a bug.
Hei, Yes I thought that initially too. But if you start gdb and print sizeof(long int) you get 4, not 8. $ gdb GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) print sizeof(long int) $1 = 4 (gdb) print sizeof(unsigned long int) $2 = 4 (gdb) print sizeof(long long int) $3 = 8 (gdb) q
(In reply to Julian Rose from comment #2) > Hei, > > Yes I thought that initially too. But if you start gdb and print sizeof(long > int) you get 4, not 8. > > $ gdb > GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1 > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-cygwin". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word". > (gdb) print sizeof(long int) > $1 = 4 > (gdb) print sizeof(unsigned long int) > $2 = 4 > (gdb) print sizeof(long long int) > $3 = 8 > (gdb) q But I have changed the summary title of this bug to better reflect that a fault appears to lie with the gdb build and not with gcc. Would it be appropriate to close this bug report and raise a new one at https://sourceware.org/bugzilla/?
https://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os states sizeof long int varies between architectures and operating systems; in particular sizeof(long) on IA-64 in Linux is 8 whereas in windows it is 4. Under Cygwin it appears gcc has been built with the "Linux" memory model, and gdb has been built with the "Windows" model. Obviously consistency between gcc and gdb is required for any given platform. But as cygwin runs on a windows platform, it is not clear if the compiler or the debugger is "wrong". Either way, perhaps a solution may be found in the specs configuration given to the compiler for the x86_64-pc-cygwin platform.
https://bugzilla.redhat.com/show_bug.cgi?id=518712 describes the same issue under Linux. But repeating the same test described in comment-1 there when run under x86_64-pc-cygwin gets the wrong answer: $ gdb GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) show arch The target architecture is set automatically (currently i386) (gdb) set arch Requires an argument. Valid arguments are i386, i386:x86-64, i386:x64-32, i8086, i386:intel, i386:x86-64:intel, i386:x64-32:intel, i386:nacl, i386:x86-64:nacl, i386:x64-32:nacl, auto. (gdb) set arch i386:x86-64 The target architecture is assumed to be i386:x86-64 (gdb) print sizeof(long) $1 = 4 (gdb) print sizeof(long long) $2 = 8 (gdb) print sizeof(long*) $3 = 8 (gdb) q
(In reply to Julian Rose from comment #3) > Would it be appropriate to close this bug report and raise a new one at > https://sourceware.org/bugzilla/? Yes please. GCC is correct.
Why shouldn't gcc configured for cygwin use the windows ABI?
It uses the ms-abi for calling conventions but LP64, no LLP64: https://cygwin.com/cygwin-ug-net/programming.html That's by design, and so GCC's behaviour is not a bug. If GDB is inconsistent that's not a GCC bug.
(In reply to Jonathan Wakely from comment #8) > It uses the ms-abi for calling conventions but LP64, no LLP64: > https://cygwin.com/cygwin-ug-net/programming.html > > That's by design, and so GCC's behaviour is not a bug. If GDB is > inconsistent that's not a GCC bug. Ok, that's good for me. Thanks all for the replies. I shall do as comment 6.
(In reply to Julian Rose from comment #9) > (In reply to Jonathan Wakely from comment #8) > > It uses the ms-abi for calling conventions but LP64, no LLP64: > > https://cygwin.com/cygwin-ug-net/programming.html > > > > That's by design, and so GCC's behaviour is not a bug. If GDB is > > inconsistent that's not a GCC bug. > > Ok, that's good for me. > > Thanks all for the replies. I shall do as comment 6. https://sourceware.org/bugzilla/show_bug.cgi?id=21500
Yes, Cygwin and MinGW ABIs are different, and GDB doesn't know about it. It assumes Cygwin == MinGW. I'll follow up in the gdb tracker.