[Pdbg] [PATCH v3 12/13] libpdbg/chip.c: ram_instructions add error handling

[Nicholas Piggin]

I think we just have to go through it case by case.

In most cases the workbook doesn't really say how to best recover from
errors, and I suspect in some cases when you start getting scom
errors or you've written the wrong thing to registers, there's probably
no longer a path back to sanity anyway. So I wouldn't put a huge
priority on catching all those things.

For cases where an operation has an expected and well defined failure
(like ramming an instruction causes an exception), I think we should
try to cope with them.

Thanks,
Nick

On Tue, 08 May 2018 11:39:00 +1000
Alistair Popple <alistair at popple.id.au> wrote:

> Yeah, (lib)pdbg error handling is pretty broken generally as I just left it as a
> giant "TODO". Open to any thoughts on how we could improve it generally.
> 
> - Alistair
> 
> On Wednesday, 2 May 2018 4:28:07 PM AEST Nicholas Piggin wrote:
> > Pass errors back to the caller, and clean up with ram_destroy on
> > failure.
> > 
> > Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
> > ---
> >  libpdbg/chip.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libpdbg/chip.c b/libpdbg/chip.c
> > index 79bc87d..ebfaaa8 100644
> > --- a/libpdbg/chip.c
> > +++ b/libpdbg/chip.c
> > @@ -168,7 +168,11 @@ static int ram_instructions(struct pdbg_target *thread_target, uint64_t *opcodes
> >  			opcode = mfspr(1, 277);
> >  		}
> >  
> > -		CHECK_ERR(thread->ram_instruction(thread, opcode, &scratch));
> > +		if (thread->ram_instruction(thread, opcode, &scratch)) {
> > +			PR_DEBUG("%s: %d\n", __FUNCTION__, __LINE__);
> > +			exception = 1;
> > +			break;
> > +		}
> >  
> >  		if (i == -2)
> >  			r1 = scratch;
> >   
> 
>