This is the mail archive of the
mailing list for the elfutils project.
Re: Transparent imports of partial units
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 07 Nov 2014 15:08:11 +0100
- Subject: Re: Transparent imports of partial units
On Fri, 2014-10-31 at 15:48 -0700, Josh Stone wrote:
> On 10/31/2014 11:26 AM, Petr Machata wrote:
> > Mark Wielaard <firstname.lastname@example.org> 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:
> And cppref agrees, though it notes some early Unix systems were ILP64.
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...