test1_33 fails on ppc64 about dyninst HOT 8 CLOSED

Obsoleting #8.

from dyninst.

Jump table parsing is failing. Will get a parse log and toss it in gist tomorrow.

from dyninst.

I think I know the problem here. Currently parseAPI will invoke the new jump table parsing on every platform, which will then invoke the instruction semantic engine on Power or ARM and will fail miserably. I will get this fixed soon.

from dyninst.

The fix is in #37.

from dyninst.

Are our powerpc semantics not sufficient to cover jump tables, are they incompatible enough that the new algorithm can't use them, or is the algorithm itself not handling some common PPC idiom? This should work.

ARM not working is obviously not relevant, as we're not claiming to have a complete ParseAPI port for this release.

from dyninst.

For power, we currently have 32-bit instruction semantics and nothing for 64-bit instruction semantics. So the new jump table code should work for ppc32, but not ppc64.

The new jump table code was going to be invoked on ppc64 and ARM, which causes crashes. I changed jump table parsing on power to use the old heuristics and to simply give up on ARM.

I see your point that the new jump table code should work for ppc32, but I am not sure whether it is.

from dyninst.

I'll see if I can check ppc32 on vulcan.

Next question: does the newest ROSE have ppc64 semantics in any useful form? More generally, can you write up issues on non-x86 jump table parsing and what we need in order to move it to the new algorithm and create a non-9.2 milestone for them?

from dyninst.

Update: ppc32 is not practical for us to test. A naive implementation of ppc64 based on only what's in ppc32 is missing many critical instructions. Separate out the reversion to the old jump table algorithm from #37 and merge to master. I can create a new issue for the ppc64 semantic bits that are missing.

from dyninst.