Kanbaru 🌟 (one hikari of too many)
I 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
3 replies
Saagar Jha
(replying to Kanbaru 🌟 (one hikari of too many))
Technically it’s S_SYMBOL_STUBS/S_LAZY_SYMBOL_POINTERS ;)
Kanbaru 🌟 (one hikari of too many)
(replying to Saagar Jha)
@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.
1 replies
Saagar Jha
(replying to Kanbaru 🌟 (one hikari of too many))
Kanbaru 🌟 (one hikari of too many)
(replying to Saagar Jha)
@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 Jha
(replying to Kanbaru 🌟 (one hikari of too many))
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
@saagar hmm, when I look at an iPhone OS 3.2 app, there’s __symbolstub1 instead :)
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
@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 :)
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
@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
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
@saagar the blog post is now out of date, touchHLE trunk now looks at the section type :)
Christopher Hahn
(replying to Kanbaru 🌟 (one hikari of too many))
@hikari That was very interesting, thanks for sharing in so much detail! Iike that you linked to the source code in between :)
2 replies
Kanbaru 🌟 (one hikari of too many)
(replying to Christopher Hahn)
@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
Saagar Jha
(replying to Christopher Hahn)
Edi'Hael :verified:
(replying to Kanbaru 🌟 (one hikari of too many))
@hikari thanks for the write-up, was a nice read and I feel like I vaguely know what's going on now! If I ever have time, I'll try myself at GDBing touchHLE, too. There's a specific game I have in mind… ^^
Kanbaru 🌟 (one hikari of too many)
(replying to Edi'Hael :verified:)
@edihael FWIW the GDB support is only really useful when the app’s gotten into some broken state, e.g. it’s trying to dereference a null pointer and that pointer didn’t come from touchHLE. for all the high-level stuff, printf debugging is the way to go :p
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
bump for the morning crowd
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
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…
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
can’t believe I wrote something this long and published it with only one typo included
Kanbaru 🌟 (one hikari of too many)
(replying to Kanbaru 🌟 (one hikari of too many))
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…
William D. Jones
(replying to Kanbaru 🌟 (one hikari of too many))
@hikari New technology: Tail calls with a call stack. :o
Kanbaru 🌟 (one hikari of too many)
(replying to William D. Jones)
@cr1901 I Can’t Believe It’s Not Stackless technology