On Fri, 2014-10-31 at 15:48 -0700, Josh Stone wrote:
> On 10/31/2014 11:26 AM, Petr Machata wrote:
> > Mark Wielaard <m...@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
