Add FatElf format support to elf image activator

[mmokhi]

Summary

This only adds FatElf support to elf image activator, results in ability of running all supported kinds of Elf in Fat format too (Linux's Elfs, FreeBSD's Elfs, etc).

There's another patch for adding support of producing these files, i plan to make (which is a separate thing).

[cem]

style(9): Don't mix initialization with definitions.

Otherwise, I don't know anything about fatelf or image activation. So I don't know how I ended up on this review.

[mmokhi]

Style (9) related issues (mixing declarations and initialization) fixed.

[mmokhi]

Correcting castings and their warnings (as expected to be).

[brooks]

The implementation seems fine as far as it goes give my understanding of the feature. There are quite a lot of white space style(9) problems in the diff, mostly due to indentation of multi-line statements having more than the specified four extra spaces. Phabriator is a lousy place to address these issues so I won't comment further here.

I don't think we should include this feature without a clear use case and it should be a kernel option even then. I think the more interesting cases are more likely to be in dynamic binaries not static ones. Without a source of fat binaries (either someone shipping them or tooling to build them in a way that seems useful) this is more likely to be a security risk than a useful feature. One use case I have though of would be to build fat libraries for (e.g.) video CODECs optimized for particular CPU features. That would let us do more optimization in the package system and provide a single shared library that targeted different vector units, etc.

[emaste]

One use case I have though of would be to build fat libraries for (e.g.) video CODECs optimized for particular CPU features.

Generally speaking I think we'd use GNU ifunc for that case, no?