1539 *use the timestamp as the point at which to modify the 1540* executable code. 1541 *The old instruction is recorded so that the event can be 1542* processed forwards or backwards. 1543 */
* 1544 perf_event_text_poke(text_poke_addr(&tp[i]), old, len, 1545 tp[i].text, len); 1546 } 1547 1548 if (do_sync) { 1549 /* 1550* According to Intel, this core syncing is very likely 1551 *not necessary and we'd be safe even without it. But 1552* better safe than sorry (plus there's not only Intel). 1553 */ 1554 text_poke_sync(); 1555 } 1556 1557 /* 1558 *Third step: replace the first byte (int3) by the first byte of 1559* replacing opcode. 1560 */
1520/* 1521 ¦* Emit a perf event to record the text poke, primarily to 1522 ¦* support Intel PT decoding which must walk the executable code 1523 ¦* to reconstruct the trace. The flow up to here is: 1524 ¦* - write INT3 byte 1525 ¦* - IPI-SYNC 1526 ¦* - write instruction tail 1527 ¦* At this point the actual control flow will be through the 1528 ¦* INT3 and handler and not hit the old or new instruction. 1529 ¦* Intel PT outputs FUP/TIP packets for the INT3, so the flow 1530 ¦* can still be decoded. Subsequently: 1531 ¦* - emit RECORD_TEXT_POKE with the new instruction 1532 ¦* - IPI-SYNC 1533 ¦* - write first byte 1534 ¦* - IPI-SYNC 1535 ¦* So before the text poke event timestamp, the decoder will see 1536 ¦* either the old instruction flow or FUP/TIP of INT3. After the 1537 ¦* text poke event timestamp, the decoder will see either the 1538 ¦* new instruction flow or FUP/TIP of INT3. Thus decoders can 1539 ¦* use the timestamp as the point at which to modify the 1540 ¦* executable code. 1541 ¦* The old instruction is recorded so that the event can be 1542 ¦* processed forwards or backwards. 1543 ¦*/ 1544 perf_event_text_poke(text_poke_addr(&tp[i]), old, len,