gmane.comp.gnu.mingw.devel

Re: Microsoft's obfuscated typedefs considered harmful

Keith Marshall — 2013-05-28T13:12:58

My compiler did *not* DTWT; it did precisely TRT.


Nope; wrong assumption.  I'm building a Linux hosted cross-pexports, to 
run natively on my 64-bit Debian box, as a complement to my existing 
(self-built) 64-bit Debian hosted mingw32-gcc cross-compiler.


If I were using the cross-mingw32-gcc, then of course that's exactly 
what it would be, (and is).  I'm not using that compiler; I'm using the 
native Debian 64-bit gcc, in which 'long' is (correctly) 64 bits.

TWT is in the declaration of IMAGE_DOS_HEADER, (in MinGW headers), where 
the 'e_lfanew' field is declared as

   LONG e_lfanew

The file layout, which that IMAGE_DOS_HEADER structure represents, 
requires an unambiguous field width of *exactly* 32 bits for e_lfanew, 
but the declaration uses an *ambiguous* type (32 bits *or* *more*).


How many members of that community care, to the extent that they prefer 
consistency with Microsoft ambiguity over technical accuracy?  Who's to 
say that, in a year or two's time, Microsoft won't introduce a new 
64-bit version of MSVC, which promotes 'long' to 64 bits?  When they do, 
it's a fair bet that they'll also concoct some _USE_32BIT_LONG kludge, 
and you'll be embroiled in the sizeof(long) counterpart of the 
_USE_32BIT_TIME_T debacle all over again.

Re: Microsoft's obfuscated typedefs considered harmful

Earnie Boyd — 2013-05-28T12:10:27

But why did your compiler DTWT?  I am assuming you're using a cross
compiler targeting MinGW?  If so, then long should be 32 bits.


I don't disagree with the idea, I'm hesitant because I fear that the
community expects them to be defined as they are by MS.

Re: Microsoft's obfuscated typedefs considered harmful

Keith Marshall — 2013-05-28T10:49:11

I agree that we must keep them typedef'd.  I wasn't suggesting 
otherwise; rather that we take a more cautious approach to *how* they 
are typedef'd.


But how many bits is a 'long'?  C99 says only that it must be at least 
as long as an 'int', but no fewer than 32 bits, while an 'int' shall be 
at least as long as a 'short', which in turn shall be no fewer than 16 
bits.  The point is that these sizes are *minima*, but not explicit.

All I'm suggesting is that, where an explicit size is intended, we may 
prefer a more explicit typedef; e.g.

   #include <stdint.h>
   ...
   typedef uint16_t WORD;
   typedef uint32_t DWORD;
   ...

in preference to the (existing) vague (non-explicit)

   typedef unsigned short WORD;
   typedef unsigned long DWORD;

Aside: BYTE, WORD, and DWORD are all abstracted from Intel assembly 
language, where they all specify explicit bit lengths, (8, 16, and 32 
bits respectively); I note that Microsoft appear to have neglected to 
derive any QWORD (64 bits) typedef, from the same source.


Yep.  I got a compile time warning related to that; pexports had its own 
private (and incorrect) INT_PTR typedef, which was raising warnings 
about casting between pointers and integers of differing sizes.  Using 
the standard 'intptr_t' in place of that, (and standard 'PRIdPTR' in 
place of its associated INT_PTR_FORMAT), resolved *that* issue.

However, a more serious issue arose at runtime; the use of 'LONG' to 
specify the type of the 'e_lfanew' field in the 'IMAGE_DOS_HEADER' 
struct; since 'LONG' is

   typedef long LONG

and 'long' is 64 bits on my 64-bit Debian box, the compiler interpreted 
this as a 64-bit 'e_lfanew' field, (which is wrong -- it *must* be an 
*explicit* 32-bit field), and the application blew up with a segment 
violation fault at runtime, as soon as it tried to parse the DLL image 
content, as referenced by the improperly sized e_lfanew offset value.

In summary: I'm not suggesting that we drop support for these Microsoft 
obfuscated typedefs; rather, we have an opportunity to engineer them 
better, (perhaps even better than Microsoft do themselves), and that we 
should maybe consider doing so.

Re: Microsoft's obfuscated typedefs considered harmful

Earnie Boyd — 2013-05-27T20:47:01

I agree that they're a headache but a required one based on the Windows API.

IIRC, long on 64bit Windows is still 32bit. See
http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows
and http://msdn.microsoft.com/en-us/magazine/cc302200.aspx

So LONG in both 32bit and 64bit Windows is still long.  Pointers are
64bit on the other hand.

Microsoft's obfuscated typedefs considered harmful

Keith Marshall — 2013-05-27T19:53:47

I've never much liked Microsoft's obfuscated typedefs; some on the 
grounds of ugliness, some because they are just plain pointless; all 
because they evade standards conforming clarity of purpose, and hinder 
portability of code.

Here's one I'd previously considered to be in the pointless category:

   typedef long LONG;

However, while building pexports as a cross-tool, to be hosted on my 
64-bit Debian box, I discover that the reality is worse; this turd is 
actually used in contexts which may actually result in segmentation 
faults, and consequent program crashes!  The explanation is that, in 
pexports.h I see a declaration, duplicated from our winnt.h, of the 
IMAGE_DOS_HEADER structure, in which the e_lfanew member is declared as 
being of type LONG; (it needs to be an explicit int32_t).  The problem 
is: on 64-bit Linux, GCC interprets long as equivalent to int64_t, and 
offsets computed on the basis of a 64-bit e_lfanew, in which the most 
significant 32-bits are garbage pulled in from the following field, (of 
a following structural data entity within the PE file image), are very 
likely to be out-of-bounds.

I can easily fix this for pexports, but we may wish to consider the 
potential impact for winnt.h, and other API headers, in which the scope 
of the potential problem may be wider reaching; (it certainly affects 
more than just the IMAGE_DOS_HEADER structure).

Thoughts?

bug 1855: libmudflap -- MinGW thread

arthur — 2013-05-03T20:16:32

To address bug 1855 [1], I try to add --enable-libmudflap to build gcc.

It failed as:

...
checking for thread model used by GCC... win32
win32 is an unsupported thread package
make[1]: *** [configure-target-libmudflap] Error 1
...

The direct cause from configure.ac:

...
# We only support posix threads, or no threads at all.
posix_threads=
case ${target_thread_file} in
   posix)
     posix_threads=yes
     ;;
   single)
     ;;
   *)
     echo "${target_thread_file} is an unsupported thread package" 1>&2
     exit 1
     ;;
esac
...

I believe MinGW has a POSIX interface for threading (pthreads-w32?). Is 
this true? If yes what is your suggestion on patching this. Adding 
'win32)\n posix_threads=yes' directly there looks ugly.

You have a good weekend!

[1] https://sourceforge.net/p/mingw/bugs/1855/

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

Fwd: Fwd: binutils 2.23.2-3

Earnie Boyd — 2013-04-29T16:36:33

---------- Forwarded message ----------
From: nick clifton <nickc-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Date: Mon, Apr 29, 2013 at 12:15 PM
Subject: Re: Fwd: binutils 2.23.2-3
To: Earnie Boyd <earnie-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org>, binutils-9JcytcrH/bA+uJoB2kUjGw< at >public.gmane.org


Hi Earnie,




Nope - just a snafu.  I have updated the websites.

Cheers
  Nick

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

John E. / TDM — 2013-04-25T23:35:22

I believe 2.23.2 has been officially released, but without its 
corresponding webpage update. See 
<http://sourceware.org/ml/binutils/2013-03/msg00279.html>.

-John E. / TDM

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

arthur — 2013-04-25T21:30:25

Just reminder: binutils 2.23.2 is not released yet even it is on ftp, 
but not on the home page.

http://www.gnu.org/software/binutils/


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

arthur — 2013-04-25T21:27:56

You are part of this. Thank you again for the building hint and 
suggesting those options.


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

Earnie Boyd — 2013-04-25T13:19:21

So the next steps are to get the changes to the mingw-dist
repository[1] correct.

[1] https://sourceforge.net/p/mingw/mingw-dist/ci/master/tree/

Re: Please test: gcc 4.8.0-1 and binutils 2.23.2-3

John E. / TDM — 2013-04-25T01:01:41

 From my limited use in compiling a few test programs, it seems to be an 
eminently usable replacement for the previous release. Congratulations 
on completing a GCC/MinGW bootstrap!

-John E. / TDM

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Please test: gcc 4.8.0-1 and binutils 2.23.2-3

arthur — 2013-04-24T17:38:35

Both build with i686-pc-mingw32.

Individual packages are under the folders of:

https://sourceforge.net/projects/arthurzhang.u/files/mingw/


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: gcc4.8.0 build and package

Earnie Boyd — 2013-04-23T22:35:00

I don't see the point.  They're actually used for cross compiling so
let the i686-pc-mingw32-*.exe replace them.  The mingw-get process
should remove the mingw32-*.exe IIRC when the upgrade occurs.

Re: gcc4.8.0 build and package

arthur — 2013-04-23T21:27:43

....


I just notice that those bin\mingw32-*.exe are wrapper executables so I 
think even the gcc install will install bin\i686-pc-mingw32-*.exe then 
we still can mv them as bin\mingw32-*.exe (after overwritten as wrapper 
exes).

Do you want we keep as bin\mingw32-*.exe (as today) or keep as 
bin\i686-pc-mingw32-*.exe (as gcc 4.8.0 installed).


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

Re: gcc4.8.0 build and package

Earnie Boyd — 2013-04-23T12:17:09

The contents of the ticket make your question understandable.  Use
--build=i686-pc-mingw32 and we will leave those using anything less
behind as far as pre-build options go.  We can help them get the
source built for their own use on the mingw-users list.  You will need
to call this out in the announcement and the MINGW-README file.  Give
the bug ticket as your reasoning for the change.

Re: gcc4.8.0 build and package

arthur — 2013-04-22T21:38:08

Thanks for this info. I will rebuild binutils with the new configure first.


Yes:-)


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Re: gcc4.8.0 build and package

arthur — 2013-04-22T21:33:55

Got it.


Changes in gcc 4.8.0 introduce multiple undefined references for Ada. 
See this ticket:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Re: gcc4.8.0 build and package

John E. / TDM — 2013-04-22T19:45:55

GNU binutils will need to be rebuilt with the same target spec, 
otherwise it will break full "relocatability" due to GCC looking in 
<sysroot>/<target>/bin for binutils executables.


I believe Arthur is presenting this 3rd option as an alternative to 
changing the target architecture.

-John E. / TDM

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

Re: gcc4.8.0 build and package (was: gcc 4.8.0 Adaerror)

Earnie Boyd — 2013-04-22T18:05:03

I think the common platform in today's world is i686 and perhaps worth
the change at this time. It is time we started using the full triplet
directory because of x86_64 which we will eventually be able to
distribute.  The users will need to know the difference.


It shouldn't break anything.  It will cause user confusion. The
mingw-get installer should handle the removal of the old structure to
present the new structure to the user.


Why does Ada not build?

Re: gcc4.8.0 build and package (was: gcc 4.8.0 Ada error)

arthur — 2013-04-22T16:40:24

Hi All, I need your input with regarding the direction of building and 
packaging gcc 4.8.0.

You can find some more discussions from 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909

Please let me know which option you'd like to go, or you may have other 
suggestion. Thanks.

1. build with '--with-arch=i686 --build=mingw32'
   this will force arch to i686 ONLY

2. build with '--build=i686-pc-mingw32'

   this is the suggested workaround by gcc team, however, our old v4.7.2 
has lib installed to \MinGW\lib\gcc\mingw32\4.7.2 (as --build=mingw32)
but now new v4.8.0 build will install lib to 
...\gcc\i686-pc-mingw32\4.8.0. This also applies to libexec dir too. 
Also the bin\mingw32-*.exe will become bin\i686-pc-mingw32-*.exe

As my limited tests, gcc looks fine with above dir/file name changes but 
I don't know if this may break other (e.g. MSYS) part of MinGW.

3. exclude Ada from v4.8.0 build and package

   this leaves our Ada package as 4.7.2



------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter