This is an archive of the discontinued LLVM Phabricator instance.

Add DefinedAtom::sectionSize().
Needs RevisionPublic

Authored by ruiu on Jun 6 2014, 1:06 AM.

Details

Summary

Merge::mergeByLargestSection is defined in terms of section size,
but there was no way to get the section size for an atom. Previously
we followed layout-before/layout-after chains to collect all atoms
for a section, but that's not the right way to do it because there's
no guarantee that layout-before/layout-after exist. Even if they
exist, it's not guaranteed that they represent a section.

So this patch adds sectionSize() member function to DefinedAtom.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 10168.Jun 6 2014, 1:06 AM
ruiu retitled this revision from to Add DefinedAtom::sectionSize()..
ruiu updated this object.
ruiu edited the test plan for this revision. (Show Details)
ruiu added reviewers: Bigcheese, shankarke, atanasyan.
ruiu added a subscriber: Unknown Object (MLST).

Iis this because of associated sections ? That you cannot get the section size ?

Can you please let us know why you can't get the section size from the layout after references / layout before references.

I am not in agreement for this as there is not a use of this on MachO or ELF.

ruiu added a comment.Jun 6 2014, 10:53 AM

It's not related to associated sections.

As I wrote in the parch description, layout-before and layout-after are
mechanisms to layout atoms in some order, and it's not always guaranteed to
be the same as sections. The current implementation that to be removed by
this parch is a hack that depends on an incorrect assumption that
layout-after/layout-before can be used to walk all atoms in the same
section.
2014/06/06 22:47 "Shankar Easwaran" <shankar.kalpathi.easwaran@gmail.com>:

Iis this because of associated sections ? That you cannot get the section
size ?

Can you please let us know why you can't get the section size from the
layout after references / layout before references.

I am not in agreement for this as there is not a use of this on MachO or
ELF.

http://reviews.llvm.org/D4042

atanasyan edited edge metadata.Jun 13 2014, 3:32 AM

Is it possible to keep the sectionSize() method in the COFFDefinedAtom class only? In general every defined atom has non-zero section size. But this method returns a sensible result for a very specific set of atoms.

shankarke edited edge metadata.Jun 13 2014, 6:37 AM

We wont be able to keep the sectionSize in COFFDefinedAtom because the Native/YAML only understand DefinedAtoms. I was proposing a way to do this earlier by having atoms contain a set of key value pairs (key=>value) that can be used to set various values.

We could start a discussion on the thread, and arrive at a way to solve this if you think we should do that.

I like this idea because now I try to figure out how to propagate the --as-needed from the ELFFileNode::parse() to the point where we create the DT_NEEDED dynamic tag. Your idea might be a solution to this problem too.

ruiu added a comment.Jun 13 2014, 12:15 PM

Adding generic key-value pair container to DefinedAtom class will probably end up with too limited or too generic code. If we limit the type of value to int64 (or some fixed-type size), it'd be pretty easy to dump it to YAML/Native, but it's restricted so it won't solve the problems we have. On the other hand, if we allow arbitrary type, it's hard to handle and needs custom dumper for Native anyway.

The thing I'd like to focus here is not the above one, but this. Merge::mergeByLargestSection is already there, and its definition is "pick the atom according to its source section size". However it currently lacks the way to get the section size for an atom. It's just wrong. Merge::mergeByLargestSection should go away (which we don't want) or we need a way to get a section size for an atom.

In general the patch is LGTM. The only thing concerns me is that we start to populate 'Core' classes by functions which really used by the single target.

ruiu added a comment.Jun 23 2014, 10:32 AM

I basically agree, we have to be careful not to bloat Core with lots of target specific stuff. However something that is needed for linking stage itself needs to be in Core, and we already have quite a lot for ELF. I'd think this change is small and acceptable.

shankarke requested changes to this revision.Jun 23 2014, 2:46 PM
shankarke edited edge metadata.
shankarke added subscribers: kledzik, Bigcheese.

I am not sure which instance in the Core Atom model that you are pointing at. The core atom model models generically for all flavors, I dont see something in the Atom model specifically designed for ELF.

That said, please check with Nick before you would like to commit this change.

This revision now requires changes to proceed.Jun 23 2014, 2:46 PM

It is not ideal to add DefinedAtom::sectionSize() to every platform, when this is only needed in rare cases on one platform.

A more pay-to-play approach would be to require mergeByLargestSection atoms to have a (group?) reference to a new atom which has a special ContentType and is a placeholder for the section, and its size() method returns the size of the section. The resolver, when finding a mergeByLargestSection atom looks for the Reference to the magic "section" atom and gets its size for comparison. The PE/COFF Writer would then also need to ignore atoms of the special contentType atoms.

ruiu added a comment.Jun 23 2014, 3:16 PM

DefinedAtom::sectionSize() is basically free if your atom does not have mergeByLargestSection attribute. It's a virtual function so it'll use one more slot for vftable, but that's it. There's no extra cost for each atomwhich does not use mergeByLargestSection. Making a virtual group atom only for size would work, but it's too complicated.

Yes, adding a virtual method is "free" in that it does not increase the size of each object, but this patch alone does not solve the round-trip (yaml/native) that Shankar brought up. My suggestion to add an atom representing the section and a reference from the mergeByLargestSection atom to the section atom, does work with round tripping.

The extra section atom and reference are not just arbitrary. They actually correspond to this merge mode. The atom is saying "pick me if my section is biggest". The reference answers the question "what is your section?" and the section atom answers the question "what is your section's size".

But there may also be another approach to this. Rather than have the SymbolTable understand all the merge modes, maybe we can have it call out to the LinkingContext to pick between custom modes? Or have it support mergeByLargestSection by calling out to the LinkingContext for the section size of a particular atom?

I would think adding a reference to another atom, and querying the atom for the size could be the approach we may want to take here.

The LinkingContext approach may work but it doesnot fit in the atom model properly IMHO.

atanasyan resigned from this revision.Feb 2 2016, 10:27 PM
atanasyan removed a reviewer: atanasyan.