proomt

Search

Search posts, papers, and topics

All posts

Raymond Chen1 min readadvanced

Windows on Itanium also provided for hot-patching, in an even simpler way

Summary

Windows hot-patching on Itanium involved overwriting the first instruction bundle with a `nop` and a `brl.cond.sptk target64` instruction. This was simpler than x86 due to Itanium's fixed-size instruction bundles and a direct 64-bit long branch instruction.

  • Itanium used fixed-size instruction bundles, each encoding three instructions.
  • Hot-patching on Itanium overwrites the first bundle with `nop` and a double-wide `brl.cond.sptk target64`.
  • The `brl` instruction directly accepts a 64-bit target, simplifying the jump.
  • Indirect jumps require moving the target to a branch register, not a general-purpose register.

Low-level systems engineers and those interested in historical CPU architectures will find this a specific explanation of how hot-patching was implemented on Itanium, contrasting it with other architectures.

7/10

Related reading

  1. What's been going on in w64devkit the past year

    This post details a year of significant updates to w64devkit, a Windows development kit, including enhanced release security with code signing and immutability, and a multilib x64 toolchain. It also introduces new build tools like CMake, Ninja, and Ccache, alongside a custom C11 threads implementation and improvements to Binutils and GCC.

    Chris Wellonsnullprogram.com8 minHN212lobste.rs4
  2. One App, More Than One Native Window

    Codename One now supports true native desktop windows via a new `Window` class that separates per‑surface state (paint queue, input routing, native peers) from the global `Display`. The change adds a `PaintSurface` abstraction, platform‑specific window back‑ends (AWT/Swing, Direct2D, GTK, UIWindowScene), and a migration path for components that assumed a single `Form`. Initial release has some UI…

    CodeName Onecodenameone.com11 min