[lld] r192930 - Fill gap in .text with NOP.
Sean Silva
silvas at purdue.edu
Thu Oct 17 16:37:47 PDT 2013
On Thu, Oct 17, 2013 at 7:13 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Thu, Oct 17, 2013 at 4:04 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> On Thu, Oct 17, 2013 at 3:54 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>>
>>> On Thu, Oct 17, 2013 at 3:45 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>> Author: ruiu
>>>> Date: Thu Oct 17 17:45:16 2013
>>>> New Revision: 192930
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=192930&view=rev
>>>> Log:
>>>> Fill gap in .text with NOP.
>>>>
>>>
>>> It almost seems like it would be better to fill with UD1 or something
>>> that won't actually execute if a stray jump lands here?
>>>
>>
>> The MSVC toolchain uses int3 to pad things for this reason. I think the
>> gnu toolchain tries to get clever and write really wide nops, since the CPU
>> still decodes unexecuted instructions. Not sure if it matters at all.
>>
>
> I remember that in IA32/64 optimization manual published by Intel says
> that you could place a UD2 after a branch instruction to stop machine code
> decoding. Not sure if it makes sense for a gap between functions, as the
> last instruction is almost always unconditional branch instruction RET.
>
That advice is specifically for indirect branches that don't have the
fall-through as a destination, which isn't going to be the case most of the
time (exceptions would be e.g. interpreters that work by tail-calling
through a jump table).
-- Sean Silva
>
> Comparing UDx and INT 3, INT 3 looks better because it's a one byte
> instruction. UDx are two bytes. That means by using INT 3, we don't need to
> worry about some invalid jump instruction would jump in the middle of UDx.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131017/42c53566/attachment.html>
More information about the llvm-commits
mailing list