bug#18699: 25.0.50; Windows 7: Odd length text property list

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

Emacs -Q won't start on a Windows 7 32 bits laptop. It prints the
mentioned message on the console. Same for a Windows 7 64 bits VM.
However, the same binary has no issues on Windows XP 32 bits nor on
Windows 8 64 bits.

It was compiled on a Windows XP machine with MinGW-w64.

The sources are the same used for this instance of Emacs on GNU Linux
that I'm using for writing this report.

There is bug#18559 on Sep 25 about the same problem but it was confirmed
as fixed that same day. My sources are from Oct 4. Also tried an
emacs.exe binary with current trunk.



In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit)
 of 2014-10-04 on qcore
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

Backtrace:

#0  validate_plist (list=8577862) at ../../emacs/src/textprop.c:235
#1  0x0114d240 in add_text_properties_1 (start=start@entry=4,
    end=end@entry=48, properties=properties@entry=8577862,
    object=object@entry=22450013,
    set_type=set_type@entry=TEXT_PROPERTY_REPLACE)
    at ../../emacs/src/textprop.c:1181
#2  0x0114d607 in Fadd_text_properties (object=22450013, properties=8577862,
    end=end@entry=48, start=4) at ../../emacs/src/textprop.c:1306
#3  Fput_text_property (start=4, end=end@entry=48, property=21207346,
    value=22318226, object=22450013) at ../../emacs/src/textprop.c:1324
#4  0x01071e04 in produce_charset (coding=<optimized out>, pos=12,
    charbuf=0x82e39c) at ../../emacs/src/coding.c:7285
#5  produce_annotation (pos=12, coding=<optimized out>)
    at ../../emacs/src/coding.c:7328
#6  decode_coding (coding=coding@entry=0x82e5e0)
    at ../../emacs/src/coding.c:7423
#7  0x01076e6e in decode_coding_object (coding=<optimized out>,
    coding@entry=0x82e5e0, src_object=<optimized out>,
    src_object@entry=14478465, from=<optimized out>, from@entry=0,
    from_byte=<optimized out>, from_byte@entry=0, to=<optimized out>,
    to_byte=<optimized out>, dst_object=<optimized out>,
    dst_object@entry=21139106) at ../../emacs/src/coding.c:8149
#8  0x01078aea in code_convert_string (string=string@entry=14478465,
    coding_system=<optimized out>, coding_system@entry=22318258,
    dst_object=<optimized out>, encodep=encodep@entry=false,
    nocopy=nocopy@entry=false, norecord=norecord@entry=true)
    at ../../emacs/src/coding.c:9491
#9  0x01078f09 in code_convert_string_norecord (string=14478465,
    coding_system=coding_system@entry=22318258, encodep=encodep@entry=false)
    at ../../emacs/src/coding.c:9511
#10 0x01167840 in intern_font_name (
    string=string@entry=0x82eb2c "Courier New")
    at ../../emacs/src/w32font.c:289
#11 0x01167ca7 in w32_enumfont_pattern_entity (frame=<optimized out>,
    requested_font=0x82ecd4, backend=21295146, font_type=4,
    physical_font=0x82e928, logical_font=0x82eb10)
    at ../../emacs/src/w32font.c:1085
#12 add_font_entity_to_list (logical_font=0x82eb10, physical_font=0x82e928,
    font_type=4, lParam=8580308) at ../../emacs/src/w32font.c:1500
#13 0x777004b5 in SetPixelV () from C:\Windows\system32\gdi32.dll
#14 0x7770041e in SetPixelV () from C:\Windows\system32\gdi32.dll
#15 0x777005db in GDI32!EnumFontFamiliesExA ()
   from C:\Windows\system32\gdi32.dll
#16 0x777005a8 in GDI32!EnumFontFamiliesExA ()
   from C:\Windows\system32\gdi32.dll
#17 0x011689a0 in w32font_list_internal (
    f=f@entry=0x1810310 <dumped_data+4102736>,
    font_spec=font_spec@entry=21240061, opentype_only=opentype_only@entry=1)
    at ../../emacs/src/w32font.c:833
#18 0x01178347 in uniscribe_list (f=0x1810310 <dumped_data+4102736>,
    font_spec=21240061) at ../../emacs/src/w32uniscribe.c:74
#19 0x011179ca in font_list_entities (f=0x1810310 <dumped_data+4102736>,
    spec=25013381) at ../../emacs/src/font.c:2804
#20 0x011181e4 in font_find_for_lface (
    f=f@entry=0x1810310 <dumped_data+4102736>, attrs=attrs@entry=0x82eeb4,
    spec=spec@entry=25232517, c=c@entry=-1) at ../../emacs/src/font.c:3281
#21 0x01118df2 in font_load_for_lface (
    f=f@entry=0x1810310 <dumped_data+4102736>, attrs=attrs@entry=0x82eeb4,
    spec=spec@entry=25232517) at ../../emacs/src/font.c:3354
#22 0x01118eb9 in font_open_by_spec (
    f=f@entry=0x1810310 <dumped_data+4102736>, spec=25232517)
    at ../../emacs/src/font.c:3416
#23 0x01118ef6 in font_open_by_name (
    f=f@entry=0x1810310 <dumped_data+4102736>, name=14478433)
    at ../../emacs/src/font.c:3432
#24 0x01157ffc in x_default_font_parameter (
    f=f@entry=0x1810310 <dumped_data+4102736>, parms=parms@entry=22486246)
    at ../../emacs/src/w32fns.c:4404
#25 0x0115fc4c in Fx_create_frame (parameters=22486246)
    at ../../emacs/src/w32fns.c:4568
#26 0x011044b2 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f094)
    at ../../emacs/src/eval.c:2723
#27 0x01136cda in exec_byte_code (bytestr=<optimized out>, vector=18883733,
    maxdepth=16, args_template=21139074, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0x0) at ../../emacs/src/bytecode.c:920
#28 0x0110401b in funcall_lambda (fun=18883685, nargs=nargs@entry=1,
    arg_vector=arg_vector@entry=0x82f240) at ../../emacs/src/eval.c:2956
#29 0x01104335 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f23c)
    at ../../emacs/src/eval.c:2784
#30 0x01136cda in exec_byte_code (bytestr=<optimized out>, vector=19180645,
    maxdepth=64, args_template=args_template@entry=1024, nargs=nargs@entry=1,
    args=<optimized out>, args@entry=0x82f3e8)
    at ../../emacs/src/bytecode.c:920
#31 0x0110409e in funcall_lambda (fun=19180597, nargs=nargs@entry=1,
    arg_vector=arg_vector@entry=0x82f3e8) at ../../emacs/src/eval.c:2890
#32 0x01104335 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f3e4)
    at ../../emacs/src/eval.c:2784
#33 0x01136cda in exec_byte_code (bytestr=<optimized out>, vector=19178765,
    maxdepth=24, args_template=args_template@entry=0, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0x82f578)
    at ../../emacs/src/bytecode.c:920
#34 0x0110409e in funcall_lambda (fun=19178725, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0x82f578) at ../../emacs/src/eval.c:2890
#35 0x01104335 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x82f574)
    at ../../emacs/src/eval.c:2784
#36 0x01136cda in exec_byte_code (bytestr=<optimized out>, vector=19196101,
    maxdepth=68, args_template=args_template@entry=0, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0x82f73c)
    at ../../emacs/src/bytecode.c:920
#37 0x0110409e in funcall_lambda (fun=19196061, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0x82f73c) at ../../emacs/src/eval.c:2890
#38 0x01104335 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x82f738)
    at ../../emacs/src/eval.c:2784
#39 0x01136cda in exec_byte_code (bytestr=<optimized out>, vector=19194541,
    maxdepth=48, args_template=args_template@entry=0, nargs=nargs@entry=0,
    args=<optimized out>, args@entry=0x82f870)
    at ../../emacs/src/bytecode.c:920
#40 0x0110409e in funcall_lambda (fun=fun@entry=19194501,
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f870)
    at ../../emacs/src/eval.c:2890
#41 0x01103595 in apply_lambda (fun=<optimized out>, args=<optimized out>,
    count=count@entry=3) at ../../emacs/src/eval.c:2831
#42 0x01103865 in eval_sub (form=form@entry=22884086)
    at ../../emacs/src/eval.c:2253
#43 0x01106be9 in Feval (form=22884086, lexical=21139074)
    at ../../emacs/src/eval.c:1993
#44 0x01099b84 in top_level_2 () at ../../emacs/src/keyboard.c:1206
#45 0x01102c39 in internal_condition_case (
    bfun=bfun@entry=0x1099b6b <top_level_2>, handlers=21192610,
    hfun=hfun@entry=0x109dffd <cmd_error>) at ../../emacs/src/eval.c:1344
#46 0x01099b62 in top_level_1 (ignore=21139074)
    at ../../emacs/src/keyboard.c:1214
#47 0x01102b5c in internal_catch (tag=21189938,
    func=func@entry=0x1099b03 <top_level_1>, arg=21139074)
    at ../../emacs/src/eval.c:1105
#48 0x0109dcb6 in command_loop () at ../../emacs/src/keyboard.c:1175
#49 recursive_edit_1 () at ../../emacs/src/keyboard.c:786
#50 0x0109df4b in Frecursive_edit () at ../../emacs/src/keyboard.c:857
#51 0x011ba1b8 in main (argc=<optimized out>, argv=0x8e2c30)
    at ../../emacs/src/emacs.c:1623

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Date: Mon, 13 Oct 2014 04:02:22 +0200
> 
> Backtrace:
> 
> #0  validate_plist (list=8577862) at ../../emacs/src/textprop.c:235
> #1  0x0114d240 in add_text_properties_1 (start=start@entry=4,
>     end=end@entry=48, properties=properties@entry=8577862,
>     object=object@entry=22450013,
>     set_type=set_type@entry=TEXT_PROPERTY_REPLACE)
>     at ../../emacs/src/textprop.c:1181
> #2  0x0114d607 in Fadd_text_properties (object=22450013, properties=8577862,
>     end=end@entry=48, start=4) at ../../emacs/src/textprop.c:1306
> #3  Fput_text_property (start=4, end=end@entry=48, property=21207346,
>     value=22318226, object=22450013) at ../../emacs/src/textprop.c:1324
> #4  0x01071e04 in produce_charset (coding=<optimized out>, pos=12,
>     charbuf=0x82e39c) at ../../emacs/src/coding.c:7285
> #5  produce_annotation (pos=12, coding=<optimized out>)
>     at ../../emacs/src/coding.c:7328
> #6  decode_coding (coding=coding@entry=0x82e5e0)
>     at ../../emacs/src/coding.c:7423
> #7  0x01076e6e in decode_coding_object (coding=<optimized out>,
>     coding@entry=0x82e5e0, src_object=<optimized out>,
>     src_object@entry=14478465, from=<optimized out>, from@entry=0,
>     from_byte=<optimized out>, from_byte@entry=0, to=<optimized out>,
>     to_byte=<optimized out>, dst_object=<optimized out>,
>     dst_object@entry=21139106) at ../../emacs/src/coding.c:8149
> #8  0x01078aea in code_convert_string (string=string@entry=14478465,
>     coding_system=<optimized out>, coding_system@entry=22318258,
>     dst_object=<optimized out>, encodep=encodep@entry=false,
>     nocopy=nocopy@entry=false, norecord=norecord@entry=true)
>     at ../../emacs/src/coding.c:9491
> #9  0x01078f09 in code_convert_string_norecord (string=14478465,
>     coding_system=coding_system@entry=22318258, encodep=encodep@entry=false)
>     at ../../emacs/src/coding.c:9511
> #10 0x01167840 in intern_font_name (
>     string=string@entry=0x82eb2c "Courier New")
>     at ../../emacs/src/w32font.c:289
> #11 0x01167ca7 in w32_enumfont_pattern_entity (frame=<optimized out>,
>     requested_font=0x82ecd4, backend=21295146, font_type=4,
>     physical_font=0x82e928, logical_font=0x82eb10)
>     at ../../emacs/src/w32font.c:1085
> #12 add_font_entity_to_list (logical_font=0x82eb10, physical_font=0x82e928,
>     font_type=4, lParam=8580308) at ../../emacs/src/w32font.c:1500
> #13 0x777004b5 in SetPixelV () from C:\Windows\system32\gdi32.dll
> #14 0x7770041e in SetPixelV () from C:\Windows\system32\gdi32.dll
> #15 0x777005db in GDI32!EnumFontFamiliesExA ()
>    from C:\Windows\system32\gdi32.dll
> #16 0x777005a8 in GDI32!EnumFontFamiliesExA ()
>    from C:\Windows\system32\gdi32.dll
> #17 0x011689a0 in w32font_list_internal (
>     f=f@entry=0x1810310 <dumped_data+4102736>,
>     font_spec=font_spec@entry=21240061, opentype_only=opentype_only@entry=1)
>     at ../../emacs/src/w32font.c:833

Looks exactly like #18559, but that one was fixed.

Which version of GCC did you use to build this binary?

The function add_font_entity_to_list is decorated with a GCC attribute
that should cause GCC to emit a few instructions in the function's
prologue to ensure the stack is 8-byte aligned.  Do you see that in the
disassembly of that function?  If not, can you show the preprocessed
source of the first few line of that function, including its
definition line?

In any case, please continue using the current trunk and reporting
results from it, not from the Oct 4 version.

Thanks.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> Date: Mon, 13 Oct 2014 08:31:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18699@debbugs.gnu.org
> 
> The function add_font_entity_to_list is decorated with a GCC attribute
> that should cause GCC to emit a few instructions in the function's
> prologue to ensure the stack is 8-byte aligned.  Do you see that in the
> disassembly of that function?  If not, can you show the preprocessed
> source of the first few line of that function, including its
> definition line?

Here's what I see in the preprocessed source on my machine:

  static int __attribute__((__stdcall__)) __attribute__((force_align_arg_pointer))
  add_font_entity_to_list (ENUMLOGFONTEX *logical_font,
      NEWTEXTMETRICEX *physical_font,
      DWORD font_type, LPARAM lParam)
  {
    struct font_callback_data *match_data
      = (struct font_callback_data *) lParam;
    Lisp_Object backend = match_data->opentype_only ? Quniscribe : Qgdi;
    Lisp_Object entity;

The important part is the force_align_arg_pointer attribute.

This is set up in w32term.h, like this:

  #ifdef __GNUC__
  # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__     \
    && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5
  #  define ALIGN_STACK __attribute__((force_align_arg_pointer))
  # else
  #  define ALIGN_STACK
  # endif  /* USE_STACK_LISP_OBJECTS */
  #endif

Is it possible that the MinGW64 compiler somehow trips here?  E.g., is
it possible that, even in a 32-bit build, it defines _W64 or
__x86_64__?  If so, what other preprocessor macros are available in
MinGW64 to distinguish between a 32-bit and a 64-bit build?

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> The important part is the force_align_arg_pointer attribute.
>
> This is set up in w32term.h, like this:
>
>   #ifdef __GNUC__
>   # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__     \
>     && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5
>   #  define ALIGN_STACK __attribute__((force_align_arg_pointer))

The problem is _W64, which is defined to _w64. This doesn't make much
sense to me. I'll ask on the MinGW-w64 ml.

Thanks.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Cc: 18699@debbugs.gnu.org
> Date: Mon, 13 Oct 2014 12:27:41 +0200
> 
> >   #ifdef __GNUC__
> >   # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__     \
> >     && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5
> >   #  define ALIGN_STACK __attribute__((force_align_arg_pointer))
> 
> The problem is _W64, which is defined to _w64. This doesn't make much
> sense to me. I'll ask on the MinGW-w64 ml.

Thanks.

So this _is_ the same as 18559.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

The MinGW-w64 guys say that _W64 is not the rigth way of checking that
we are targeting Windows 64. _WIN64 is.

http://sourceforge.net/p/mingw-w64/mailman/message/32925577/

AFAIU the fact that we are using _W64 for detecting MinGW-w64 (on both
32 and 64 bit variants) is also wrong. _W64 is a MS thing and not
specific to MinGW-w64, as explained on the StackOverflow question linked
from the above message. It just happens that MinGW does not define it.

The right way to detect MinGW-w64 is to test for __MINGW64_VERSION_MAJOR
*after* including some C runtime header or _mingw.h, because it is not a
preprocessor predefined macro. It is explained here:

http://sourceforge.net/p/mingw-w64/discussion/723798/thread/ea355c1f/#d4db

I propose to fix the ALIGN_STACK issue by replacing _W64 with _WIN64 and
later fix the places where _W64 is used for detecting MinGW-w64 with the
right method.

Eli, can you take care of the ALIGN_STACK fix? I'll send a patch for the
rest of _W64 cases, if nobody beats me to it.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 13 Oct 2014 13:46:22 +0200
> 
> The MinGW-w64 guys say that _W64 is not the rigth way of checking that
> we are targeting Windows 64. _WIN64 is.

I'm quite sure at some point someone told me the exact opposite of
this, whcih is why you see what you see in nt/inc/.

> The right way to detect MinGW-w64 is to test for __MINGW64_VERSION_MAJOR
> *after* including some C runtime header or _mingw.h, because it is not a
> preprocessor predefined macro.

It is a PITA that the MinGW64 compiler doesn't define some clear-cut
macro for that without the need to include headers.  IME this is a
terrible maintenance headache in the long run.  Perhaps you could ask
the MinGW64 developers to change their mind about that.

What about __x86_64__, does it perhaps fit the bill already?

> Eli, can you take care of the ALIGN_STACK fix?

Done in trunk revision 118105.

> I'll send a patch for the rest of _W64 cases, if nobody beats me to
> it.

TIA

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> It is a PITA that the MinGW64 compiler doesn't define some clear-cut
> macro for that without the need to include headers.  IME this is a
> terrible maintenance headache in the long run.

Agreed.

> Perhaps you could ask the MinGW64 developers to change their mind
> about that.

I could try, but my understanding is that they are not interested on
doing that, for multiple reasons. One of them is that, in theory, you
could use the MinGW-w64 compiler with the MinGW headers and libraries.

> What about __x86_64__, does it perhaps fit the bill already?

__x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my
Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But
I've seen quite a few patch submissions about ARM support on the
MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits
by MinGW would fail the __x86_64__ test. If that Emacs comes to light,
we probably would need to determine what's the right thing wrt
ALIGN_STACK, though.

So in this specific case __x86_64__ does not harm, but it is superfluous
on the presence on _WIN64.

>> Eli, can you take care of the ALIGN_STACK fix?
>
> Done in trunk revision 118105.

Thanks!

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Cc: 18699-done@debbugs.gnu.org
> Date: Mon, 13 Oct 2014 15:57:17 +0200
> 
> > Perhaps you could ask the MinGW64 developers to change their mind
> > about that.
> 
> I could try, but my understanding is that they are not interested on
> doing that, for multiple reasons. One of them is that, in theory, you
> could use the MinGW-w64 compiler with the MinGW headers and libraries.

That's a nice theory, but I don't think it will hold, since (AFAIU)
the two compilers use different methods of throwing C++ exceptions
between DLLs.

> > What about __x86_64__, does it perhaps fit the bill already?
> 
> __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my
> Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But
> I've seen quite a few patch submissions about ARM support on the
> MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits
> by MinGW would fail the __x86_64__ test. If that Emacs comes to light,
> we probably would need to determine what's the right thing wrt
> ALIGN_STACK, though.
> 
> So in this specific case __x86_64__ does not harm, but it is superfluous
> on the presence on _WIN64.

It is there for Cygwin's sake, but I thought it could also serve
MinGW64.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Ken Brown]

On 10/13/2014 3:07 PM, Eli Zaretskii wrote:
>> From: oscarfv@telefonica.net (Óscar Fuentes)
>> Cc: 18699-done@debbugs.gnu.org
>> Date: Mon, 13 Oct 2014 15:57:17 +0200
>>
>>> Perhaps you could ask the MinGW64 developers to change their mind
>>> about that.
>>
>> I could try, but my understanding is that they are not interested on
>> doing that, for multiple reasons. One of them is that, in theory, you
>> could use the MinGW-w64 compiler with the MinGW headers and libraries.
>
> That's a nice theory, but I don't think it will hold, since (AFAIU)
> the two compilers use different methods of throwing C++ exceptions
> between DLLs.
>
>>> What about __x86_64__, does it perhaps fit the bill already?
>>
>> __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my
>> Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But
>> I've seen quite a few patch submissions about ARM support on the
>> MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits
>> by MinGW would fail the __x86_64__ test. If that Emacs comes to light,
>> we probably would need to determine what's the right thing wrt
>> ALIGN_STACK, though.
>>
>> So in this specific case __x86_64__ does not harm, but it is superfluous
>> on the presence on _WIN64.
>
> It is there for Cygwin's sake,

Right.  And it's *not* about the processor.  gcc running under 32-bit 
Cygwin will not define __x86_64__, regardless of the processor.

Ken

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

Ken Brown <kbrown@cornell.edu> writes:

> Right.  And it's *not* about the processor.  gcc running under 32-bit
> Cygwin will not define __x86_64__, regardless of the processor.

It is about the *target* processor of the compiler. Obviously if you
target x86 then __x86_64__ is expected to be undefined, regardless of
the *host* processor.

OTOH if you are saying that Cygwin does not define __x86_64__ when you
are cross-compiling to a x86_64 target on a x86 host, I'll consider that
a bug.

My understanding now is that the __x86_64__ test is there because Cygwin
does not define _WIN64.

Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception
methods on x86. Maybe MinGW only supports one method on its official
binaries, but that's just a detail that can change at any moment. Plus
the user can build his own toolchain. And since when we do care about
C++ here? ;-)

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Cc: Eli Zaretskii <eliz@gnu.org>,  18699@debbugs.gnu.org
> Date: Mon, 13 Oct 2014 21:39:33 +0200
> 
> Ken Brown <kbrown@cornell.edu> writes:
> 
> > Right.  And it's *not* about the processor.  gcc running under 32-bit
> > Cygwin will not define __x86_64__, regardless of the processor.
> 
> It is about the *target* processor of the compiler. Obviously if you
> target x86 then __x86_64__ is expected to be undefined, regardless of
> the *host* processor.
> 
> OTOH if you are saying that Cygwin does not define __x86_64__ when you
> are cross-compiling to a x86_64 target on a x86 host, I'll consider that
> a bug.
> 
> My understanding now is that the __x86_64__ test is there because Cygwin
> does not define _WIN64.

A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build,
doesn't need the force_align_arg_pointer, since the 64-bit ABI
requires the 8-byte alignment.  The __x86_64__ is there to exclude the
64-bit Cygwin build.  If it can also exclude the MinGW64 build, we
don't need any MinGW64-specific symbols there.

> Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception
> methods on x86.

But what is the default one?  That's what's important.

> And since when we do care about C++ here? ;-)

At least the DWARF2-based exceptions machinery comes into play in C
programs as well, see the few Emacs crashes we had with libraries
linked against the libgcc DLL.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build,
> doesn't need the force_align_arg_pointer, since the 64-bit ABI
> requires the 8-byte alignment.  The __x86_64__ is there to exclude the
> 64-bit Cygwin build.  If it can also exclude the MinGW64 build, we
> don't need any MinGW64-specific symbols there.

As mentioned on a previous message, __x86_64__ will exclude Windows 64
on x86* processors, but not on others (i.e. ARM).

>> Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception
>> methods on x86.
>
> But what is the default one?  That's what's important.

MinGW-w64 has no default. Both sjlj and Dwarf have official binaries on
x86 and sjlj and SEH on x86_64. MinGW only distributes Dwarf, IIRC, but
that can change anytime.

But we are off-topic now.

bug#18699: 25.0.50; Windows 7: Odd length text property list

[Eli Zaretskii]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Cc: kbrown@cornell.edu,  18699@debbugs.gnu.org
> Date: Mon, 13 Oct 2014 22:35:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build,
> > doesn't need the force_align_arg_pointer, since the 64-bit ABI
> > requires the 8-byte alignment.  The __x86_64__ is there to exclude the
> > 64-bit Cygwin build.  If it can also exclude the MinGW64 build, we
> > don't need any MinGW64-specific symbols there.
> 
> As mentioned on a previous message, __x86_64__ will exclude Windows 64
> on x86* processors, but not on others (i.e. ARM).

We could decide not to worry about that until we need to support a
Windows build on any of those others.  Like we do with Cygwin.