Thread with 23 posts
jump to expanded postI finally did a write-up of how touchHLE works. well, an important part of it, anyway!
new blog post: “touchHLE in depth, part 1: a day in the life of a function call”
https://hikari.noyu.me/blog/2023-04-13-touchhle-in-depth-1-function-calls.html
bump for the morning crowd
the thing I originally wanted to write up was the Objective-C runtime, but then I realised that to understand how message sending works, you would really need to grasp how function calls work…
can’t believe I wrote something this long and published it with only one typo included
ah of course, there was a material technical error lurking in there: I can’t believe I didn’t notice that I claimed the stub functions do a tail call and that the dynamic linker looks at the stack to see which stub function calls it. only one of those can be true. fixed now…
@hikari New technology: Tail calls with a call stack. :o
@cr1901 I Can’t Believe It’s Not Stackless technology
@hikari Yea, I've been meaning to grok stackless/stackful coroutines, their differences, and I just haven't had the bandwidth plus chunk of time to dedicate to it. Not while I'm putting off 5 other things that I need to fix in "embedded Rust targets not named ARM" :/.
@hikari That was very interesting, thanks for sharing in so much detail! Iike that you linked to the source code in between :)
@ChH1999 I’m glad you enjoyed it! linking to the source code was important to me, I wanted the post to be helpful in understanding the code. you might notice though that until I get to the ABI part, there’s very few source code links. that’s because the code that actually talks to dynarmic is broken into several layers that don’t really make sense to link to in isolation
Technically it’s S_SYMBOL_STUBS/S_LAZY_SYMBOL_POINTERS ;)
@saagar oh no, can those sections be renamed? the way touchHLE loads Mach-O files probably deviates substantially from how Apple’s code does, because I basically started by looking inside some binaries to find interesting things and worked backwards from there to figure out how to load them.
@saagar ah, of course, there’s an integer type value on each section, and my code never looks at it… well, I can easily fix that :)
@saagar oh huh, it’s only these stub sections and a handful of other things that get special type values. all the Objective-C sections must be matched by name rather than by type, I guess:
touchHLE::mach_o: Reading "Monkey Ball"
touchHLE::mach_o: Section: "__text" 0x2000 (0x3d13c bytes), type 0
touchHLE::mach_o: Section: "__symbol_stub4" 0x3f13c (0x984 bytes), type 8
touchHLE::mach_o: Section: "__const" 0x3fac0 (0x683c bytes), type 0
touchHLE::mach_o: Section: "__cstring" 0x462fc (0x6150 bytes), type 2
touchHLE::mach_o: Section: "__dyld" 0x4d000 (0x1c bytes), type 0
touchHLE::mach_o: Section: "__la_symbol_ptr" 0x4d01c (0x32c bytes), type 7
touchHLE::mach_o: Section: "__mod_init_func" 0x4d348 (0x1a0 bytes), type 9
touchHLE::mach_o: Section: "__nl_symbol_ptr" 0x4d4e8 (0x1e8 bytes), type 6
touchHLE::mach_o: Section: "__const" 0x4d6d0 (0xc58 bytes), type 0
touchHLE::mach_o: Section: "__cfstring" 0x4e328 (0x150 bytes), type 0
touchHLE::mach_o: Section: "__gcc_except_tab" 0x4e478 (0x78c bytes), type 0
touchHLE::mach_o: Section: "__objc_selrefs" 0x4ec04 (0x19c bytes), type 5
touchHLE::mach_o: Section: "__objc_classrefs" 0x4eda0 (0x60 bytes), type 0
touchHLE::mach_o: Section: "__objc_superrefs" 0x4ee00 (0xc bytes), type 0
touchHLE::mach_o: Section: "__objc_classlist" 0x4ee0c (0xc bytes), type 0
touchHLE::mach_o: Section: "__objc_catlist" 0x4ee18 (0xc bytes), type 0
touchHLE::mach_o: Section: "__objc_protolist" 0x4ee24 (0xc bytes), type 0
touchHLE::mach_o: Section: "__objc_imageinfo" 0x4ee30 (0x8 bytes), type 0
touchHLE::mach_o: Section: "__data" 0x4ee38 (0x2720 bytes), type 0
touchHLE::mach_o: Section: "__bss" 0x51558 (0x3958 bytes), type 1
touchHLE::mach_o: Section: "__common" 0x54eb0 (0x300 bytes), type 1
@saagar the blog post is now out of date, touchHLE trunk now looks at the section type :)
@saagar well, __la_symbol_ptr seems to be alive and well on x64 macOS, at least.
something I wonder about is why __symbol_stub4 (and __picsymbolstub4, which I omitted for simplicity) have that 4 suffix. 4 bytes per pointer? I can’t be bothered to figure it out though :)
@saagar nah, this is older than iOS 4
@saagar hmm, when I look at an iPhone OS 3.2 app, there’s __symbolstub1 instead :)
@hikari Thanks for sharing, this is so awesome!