Page MenuHomeFreeBSD

Add FatElf format support to elf image activator
Needs ReviewPublic

Authored by mmokhi on Apr 2 2016, 5:13 PM.

Details

Reviewers
None
Group Reviewers
emulation
Contributor Reviews (base)
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).

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 3122
Build 3155: arc lint + arc unit

Event Timeline

mmokhi retitled this revision from to Add FatElf format support to elf image activator.
mmokhi updated this object.
mmokhi edited the test plan for this revision. (Show Details)
mmokhi set the repository for this revision to rS FreeBSD src repository - subversion.
cem removed a reviewer: 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.

cem requested changes to this revision.Apr 2 2016, 9:44 PM
cem added a reviewer: cem.
This revision now requires changes to proceed.Apr 2 2016, 9:44 PM
cem removed a reviewer: cem.
mmokhi edited edge metadata.
mmokhi removed rS FreeBSD src repository - subversion as the repository for this revision.
mmokhi changed the visibility from "All Users" to "Public (No Login Required)".

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

mmokhi set the repository for this revision to rS FreeBSD src repository - subversion.

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

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.

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?