On Wed, Aug 26, 2009 at 9:20 PM, David Brownell wrote:
> On Wednesday 26 August 2009, Ųyvind Harboe wrote:
>> > Does i.MX31 have one of the cores which extends Thumb
>> > with new instructions? I'm not sure they're all fully
>> > supported for use by the simulator. Worth looking at
>> > once you
On Wednesday 26 August 2009, Øyvind Harboe wrote:
> > Does i.MX31 have one of the cores which extends Thumb
> > with new instructions? I'm not sure they're all fully
> > supported for use by the simulator. Worth looking at
> > once you have the ARM instructions behaving. :)
>
> openocd arm11 ta
On Wed, Aug 26, 2009 at 9:06 PM, David Brownell wrote:
> On Wednesday 26 August 2009, Ųyvind Harboe wrote:
>> > If anything, they should be *more* separate.
>> >
>> > The whole simulator bears some thought though. Is the whole
>> > point of it just to enable one type of single stepping? I
>> > do
On Wednesday 26 August 2009, Øyvind Harboe wrote:
> > If anything, they should be *more* separate.
> >
> > The whole simulator bears some thought though. Is the whole
> > point of it just to enable one type of single stepping? I
> > don't recall seeing comments about when/why the simulator
> > wo
On Wed, Aug 26, 2009 at 5:58 PM, David Brownell wrote:
> On Wednesday 26 August 2009, Igor Skochinsky wrote:
>> As for ARM, I think arm_simulator.c and arm_disassembler.c should be
>> merged since they share a lot of functionality.
>
> They seem kind of separate to me. I can disassemble without
>
Hi,
On Wed, Aug 26, 2009 at 17:58, David Brownell wrote:
> On Wednesday 26 August 2009, Igor Skochinsky wrote:
>> As for ARM, I think arm_simulator.c and arm_disassembler.c should be
>> merged since they share a lot of functionality.
>
> They seem kind of separate to me. I can disassemble without
On Wednesday 26 August 2009, Igor Skochinsky wrote:
> As for ARM, I think arm_simulator.c and arm_disassembler.c should be
> merged since they share a lot of functionality.
They seem kind of separate to me. I can disassemble without
wanting to simulate. And vice versa.
If anything, they should
On Wed, Aug 26, 2009 at 4:50 PM, Igor Skochinsky wrote:
> On Wed, Aug 26, 2009 at 16:29, Øyvind Harboe wrote:
>> I've worked on refactoring the arm simulation code
>> to be able to support non-armv4_5 targets. The
>> approach is to define an interface that the caller
>> has to support. See below fo
On Wed, Aug 26, 2009 at 16:29, Øyvind Harboe wrote:
> I've worked on refactoring the arm simulation code
> to be able to support non-armv4_5 targets. The
> approach is to define an interface that the caller
> has to support. See below for example.
>
> Thoughts? Objections?
I think there is no need
I've worked on refactoring the arm simulation code
to be able to support non-armv4_5 targets. The
approach is to define an interface that the caller
has to support. See below for example.
Thoughts? Objections?
int arm_simulate_step(target_t *target, uint32_t *dry_run_pc)
{
armv4_5_c
Any thoughts on how to solve the arm11 single stepping
support?
If the hardware does not support single stepping, then the
instruction must be emulated and a breakpoint must
be set on the next instruction.
This code has been written for arm7/9, but it
relies on the armv4_5 structure which the ARM
11 matches
Mail list logo
