Re: Transparent imports of partial units

[Josh Stone <jistone@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

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


For fun, I tried to cross-compile to x86_64-w64-mingw32 from F20.  I had
to use the portable branch for lack of __thread, and then I still ran
into a bunch of headers that had no suitable provider in the repos.

$ make -k |& grep '#include' | sort -u
 #include <argp.h>
 #include <ar.h>
 #include <byteswap.h>
 #include <endian.h>
 #include <features.h>
 #include <fnmatch.h>
 #include <fts.h>
 #include <obstack.h>
 #include <stdio_ext.h>
 #include <sys/mman.h>

That doesn't mean it's impossible to find those headers, just that
they're not in Fedora's mingw packages.  But really, I think it's safe
to ignore Windows issues in elfutils...

:)