[llvm-dev] [ELF] [RFC] Padding between executable sections

[Martin J. O'Riordan via llvm-dev]

With Gnu this is handled by the FILL command or using the ‘=N’ expression.  For example:

SECTIONS {

  .text : { *(.text) *(.text.*) } = 0xCC

}

I must admit, I haven’t yet used LLD, but I would have expected that it would be functionally equivalent to Gnu ld?

            MartinO

 

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Henderson via llvm-dev
Sent: 10 March 2017 16:19
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] [ELF] [RFC] Padding between executable sections

 

Hi,

I was doing some experiments with LLD and noticed that it pads out OutputSections with null bytes in all cases (as far as I could tell). However, for executable sections on some targets, 0x00 forms part of an executable instruction that is not nop. In particular, for x86_64 targets at least, the sequence 0x00 0x00 is an add instruction. This can result in confusing disassembly.

For example, on x86_64, given a simple InputSection that is a single "0xc3 retq" instruction, and given an alignment of 16 bytes, 15 null bytes are inserted between the end of that InputSection and the next. In the disassembly I then see the retq instruction followed by a series of adds, the last of which actually consumes 1 or more bytes of the next section to form a valid instruction, which can in turn throw off the disassembly of the following instructions at the start of the next section.

What do people think about using a target-specific nop instruction sequence to pad executable sections? Another possible option, on x86_64 at least (I haven't investigated other targets), is to use the 0xcc interrupt instruction.

Regards,

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170310/7c18061a/attachment.html>