disassembly options

[Nick Clifton]

Hi Robin,

>>         P2.L = 0x1f24   /* P2=0x000012f4 */
> 
> Yes - P2 is an int (32 bit), but I wasn't printing the leading zeros today.
> The feedback from my limited sample size (me and Mike), said that this wasn't
> desired :)

My idea was that the leading zeros tell the reader that the register value 
tracker definitely knows that the top 16-bits are clear, rather than just being 
in an unknown state.

>> Maybe one approach would be 
>> to not display this information when performing a static analysis (ie via 
>> objdump -d) but instead to provide it when performing a disassembly for a third 
>> party which can provide dynamic analysis.  ie I am thinking of GDB here, using 
>> the opcodes library to provide a disassembly.  If the opcodes library provided 
>> a new API function to map memory addresses to mmr register names, then GDB 
>> could choose to display the mmr name as a comment when it is displaying a line 
>> of disassembly.  Since GDB would have access to the actual register values, it 
>> could be sure of getting the correct mmr name.
> 
> Hmm - that also would be handy, but I thought that gdb disassembled things before
> it actually executed them?

Mmm, good point.  Oh well, so much for that idea.


>> Hmm, I think that this would be overkill.  Presumably you are not going to 
>> write your own XML file parser, and I really would not want to see a new 
>> dependency upon a new host library added to objdump.  (Especially given that 
>> the binutils are often built to run on small OSes which may not have an XML 
>> parsing library). 
> 
> dlopen would fix that - wouldn't it? if expat isn't there - it doesn't get opened/used.

If the host OS supported dlopen, which is not at all guaranteed.

Cheers
   Nick