Advise on long types in 64-bit binutils PE compiles.

[Jerker Bäck <jerker dot back at telia dot com>]

This may seem like a trivial and off-topic question, but it puzzles me every
time I try dive into binutils.
How to treat the long type in binutils?
The obvious answer is: A long type is a long type is a long type...
But actually it's not that simple, at least not for me.

My system, Interix have the LP64 long type data model, thus a long is 64bit.
But we also use PE binaries and all 64bit PE compilers I know of have the
LLP64 long type data model, thus a long is 32bit. To support the Interix
LP64, we usually convert all longs to long long in the compilation process,
leaving the real 32bit long type practically obsolete.

To put it the other way around, how do a 64bit LP64 unix developer regard
the long type in relation to the long long type?

I've got these as 64bit in bfd
BFD_HOSTPTR_T, bfd_vma, bfd_signed_vma, bfd_size_type, symvalue

I think my scenario would be equivalent to 64bit PE cross tools on a 64bit
LP64 elf system (e.g. x86_64 NetBSD).

Do binutils assume that a long type is capable of holding a pointer?

When it comes to the PE header as described in the <ntimage.h> WDK header,
the structures requires a 32bit long. Using the LP64 model here would never
work as the structure sizes would be totally wrong. What about the
corresponding structures in binutils? Do they also requires 32bit longs?
I've tried to figure this out, but it's very difficult to tell as the
structures may never be used as is.

Examples of binutils PE structures with wrong sizes if LP64 is used:
internal_extra_pe_aouthdr, internal_filehdr

Examples of ambiguous use of longs in binutils:

long bfd_get_mtime (bfd *abfd); returns a long converted time_t type.

unsigned long bfd_calc_gnu_debuglink_crc32 (
    unsigned long crc, const unsigned char *buf, bfd_size_type len);


In other words:
Should binutils be compiled in LLP64 for 64bit PE targets?

Thanks for any advise
Jerker