Re: winedbg: Respect Thumb mode when adjusting PC on ARM
Le 10/03/2012 18:26, André Hentschel a écrit :
--- programs/winedbg/be_arm.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/programs/winedbg/be_arm.c b/programs/winedbg/be_arm.c index c39043c..6c1cc05 100644 --- a/programs/winedbg/be_arm.c +++ b/programs/winedbg/be_arm.c @@ -205,13 +205,15 @@ static void be_arm_clear_watchpoint(CONTEXT* ctx, unsigned idx)
static int be_arm_adjust_pc_for_break(CONTEXT* ctx, BOOL way) { + INT step = (ctx->Cpsr& 0x20) ? 2 : 4; hmm the way winedbg works might put us in trouble here...
when winedbg is entered with a break exception: 1/ winedbg calls adjust_pc_for_break(..., TRUE) to get the PC to the real location of the break insn (and not after, as most CPU report in break exception handler) 2/ user interacts with winedbg 3/ user resumes execution, and winedbg calls again adjust_pc_for_break(..., FALSE) but, the ctx passed here is the context used to resume execution... and in ARM case Cpsr could have been changed by user in step 2/ leading to wrong PC computation in 3/ therefore, if we want to plug that hole, I'd suggest having two context used in winedbg (the incoming one (never being changed), and the current/outgoing one), and that we pass the two contexts in winedbg to do the right thing here A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Le 11/03/2012 09:18, Eric Pouech a écrit :
Le 10/03/2012 18:26, André Hentschel a écrit :
--- programs/winedbg/be_arm.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/programs/winedbg/be_arm.c b/programs/winedbg/be_arm.c index c39043c..6c1cc05 100644 --- a/programs/winedbg/be_arm.c +++ b/programs/winedbg/be_arm.c @@ -205,13 +205,15 @@ static void be_arm_clear_watchpoint(CONTEXT* ctx, unsigned idx)
static int be_arm_adjust_pc_for_break(CONTEXT* ctx, BOOL way) { + INT step = (ctx->Cpsr& 0x20) ? 2 : 4; hmm the way winedbg works might put us in trouble here...
when winedbg is entered with a break exception: 1/ winedbg calls adjust_pc_for_break(..., TRUE) to get the PC to the real location of the break insn (and not after, as most CPU report in break exception handler) 2/ user interacts with winedbg 3/ user resumes execution, and winedbg calls again adjust_pc_for_break(..., FALSE)
but, the ctx passed here is the context used to resume execution... and in ARM case Cpsr could have been changed by user in step 2/ leading to wrong PC computation in 3/
therefore, if we want to plug that hole, I'd suggest having two context used in winedbg (the incoming one (never being changed), and the current/outgoing one), and that we pass the two contexts in winedbg to do the right thing here
A+
and I forgot my question... is it possible for the user to change the cpsr value? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Am 11.03.2012 09:40, schrieb Eric Pouech:
Le 11/03/2012 09:18, Eric Pouech a écrit :
Le 10/03/2012 18:26, André Hentschel a écrit :
--- programs/winedbg/be_arm.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/programs/winedbg/be_arm.c b/programs/winedbg/be_arm.c index c39043c..6c1cc05 100644 --- a/programs/winedbg/be_arm.c +++ b/programs/winedbg/be_arm.c @@ -205,13 +205,15 @@ static void be_arm_clear_watchpoint(CONTEXT* ctx, unsigned idx)
static int be_arm_adjust_pc_for_break(CONTEXT* ctx, BOOL way) { + INT step = (ctx->Cpsr& 0x20) ? 2 : 4; hmm the way winedbg works might put us in trouble here...
when winedbg is entered with a break exception: 1/ winedbg calls adjust_pc_for_break(..., TRUE) to get the PC to the real location of the break insn (and not after, as most CPU report in break exception handler) 2/ user interacts with winedbg 3/ user resumes execution, and winedbg calls again adjust_pc_for_break(..., FALSE)
but, the ctx passed here is the context used to resume execution... and in ARM case Cpsr could have been changed by user in step 2/ leading to wrong PC computation in 3/
therefore, if we want to plug that hole, I'd suggest having two context used in winedbg (the incoming one (never being changed), and the current/outgoing one), and that we pass the two contexts in winedbg to do the right thing here
A+
and I forgot my question... is it possible for the user to change the cpsr value? A+
No, he can't. That only would happen (at least for the 0x20 of cpsr) if the user moves the PC to a codepart, which is Thumb and it was ARM before (or vise versa). AFAIK he can't do that. -- Best Regards, André Hentschel
participants (2)
-
André Hentschel -
Eric Pouech