I was just playing around and I stumbled upon the following code near the end of the function


I am talking about the two seemingly useless jumps starting at the highlighted instruction.
Any comments on this? What could this possibly do that a nop could not do?

Take up two less lines in a disassembly window? Flush the prefetch buffer? Make a debugging session slower because people waste time wondering about such things rather than concentrating on the task at hand? Legacy code from aeons ago? Erm ... or perhaps nothing?

I give in. What is the answer?

[ Post removed by author. ]

Incorrect disassembled code?
- no, it is disassembled correctly
Compiler generated code?
- I'm sure that is the case, but neither of the jumps is the target of another jump in the function, so they probably didn't come from an empty basic block of instructions
Take up two less lines in a disassembly window?
- 66 66 66 90 only takes up only one line and does the same thing
- plus, if the goal is alignment, this is a fairly poor choice given the proceeding code
Flush the prefetch buffer?
- This is interesting - so unconditional jumps may flush the (instruction) prefetch buffer?
Make a debugging session slower because people waste time wondering about such things rather than concentrating on the task at hand? Legacy code from aeons ago? Erm ... or perhaps nothing?
- This is too pragmatic - what if the goal is understanding?

kernelbase.dll is littered with such examples, here is another

This kind of code was written either my a machine or by a human, and it was written for a reason. I was just hoping someone here at this board had a good explanation of why such nonsense exists in my copy of windows...

[ Post removed by author. ]

Well, compilers do have a difficult task to perform, and sometimes the results of applying some algorithm A look strange to us because another algorithm B gives better results.

Certainly the compiler is not programmed like:


I hope you will not conclude that this thread is the same waste.

[ Post removed by author. ]

Maybe this code will be patched at run-time?
If it will be patched with one (shorter) byte sequence -- code will jump to one location.
When patched with sequence #2 (longer) -- then jump to a different location.
Of course, patching may happen on some condition, so you are not seeing it while stepping in debugger at the moment.

Windows likes to do the "hot" patching.

Good answer, these useless instructions do make it much easier to divert control, and that is probably what is happening.
But, the code was in a write/execute section only. So, I assume only the kernel can patch it???

VirtualProtect, WriteProcessMemory... global patching is trickier, though.

Going just by the screen shot, my guess is that since "lock xadd" can only be done in asm this has either interrupted the normal optimisation of the nested ifs or is the result of inline linking

It can be even LTCG-involved result. There are many kludges (like __declspec(thread)) in Visual C, probably only its programmers know what it's doing.