This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: a question about rs6k's prologue analysis
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>
- To: Wu Zhou <woodzltc at cn dot ibm dot com>
- Cc: gdb at sourceware dot org
- Date: Wed, 11 Oct 2006 16:15:58 +0530
- Subject: Re: a question about rs6k's prologue analysis
- References: <452CC397.5050304@cn.ibm.com>
- Reply-to: ramana dot radhakrishnan at codito dot com
I am guessing a bit but you could use it for "milli" calls to functions
to save callee save registers ? Was this done on the PowerPC at any
time ?
If it is in the first 3 instructions then maybe its a milli-call and you
might have other instructions in the prologue after that.
My 10 paise.
cheers
-Ramana
On Wed, 2006-10-11 at 18:12 +0800, Wu Zhou wrote:
> In function skip_prologue of rs6000-tdep.c, when it finds an instruction like "bl foo", and that it
> is not within the first three instructions of the prologue, the prologue analysis will stop.
>
> else if ((op & 0xfc000001) == 0x48000001)
> { /* bl foo,
> to save fprs??? */
>
> fdata->frameless = 0;
> /* Don't skip over the subroutine call if it is not within
> the first three instructions of the prologue. */
> if ((pc - fdata->func_start) > 8)
> break;
> ....
> }
>
> Any specific reason for this?
>
> I encountered some prologue code like this:
>
> 61a0: 7c 08 02 a6 mflr r0
> 61a4: 94 21 ff f0 stwu r1,-16(r1)
> 61a8: 93 e1 00 0c stw r31,12(r1)
> 61ac: 48 01 8a 81 bl 1ec2c <__JCR_END__+0x4>
> 61b0: 7f e8 02 a6 mflr r31
> 61b4: 90 01 00 14 stw r0,20(r1)
>
> In the first instruction, lr is saved in r0, its content is saved on stack at the last instruction.
> But between these two instruction, a "bl foo" instruction exists, which make skip_prologue return.
> In this scenario, gdb won't have any way to know where lr is saved on the stack. This might make the
> backtrace loops at this point.
>
> Could it be possible that we delete this conditional statement? I guess this will only make
> prologue analysis get a little longer. Any other impact?
>
> Or that some changes in the compiler's side is needed? But now that these code are already there,
> and it also seems that they work ok, I guess it is not very easy for compiler to change that.
>
> Any insight? Thanks a lot!
>
> Regards
> - Wu Zhou
--
Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>
Codito Technologies Pvt. Ltd.