This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: disassembly options
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....