See PR32227. Executable sections should not be padded with zero by default. On some architectures, 0x00 is the start of a valid instruction sequence, so can confuse disassembly between InputSections (and indeed the start of the next InputSection in some situations). Further, in the case of misjumps into padding, padding may start to be executed silently.
On x86, the "0xcc" byte represents the int3 trap instruction. It is a single byte long so can serve well as padding. This change switches x86 (and x86_64) to use this value for padding in executable sections, if no linker script directive overrides it. It also puts the behaviour into place making it easy to change the behaviour of other targets when desired. I do not know the relevant instruction sequences for trap instructions on other targets however, so somebody should add this separately.
Because the old behaviour simply wrote padding in the whole section before overwriting most of it, this change also modifies the padding algorithm to write padding only where needed. This in turn has caused a small behaviour change with regards to what values are written via Fill commands in linker scripts, bringing it into line with ld.bfd. The fill value is now written starting from the end of the previous block, which means that it always starts from the first byte of the fill, whereas the old behaviour meant that the padding sometimes started mid-way through the fill value. See the test changes for more details.
This function doesn't use any member variable of OutputSection, so it should be a non-member function.