Re: disassembly options

[Nick Clifton <nickc at redhat dot com>]

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