On Wed, 29 Jun 2011, Mikulas Patocka wrote: > > Now, if we are getting stack trace from "g" function, the code scanner > > sees both > > ldo 144(%r30),%r30 > > ldo -144(%r30),%r30 > > No, it actually stops when frame_size == (e->Total_frame_size << 3) > > But I still don't understand the purpose of decoding those stack pointer > decrement instruction. Due to bug in the code, every such stack pointer > decrement adds 0x100000000 to the frame size and causes a crash. Understand. The purpose of decoding the stack pointer adjustments probably was to handle the case where the .callinfo frame size information is missing or wrong. This is probably a remnant from when binutils was generating incorrect unwind data... Thus, you are correct that the negative adjustments should be ignored. In large frames, I believe that the adjustment is done in more than one instruction. It is quite unlikely that the pc in a backtrace will occur before the positive adjustment or after the negative adjustment. If the above is a problem, it probably would be fairly simple to check whether the pc lies between the entry point and the positive adjustment. Similarly, for the negative adjustment. In both cases, the adjustments have to be in the same code basic block as the entry/return. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
