This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PowerPC prologue analysis


Daniel Jacobowitz wrote:
On Mon, Jul 28, 2008 at 04:29:18PM -0400, Aleksandar Ristovski wrote:
Thanks for the link! I briefly looked at the patch and it seems to address some of the things I am talking about (r30-r31 issue) but the comment still reads:

+     All gpr's from saved_gpr to gpr31 are saved (except during the
+     prologue).  */

Is that in the ABI? I would think that if it is, then the code I am looking at is not according to it (gcc issue or just me not understanding powerpc assembly?).

Sorry, I don't know which.



There seems to be no such statement in the PowerPC ABI "all gpr's from saved_gpr to gpr31 are saved" - non-volatile registers do not need to be stored in this manner. For example, a function may save r29 but not r30 and r31. However PPC prologue analysis in gdb will assume there is r31 saved as well which will make unwind_register(r31) fail (fetch bogus value). (Note: I am using gcc 4.2.3).


Another assumption made in gdb code is that if multiple registers are saved by the prologue, they will be saved in the ascending index order - I am not sure this is a requirement stated in the ABI either. (Is it?) I believe there could be cases where registers are saved in different order, e.g. r30, r28, r29, etc... Hopefully this doesn't happen in practise.

I think your patch with gpr_mask covers the first case (not all registers saved) but the second issue (if real issue) is still not handled.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]