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 01/19/2012 11:29 AM, 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".

I'm just trying to balance the "elegance" vs "potential for headaches we
don't really need, because all suggestions have downsides", and point out
that implementing the pragma may need more consideration than a simple
hack.

> 
> 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.
> 
> What solution would you prefer?  Or is there another, perhaps more
> inelligent way to do it which we didn't discuss yet?

I think 1. is actually the easiest and best route (or Andy's 5, about the
same, although LONG is a typedef, not a define).  I have no idea how far
from building a 64-bit cygwin compiler are we, and if it's buildable, and
useable, but it may be worth it to spend a little sed'ing long in the
headers, and get a feel for the result banging the result against some
code base.

> And then again, which of these methods, if any, would be acceptable
> upstream?

3. you've shown doesn't work if we don't change the raw "long"'s in the
headers.  2. has potential for breaking existing 32-bit code.

1. is probably acceptable by gcc upstream.  Googling around,
I find precedent in other compilers for something like that.

My questions were along the "is it worth the bother", not
objections, FWIW.

-- 
Pedro Alves


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