RE: disassembly options

["Dave Korn" <dave dot korn at artimi dot com>]

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
> -mike

  (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.)

  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.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....