[llvm] r196334 - [Stackmap] Emit multi-byte nops for X86.

[Rafael Espíndola]

On 4 December 2013 14:00, Juergen Ributzka <juergen at apple.com> wrote:
> Hi Rafael,
>
> I already tried going down that path and adding emitNops to MCObjectStreamer was pretty easy, because you just need to add a fill fragment (and add nop emission support). Once that fragment gets emitted to the object file it simply calls the target specific writeNopData method. Unfortunately that doesn’t work for MCAsmStreamer. MCAsmStreamer just emits an align directive to perform the code alignment and the assembler that has to later on parse the assembly file has to deal with it. I don’t want to align the code - I need a nop slide of a given size that can be patched later on. I could take the raw bytes from writeNopData and write them with byte directives to the asm file, but that would be really ugly.

OK. I think I see why this is harder than the cfi case. We only
produce the eh_frame at the end of the file and it is a new section.
That way it is easy to use text or object streamer to print the
correct data.

In the case of nops once we know the size of the align fragment we are
long done with streaming that section.

>Another way is to change the interface and implementation of writeNopData and return a vector of MCInst instructions that can be emitted by both - MCObjectStreamer and MCAsmStreamer. Besides changing every backend implementation it also would require some more work on X86 to emit operations with multiple OpSize prefixes which isn't supported either. It’s a lot of changes to all targets (that don’t even need it) just to make the X86 case work. A third solution would be to just get the MCObjectStreamer case right and just emit simple nops in the asm file, but that would generate different binaries depending on which path you take through the pipeline.
>
> What do you think?

I agree that the streamer that feeds itself back with the nop data
would be very cumbersome at best. I would probably still try to
refactor this to have a emitNops method at the streamer and then
change writeNopData to know how to print text nops to a MCAsmStreamer
or binary nops to a MCObjectWriter. It would be ugly, but at least we
would have the code for producing text and binary next to each other.

In any case, it is not as bad a duplication as it looked at first, so
just a FIXME pointing at writeNopData should be fine for now.

Thanks,
Rafael