Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hot-code reloading on macOS/arm64 with Zig

jakubkonka.com

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Hot-code reloading on macOS/arm64 with Zig

#11

Post by kubkon »

pmalynin wrote: post #9
kubkon wrote: post #8

Earlier quoted context omitted.

Hey, author of the article here. Thanks for the suggestion! I actually didn't know about the MAP_JIT flag to mmap before and will defo consider it. As to elevating your privs - this is just a temp solution until I work out how to add this entitlement https://developer.apple.com/documentation/bundleresources/en... to the Zig compiler. I wrote the default Zig's MachO linker from scratch and it can embed the adhoc code…

The only entitlement that is relevant here is get-task-allow. But that would allow anyone to get a control task port for your application and do with it as they may. This functionality was not designed to be used in production — except for debugging. The debugger entitlement is even more powerful, but once again since you’re modifying your own memory you don’t need it.

Wait, but what about debuggers then? Plus hot-code reloading should only ever be used for quick development cycles when prototyping your app in debug mode, so very much what a debugger is used for, right? Additionally, I actually based the implementation of this PoC on lldb's debugserver for macOS.

Re: Hot-code reloading on macOS/arm64 with Zig

#12

Post by saagarjha »

pmalynin wrote: post #2

Why not simply use MAP_JIT? There is no need to do these weird tricks, plus you’re putting your process and the rest of the system at risk by elevating privilege and using task-for-pid.

You’ll need to get the task port of the child process if you want to patch code in it.

Re: Hot-code reloading on macOS/arm64 with Zig

#13

Post by saagarjha »

pmalynin wrote: post #9
kubkon wrote: post #8

Earlier quoted context omitted.

Hey, author of the article here. Thanks for the suggestion! I actually didn't know about the MAP_JIT flag to mmap before and will defo consider it. As to elevating your privs - this is just a temp solution until I work out how to add this entitlement https://developer.apple.com/documentation/bundleresources/en... to the Zig compiler. I wrote the default Zig's MachO linker from scratch and it can embed the adhoc code…

The only entitlement that is relevant here is get-task-allow. But that would allow anyone to get a control task port for your application and do with it as they may. This functionality was not designed to be used in production — except for debugging. The debugger entitlement is even more powerful, but once again since you’re modifying your own memory you don’t need it.

The entitlement exists to enable development workflows like these.

Re: Hot-code reloading on macOS/arm64 with Zig

#14

Post by pmalynin »

kubkon wrote: post #11
pmalynin wrote: post #9

Earlier quoted context omitted.

The only entitlement that is relevant here is get-task-allow. But that would allow anyone to get a control task port for your application and do with it as they may. This functionality was not designed to be used in production — except for debugging. The debugger entitlement is even more powerful, but once again since you’re modifying your own memory you don’t need it.

Wait, but what about debuggers then? Plus hot-code reloading should only ever be used for quick development cycles when prototyping your app in debug mode, so very much what a debugger is used for, right? Additionally, I actually based the implementation of this PoC on lldb's debugserver for macOS.

Yeah this entitlement says your application is still “in-development” and allows a debugger to modify its executable memory.

Re: Hot-code reloading on macOS/arm64 with Zig

#15

Post by saagarjha »

stingraycharles wrote: post #7
chrisseaton wrote: post #4

> Instead of having your program managed by a running side-by-side loader program, what if the compiler would “simply” update the memory of the running process? You will most inevitably think I have gone completely crazy This isn't crazy - this is how just-in-time compilers work.

It is a bit crazy if you do it for hot code reloading, though, as the logic has now changed. In the case of JIT, it may swap the bytecode but the flow of execution remains the same. Hot code reloading usually requires a different approach.

Yep, a JIT will typically use on-stack replacement to keep execution coherent. Hot code reloading has to deal with the semantics of the code changing out from under it, which is substantially more complicated to deal with (and many implementations do not really handle this very well).

Re: Hot-code reloading on macOS/arm64 with Zig

#16

Post by metadat »

stingraycharles wrote: post #7
chrisseaton wrote: post #4

> Instead of having your program managed by a running side-by-side loader program, what if the compiler would “simply” update the memory of the running process? You will most inevitably think I have gone completely crazy This isn't crazy - this is how just-in-time compilers work.

It is a bit crazy if you do it for hot code reloading, though, as the logic has now changed. In the case of JIT, it may swap the bytecode but the flow of execution remains the same. Hot code reloading usually requires a different approach.

In the case of JIT, it may swap the Bytecode but the flow of execution remains the same.

Are you able to elaborate on this further?

1a. Does this mean the process gets restarted during reload?

1b. If no restart, how are active threads handled? What if a thread should no longer exist post-reload?

Re: Hot-code reloading on macOS/arm64 with Zig

#18

Post by [deleted] »

chrisseaton wrote: post #4

> Instead of having your program managed by a running side-by-side loader program, what if the compiler would “simply” update the memory of the running process? You will most inevitably think I have gone completely crazy This isn't crazy - this is how just-in-time compilers work.

[deleted]
Post reply on HN