[PATCH] D38260: [llvm-objcopy] Add support for removing sections

Jake Ehrlich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 5 18:00:43 PDT 2017


jakehehrlich added a comment.

In https://reviews.llvm.org/D38260#889154, @jhenderson wrote:

> I did an experiment using objcopy, to see what happened if it removes a SHF_ALLOC section in a linked ELF with segments. As it turns out, objcopy removes the section without warning or error, and leaves 0s in its place. This could be dangerous on x86 at least, I think. If you do this to an executable section, and there's still the ability to jump there, then this could lead to execution of invalid instructions. At the very least, we should write trap instructions in place of the removed section, if it is in the executable segment. Alternatively, I'm quite happy you emit an error in this case.
>
> A possible suggestion might be to have both behaviours, but have the "blank section" behaviour under another switch (e.g. --blank-section). This could be useful if the user wants to send somebody an ELF to inspect some specific characteristics, but without allowing them to actually run the program or see certain bits of data for whatever reason. I'd still replace the section contents with trap instructions in this case.


So someone on IRC requested that llvm-objcopy support the -j option. The particular way this is used is in conjunction with -O binary. This winds up showing a difference between what I did and what GNU objcopy actually does under the hood. GNU objcopy is section oriented not segment oriented. So if you use -O binary and -j  in conjunction it will output just the data from that specific section. In the process of thinking about how to support this it became clear to me that removing allocated sections is something that's important to support, we can't just throw an error. It also became clear that I need to make -O binary work differently but more on that later. I talked with Roland McGrath about what seemed like expected behavior since I was quite ambivalent about what should happen when you remove a section that's in the middle of a segment. I pitched writing with gap fill (zero by default but using <gap fill> from --gap-fill=<gap fill> otherwise) vs just keeping the segment data. Roland seemed to think that keeping the segment data made no sense at all. This being the case it makes most sense to copy what GNU objcopy does. This also gives you both behaviors by default. Namely if you don't want a section overwritten with zeros just don't remove it. So to support the only change we would make is to just leave Object::writeSectionData alone rather than having it write segment data out first. In the --strip-sections diff we then remove only the non-allocated sections and don't emit the section header table. Everything should be consistent with what GNU objcopy does in the relevant cases.


Repository:
  rL LLVM

https://reviews.llvm.org/D38260





More information about the llvm-commits mailing list