[PATCH] D135494: [BOLT] Section-handling refactoring/overhaul

[Maksim Panchenko via Phabricator via llvm-commits]

maksfb added a comment.

In D135494#3887977 <https://reviews.llvm.org/D135494#3887977>, @treapster wrote:

> @maksfb a patch is now not mature enough for RFC, but the idea is that we add more relocations including data-to-data, create them for plt, and emit all these sections with original names and call registerOrUpdate for each in EFMM. If we want to duplicate some section like .rodata, we can rename it to ".bolt.org.rodata" before emitting or emit it under a new name. In my original patch i used the latter, but for compatibility, i think renaming before emission should work. So, the general idea is that instead of this sorcery in EFMM we can call something like RenameDuplicatedSections() prior to emission(in RewriteInstance), where we decide based on options which sections we want rewritten and which duplicated, and then just emit everything under original name. Do you think it's a good idea? Or it won't work?

@treapster, to be clear, you don't need a patch to submit an RFC, we can have a discussion even before any code is produced. Having this discussion on discourse.llvm.org has other benefits.

BOLT has a special handling for input file sections because it tries to be as noninvasive as possible. The renaming that takes place in EFMM is happening b/c we don't have full control over what sections are emitted by MC layer. E.g., the new ".eh_frame" will be emitted by MC under ".eh_frame" name using special directives while emitting regular code. To avoid a conflict with the original ".eh_frame", EFMM uses prefixes. If you intent to update the original ".eh_frame", assuming the size hasn't increased, you can still do so, but you have to use a special prefix (OrgSecPrefix) while emitting it manually. That's how we handle in-place updates of ".data", ".rodata" etc.

If you are doing a full binary rewrite, you don't have to preserve the original section contents and location. I assume, you have full control over section size and placement too. You can create copies of input file sections, and then deregister the originals since you wouldn't need them while writing out the file. If the input file sections are removed from the list of sections, no renaming will take place inside EFMM.

For the patch, if possible, break it down to multiple small changes. E.g. I suspect you will have to handle more relocation types in BOLT, and that change could be fairly independent.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135494/new/

https://reviews.llvm.org/D135494