However it does report 4 other locations (which have the same structure). Not sure what these ones are for, but the one selected is the one referenced in GetFocusLensSubjectDistanceFromLens.I suppose that this is where not limiting the signature length can help in differentiating the correct one.
Quote from: barberofcivil on 26 / November / 2009, 13:02:19However it does report 4 other locations (which have the same structure). Not sure what these ones are for, but the one selected is the one referenced in GetFocusLensSubjectDistanceFromLens.I suppose that this is where not limiting the signature length can help in differentiating the correct one.Actually, in this particular example, extending the signature length fails. In all the reference builds (and even the SX10 dump) the GetFocusLensSubjectDistance function is followed immediately by another function instruction (either a STM or LDR then STM instruction set), but in the 200 dump, it is followed by a literal pool. So allowing the reference function to extend beyond the initial 10 instructions actually disqualifies the correct function.
One question about the sig finder. This function ends in a non-returning branch instruction (ie. the function is continued elsewhere). Does/can the sig finder be made to follow this branch instruction to build and compare function signatures?
QuoteActually, in this particular example, extending the signature length fails. In all the reference builds (and even the SX10 dump) the GetFocusLensSubjectDistance function is followed immediately by another function instruction (either a STM or LDR then STM instruction set), but in the 200 dump, it is followed by a literal pool. So allowing the reference function to extend beyond the initial 10 instructions actually disqualifies the correct function.Right, but in this case I decided that 1 bad match is better than 17 (and many more sub-versions) with 4+ partial matches. If I remember right, the 10 instruction limit meant that actually only 3 instructions were actually used (because as mentioned earlier, the sig finder ignores some instructions).
Actually, in this particular example, extending the signature length fails. In all the reference builds (and even the SX10 dump) the GetFocusLensSubjectDistance function is followed immediately by another function instruction (either a STM or LDR then STM instruction set), but in the 200 dump, it is followed by a literal pool. So allowing the reference function to extend beyond the initial 10 instructions actually disqualifies the correct function.
No, it doesn't follow branches at all. Updating it means re-working the whole system, because it will affect all existing files. The ability to branches has long been on my list of things for a "next generation" sig finder. Really, we shouldn't use the automatically generated files directly. Once a function is found and known correct, it should be "frozen" and only updated if needed (but somehow, we should maintain the information of how it was found in the first place). The whole thing is a hack and doesn't really scale to the number of cameras variants we have. It is also horribly inefficient, meaning that a full build of all the platforms, with sig matching takes well over an hour on my windows system.
How can you tell how many instructions it uses? In the signatures_dryos.h file, the signature carries 8 of the 10 instructions (looks like it always ignores STM/LDM instructions)
I agree that manually verified and inserted functions are best, but at least the sig generator helps a little. Especially in a case like this where I'm trying to correct/add some functions and there aren't necessarily people active and working on all the particular models anymore to do searching and testing.
At least there is a chance that the signature builder will help find them in some cases.I think if it could extend to direct branch instructions as suggested it may help a little too, at least for functions that get shortened in this manner. The difficulty would be in deciding what branches to follow. One suggestion is that it uses the user input length (in this case 10). If a branch is detected, it continues and follows that branch as if no length is present. If it isn't a branch, it acts as usual.
The other thing is you lose the information of how the function was found in the first place.
Quote from: reyalp on 26 / November / 2009, 20:20:59The other thing is you lose the information of how the function was found in the first place.Perhaps we could have a thread for adding function finding documentation for future reference? I could add the info for these functions as I have already basically outlined it here in this thread, but this thread could easily become buried down the road.
Hi barberofcivil and reyalp, i have install the build 844, but i can't find the Option in DOF Calculator "Stacked"My Camera are SX100 100cmany thanksHamster
Started by obsidian General Discussion and Assistance
Started by eliavecellio AllBest's Builds
Started by zeno General Discussion and Assistance
Started by joewatt Feature Requests
Started by TMHKR General Help and Assistance on using CHDK stable releases
