This is an archive of the discontinued LLVM Phabricator instance.

COFF: Create a separate "section" for the file header
ClosedPublic

Authored by labath on Oct 17 2019, 4:54 AM.

Details

Summary

In an attempt to ensure that every part of the module's memory image is
accounted for, D56537 created a special "container section" spanning the
entire image. While that seemed reasonable at the time (and it still
mostly does), it did create a problem of what to put as the "file size"
of the section, because the image is not continuous on disk, as we
generally assume (which is why I put zero there). Additionally, this
arrangement makes it unclear what kind of permissions should be assigned
to that section (which is what my next patch does).

To get around these, this patch partially reverts D56537, and goes back
to top-level sections. Instead, what I do is create a new "section" for
the object file header, which is also being loaded into memory, though
its not considered to be a section in the strictest sense. This makes it
possible to correctly assign file size section, and we can later assign
permissions to it as well.

Event Timeline

labath created this revision.Oct 17 2019, 4:54 AM
jankratochvil added inline comments.
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
797

dropped /*file_size*/

clayborg added inline comments.
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
794

maybe name this "COFF header" or "PECOFF header"?

labath marked 4 inline comments as done.Oct 18 2019, 4:50 AM
labath added inline comments.
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
794

good idea.

797

somehow I thought that a non-trivial argument value does not need a comment, but you're right that this is still ambiguous. Adding it back.

labath updated this revision to Diff 225600.Oct 18 2019, 4:50 AM
labath marked 2 inline comments as done.

Address review comments

Looks and sounds good to me, although I'm not familiar with this code and its context yet - so I'm not sure if I'm qualified to formally approve it.

mstorsjo accepted this revision.Oct 21 2019, 1:22 PM

I've happened to poke around a bit more in this piece of code now recently, and it does indeed seem reasonable.

This revision is now accepted and ready to land.Oct 21 2019, 1:22 PM
amccarth accepted this revision.Oct 21 2019, 1:38 PM

I'm OK with this. I'm just wondering whether it would be a good idea to make it clear that these header sections are "not considered to be a section in the strictest sense." Is the distinction going to be important to future code readers? Do we already have "sections" that aren't truly "sections"?

Perhaps just a comment where the header sections are created?

I'm OK with this. I'm just wondering whether it would be a good idea to make it clear that these header sections are "not considered to be a section in the strictest sense." Is the distinction going to be important to future code readers? Do we already have "sections" that aren't truly "sections"?

Perhaps just a comment where the header sections are created?

Both ELF and MachO have the concept of a "segment", which is the thing which describes how objects are loaded into memory. These are also represented as "sections" in lldb (and real sections are their "subsections"). However, this is the only case where we're inventing a "section" out of thin air, but that seems reasonable as neither elf nor mach-o have a concept of a piece of file which is loaded into memory, but is not a part of any section/segment.

So yeah, sure, adding a comment sounds like a good idea.

labath closed this revision.Oct 25 2019, 3:14 PM

Committed as 73a7a55.