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]

Re: RFC: Cygwin 64 bit?


On 19 January 2012 11:29, Corinna Vinschen wrote:
> On Jan 19 11:13, Pedro Alves wrote:
>> On 01/19/2012 10:25 AM, Corinna Vinschen wrote:
>> > On Jan 18 15:54, Corinna Vinschen wrote:
>> >> ÂFrom the LLP64 code:
>> >>
>> >> Â Â<1><d0>: Abbrev Number: 2 (DW_TAG_base_type)
>> >>    <d1>  DW_AT_byte_size  : 4
>> >>    <d2>  DW_AT_encoding  Â: 5    Â(signed)
>> >>    <d3>  DW_AT_name    Â: long int
>> >>
>> >> ÂFrom the LP64 code in the same CU:
>> >>
>> >> Â Â<1><dc>: Abbrev Number: 2 (DW_TAG_base_type)
>> >>    <dd>  DW_AT_byte_size  : 8
>> >>    <de>  DW_AT_encoding  Â: 5    Â(signed)
>> >>    <df>  DW_AT_name    Â: long int
>> >
>> > That won't be the case, fortunately. ÂA collegue has created a POC patch
>> > which would result in only one entry for long, the "right" one with
>> > DW_AT_byte_size 8, while the LLP64 usage of long would be converted to
>> > the type int internally.
>>
>> Sounds like there's potential for gdb getting confused.
>>
>> There's also C++ mangling to consider:
>>
>> #pragma model64 (push, LLP64)
>> void foo (long i);
>> #pragma model64 (pop)
>> void foo (long i);
>> void foo (int i);
>>
>> What does the llp64 version mangle to? ÂIf it's auto converted to
>> int internally, then it conflicts with the int version. ÂIf it's
>> kept as long, then it conflicts with the lp64 long version.
>
> Yes, there is a downside to the concept. ÂOf course the LLP64 version
> would collide with one of the LP64 versions. ÂBut is that a realistic
> problem? ÂThe usage of such a, let's say, dangerous #pragma would be to
> fix a specific problem. ÂThe idea is to find an easy solution to use the
> strict LLP64 Win32 headers with an LP64 compiler. ÂEverything beyond that
> falls under "you're doing that at your own risk".
>
> So far we had four potential ways to tackle this problem in this thread:
>
> 1. Use `#ifdef __LP64__' and define as `int' and `unsigned int'
> Â only on LP64 compilers.
>
> 2. Change all `long' and `unsigned long' to `int' and `unsigned int'
> Â unconditionally.
>
> 3. Add `__attribute__ ((mode(SI)))' to affected typedefs.
>
> 4. Introduce a #pragme to redefine long.

5. Change uses of 'long' and 'unsigned long' to 'LONG' and 'ULONG',
and define the latter two as 'int' and 'unsigned int' for __LP64__.
(Most of the w32api headers use the uppercase typedefs anyway; shame
MS didn't manage to be entirely consistent about that.)

The pragma approach seems the least intrusive though.

Andy


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