Re: disassembly options

[Mike Frysinger <vapier at gentoo dot org>]

On Friday 07 September 2007, Dave Korn wrote:
> On 07 September 2007 16:03, Mike Frysinger wrote:
> > On Friday 07 September 2007, Dave Korn wrote:
> >> On 07 September 2007 15:52, Nick Clifton wrote:
> >>> Hi Robin,
> >>>
> >>>> It would be nice to have something that automatically told me that the
> >>>> MMR at 0xffc00000 == "PLL_CTL", (the name actually means something -
> >>>> and is referenced in the standard processor documentation), and get
> >>>> something that looks like:
> >>>>
> >>>>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
> >>>>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
> >>>>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
> >>>
> >>> I think that this would be useful.
> >>>
> >>> You may find however that implementing it in a nice generic way will
> >>> mean that you will have to rewrite the symbol/address decoding part of
> >>> the disassembler. Not that this would be a bad thing, it could
> >>> certainly use a tidy up.
> >>
> >>   Won't the real tricky bit be in performing the data flow analysis? 
> >> There are relocs on those two assignments.  There's nothing on the load
> >> indirect. I don't see how it could handle (sorry, don't speak bfin
> >> assembler, so this is a bit made up) stuff like:
> >
> > there are no relocs ... everything in the 0xffc00000 - 0xffffffff range
> > are MMR's on a Blackfin proc
>
>   (That doesn't necessarily mean that there aren't hi/lo relocs against
> *ABS* on those two assignments to P2.H, but I may have been reading too
> much in to that '1f24' which I otherwise couldn't see where it comes from.)

i think it'd be impossible to have an ABS reloc where the upper 16bits pointed 
to anything in 0xffc0 or higher on the Blackfin processor ...

>   In any case, regardless of whether there are relocs or the data is
> already in-place, the question of how to handle anything other than an
> exact sequence of load-pointer-by-halves-then-immediately-dereference-it
> remains the same.

what we have at the moment is a simple state machine that tracks all the 
registers and displays after any load to high or load as gcc may rearrange 
things on us, so there is no guarantee as to the order as such
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.