I don't think you are quite on the right track. w2c_rlbox_streqci has 3 arguments, not 2 like the source you quote, so that will make it real hard to match those up.
It does only have 2, but it is an original C source. What it does with it I don't know, if it doesn't second source it from elsewhere. It looks to me like some kind of ABI is involved that uses an instance to call off or for data, similar to an OOP call. I've seen this before where functions were called off a jump table, which confused the register layout with an extra pointer passed.
That's interesting. Does it cause a bad penalty on ppc64 if unaligned?The nops are almost certainly there to align the loop start with the icache line size (making it start at +16).
The strange r4 r5 sub is probably to have a single loop increment variable, but I expect that will be really hard to understand without finding the exact matching code and what that 3rd argument is about. That is besides that the bug could be very, very far away from the crash location, so not sure you are anywhere close to the issue (but I don't have any better suggestion).
I've noticed another discrepancy. Leading up to it the instance
is first parameter. But when it calls w2c_rlbox_streqci it has
instance last! Even optimised out it should still be in same spot
unless it rearranged registers for more confusion to suit itself.
I'm interested in step debugging through it. If I can get over the
way gdb is CLI based. I find a command interface isn't suited for
step debugging and makes it awkward. If anyone uses it directly
for real debugging.
-- My regards, Damien Stewart.