Re: Transparent imports of partial units

[Mark Wielaard <mjw at redhat dot com>]

On Fri, 2014-10-31 at 15:48 -0700, Josh Stone wrote:
> On 10/31/2014 11:26 AM, Petr Machata wrote:
> > Mark Wielaard <mjw@redhat.com> writes:
> > 
> >> So, assuming we can use the long int padding field as Dwarf_Die pointer,
> > 
> > In other words, do we want to keep backward compatibility on LLP64
> > architectures?  I know Widnows do use this model, do we care?  Any
> > Unices with this model out there?  FWIW, x32 and (MIPS) n32 are both
> > ILP32 ABI's.
> 
> For reference:
> 
>   /* DIE information.  */
>   typedef struct
>   {
>     /* The offset can be computed from the address.  */
>     void *addr;
>     struct Dwarf_CU *cu;
>     Dwarf_Abbrev *abbrev;
>     // XXX We'll see what other information will be needed.
>     long int padding__;
>   } Dwarf_Die;
> 
> Even if that padding is only 4 bytes on LLP64, wouldn't the whole struct
> still be 32 bytes for alignment?  So you may be able to cheat this one,
> turn it into a pointer anyway.
> 
> But I'm not sure if things like struct copies will include alignment
> padding.  Probably not, so then this wouldn't work after all...
> 
> Anyway, at least this only cites Windows 64 as being LLP64:
> https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
> 
> And cppref agrees, though it notes some early Unix systems were ILP64.
> http://en.cppreference.com/w/cpp/language/types#Data_models

But ILP64 wouldn't be a problem since long and pointer have the same
size. So changing the long to a pointer would really only be an ABI
issue for Windows 64 API (even Windows 16 and 32 should be fine).

> But really, I think it's safe to ignore Windows issues in elfutils...
> 
> :)

Agreed.

Cheers,

Mark