Re: RFC: Cygwin 64 bit?

[Pedro Alves <alves dot ped at gmail dot com>]

On 01/19/2012 10:25 AM, Corinna Vinschen wrote:
> On Jan 18 15:54, Corinna Vinschen wrote:
>> On Jan 18 14:23, Pedro Alves wrote:
>>> I was looking for a technical reason that's worse, other then the
>>> amount of mechanical work, which I'm sure could also be easily
>>> scripted, with the long/int hidden behind a #define,
>>> from the perspective of code that uses the headers.   It's obvious
>>> the pragma is less intrusive to the headers.
>>
>> I can't think of any.  In both cases you will get the type mismatches in
>> certain circumstances within the LP64 code of the application.
>>
>> Hmm.  The only other problem I could see with the #pragma approach is a
>> potential clash of debug information within the same CU.  If you use
>> Windows headers you would potentially have two entries for long in
>> .debug_info:
>>
>>  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.

-- 
Pedro Alves