On 23 Oct, 2009, at 02:02, David Brownell wrote:
> On Thursday 22 October 2009, Colin Howarth wrote:
>> 1318,1319c1318,1319
>> < LOG_ERROR("should never reach this point");
>> < return -1;
>> ---
>> > snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%8.8"
>> PRIx32
>> "\tDATA", address, opcode);
>> > return 0;
>
> So you propose that every place the disassembler
> receives garbage it should print it out as DATA?
> Or just that *one* place?
Well, it should do something other than dying, or silently ignoring
it :-)
Generally I trust (ARM) assemblers to output correct code. On this
assumption
garbage, ie. anything unrecognized, is _potentially_ data. The LOG_ERROR
I replaced was the last catch-all case in the arm_evaluate_opcode
procedure.
There were two others so I guess they should be replaced too.
> Better approach: treat them all as undefined opcodes.
> That's more correct, in any case...
Whether they are labelled as undefined opcodes or data doesn't bother
me.
> If you could provide a fix in the format "git diff"
> produces, such a change could be applied as a patch
> using "patch -p1 < yourstuff" and then merged.
OK, I'll go and learn git, sometime. *grumble, grumble*
> Note that you should generate such a patch against
> the latest code.
OK, but don't you have the stable v. bleeding edge thing? I downloaded
openocd-0.2.0 since it was supposed to be the latest stable release. (?)
> You can download a snapshot from
> the gitweb interface, if you like. In any case,
> like 1318 doesn't look *anything* like that in the
> current code, so I have no idea which of the many
> stupid "should not reach this point" messages you
> ran into ...
Well, I only got ONE "should not reach this point" — because it stopped
disassembling there :-)
--colin
PS. I can't consider myself an OpenOCD developer yet - I'm still
learning.
I'm also going through the code which was in the Hitex STR9-comstick.
The raw disassembler output isn't ideal, ie. what I would have
written, so
it's taking a while...
Bit pointless really though, since *my* beagle_board has just
arrived :-)
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
