[PATCH] D30886: [ELF] Pad x86 executable sections with 0xcc int3 instructions

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In https://reviews.llvm.org/D30886#699194, @joerg wrote:

> Does this have any impact on compressibility of executables? E.g. gzip or xz.


Without knowing much (or really anything) about the compression algorithms used, I cannot say for certain. A number of factors would likely be involved, including the number of input sections and amount of padding required between each, which will depend on alignment requirements. I would guess that it may have a small negative impact in general, but given that all padding between executable sections will be the same sequence of bytes, at least for x86, I don't expect it to be significant.

Do you have or know of any straightforward way to test this?



================
Comment at: ELF/Target.h:102
+
+  uint32_t DefaultExecutableFill = 0;
 };
----------------
hfinkel wrote:
> hfinkel wrote:
> > Making this a uint32_t implies (at least to me) that it might make sense for the value to be something other than a single repeated byte. Does it make sense for it to be something other than that?
> > 
> Never mind; the value needs to be some multiple of the length of the trap instruction, or similar, which is likely uses the smallest available encoding size (whatever that happens to be for the target architecture). So long as we never need to fill in regions smaller than that, then there should be no ambiguity.
Also of note is that LLD and ld.gold use 32-bit integers as the input for the FILL directive, which is the way to override this value via a linker script.


https://reviews.llvm.org/D30886