This is the mail archive of the 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: Problem with GDB when debugging IRQ handlers

On Tue, Jun 28, 2011 at 03:37:59PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 28, 2011 at 03:30:14PM +0100, Catalin Marinas wrote:
> > Actually since the return address is in S_PC (which maybe gdb assumes it
> > would be the saved LR), this is probably not be correct. After SVC
> > entry, we have he following structure on the stack:
> > 
> > 	ORIG_r0
> > 	CPSR
> > 		<--- assuming this is the Call Frame Address (SP+S_PC+4)
> > 	PC	<--- CFA - 4
> > 	LR	<--- don't care
> > 	SP	<--- CFA - 12
> > 	...
> If I'm reading this correctly, it's not correct.
> parent SP -->	parent context stack
> 		[possible empty word]
> 		ORIG_r0
> 		parent context CPSR
> 		parent context PC
> 		parent context LR
> 		parent context SP
> 		...
> new SP -->	R0
> That empty word may or may not be present if the parent SP is aligned to
> a 64-bit boundary.

But it shouldn't matter if we tell gdb that the previous SP (parent) is
stored in the current stack at CFA - 12. It calculates CFA by adding
S_PC+4 to the current SP, in which case the possible empty word doesn't

But please note that I don't have any gdb experience, so we need someone
else to confirm.


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