Page MenuHomePhabricator

[yaml2obj]Allow explicit setting of p_filesz, p_memsz, and p_offset

Authored by jhenderson on Mar 14 2019, 10:30 AM.



yaml2obj currently derives the p_filesz, p_memsz, and p_offset values from sections. This makes writing tests for certain formats more complex, and sometimes impossible. This patch allows setting these fields explicitly, overriding the default value, when relevant.

Diff Detail


Event Timeline

jhenderson created this revision.Mar 14 2019, 10:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2019, 10:30 AM
Herald added a subscriber: jdoerfert. · View Herald Transcript
jakehehrlich accepted this revision.Mar 14 2019, 12:26 PM

This is much needed. Thanks!

This revision is now accepted and ready to land.Mar 14 2019, 12:26 PM

I think there are some really funky tests in llvm-objcopy that we can fix now but it's going to take a careful eye to see which ones.

Oh also we can add PHDR tests to llvm-objcopy with this!

Thanks! Just to note that this does NOT force the sections that are in the segments to appear at different offsets than they otherwise would. That will require some different changes at some point, which I would certainly appreciate, but don't need at the moment, because you can use the section's address align value to achieve the same effect usually.

I have a minor question. I do not think it is really important so should not be stoppable for landing this.

53 ↗(On Diff #190663)

So out of curiosity: was it important for some reason to have an arbitrary numeric type here?
(and not a some kind of regular header)

This revision was automatically updated to reflect the committed changes.
jhenderson marked an inline comment as done.Mar 15 2019, 3:41 AM
jhenderson added inline comments.
53 ↗(On Diff #190663)

This was requested in an internal review of this before I put up a similar patch up for review previously. The idea is that the standard PT_* types have special semantics, and therefore by using a non-standard type, it bypasses any issues to do with it (and hopefully doesn't suggest that the type is important, together with the comment).

grimar added inline comments.Mar 15 2019, 3:54 AM
53 ↗(On Diff #190663)

I see, thanks.

(to clarify: the first thing I tried when saw this is to lookup in LLVM for 6abcdef0 and 0xabcdef0,
I did not instantly realize that it is just a set of alphabetical characters in order, but now after your reply
I re-read this place and that's looking fine for me now).