On Thursday 22 October 2009, Colin Howarth wrote:
> On 23 Oct, 2009, at 02:02, David Brownell wrote:
> >
> > 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.
"Potentially data" ... actually, the arch spec talks
about "potentially code", and you asked to treat it
as code; so "undefined opcode" is more consistent.
> > 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.
I'd go for "undefined opcode".
> > 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*
You don't really have to do that, but the relevant bits
are *really* easy:
git clone ...
bootstrap
configure --enable-maintainer-mode ...
build ... yay, it works!
change some code
build, test, verify
git diff > my.patch
> > 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. (?)
Our policy is to accept patches against reasonobly current
code ... we're *very* near a 0.3 release now.
> > 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 :-)
Yes, they're all equally stupid. I'd hate to fix just
one, and find it's not the one you ran into! ;)
> --colin
>
>
> PS. I can't consider myself an OpenOCD developer yet - I'm still
> learning.
Learning never ends. If that's your criterion, you
will never reach "yet"!
> 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 :-)
Well, if you're using a Beagle there will probably be a few
other things you can learn. And maybe even find ways to
submit a few not-yet-developer patches, if you want. :)
- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
