This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: disassembly options


On Mon 17 Sep 2007 07:40, Nick Clifton pondered:
> Hi Robin,
> 
> > A better/actually possible idea is:
> > 
> >      P2.L = 0x1f24   /* P2=0x12f4 */
> 
> Shouldn't this be:
> 
>         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 :)

> If your data flow analysis tells you that P2 was 0 before the instruction or:
> 
>         P2.L = 0x1f24   /* P2=????12f4 */
>
> If you do not know the value of the high bits of P2.

I also was not keeping track of when things get unknown (call clobbered, or
reads), since the compiler normally puts the 1/2 loads pretty close together,
and it is pretty obvious to even the casual reader what is going on.

> 
> >      P2.H = 0xffc0   /* P2=0xffc01f24(MDMA1_D0_CURR_ADDR) */;
> 
> I would suggest adding a little bit of white space to make things clearer:
> 
>         P2.H = 0xffc0   /* P2=0xffc01f24  (MDMA1_DO_CURR_ADDR) */;

No problem.
 
> (Btw is the semi-colon necessary ?)

It is in the Blackfin proprietary assembler - so we print it out in objdump
to attempt to keep things similar.

> Mind you this whole tracking of the values in registers business is going to 
> very complicated to do in a generic way.

Right - I was actually doing it today in /opcodes/bfin-dis.c - when we see an
immediate load instruction, we simulate it as well as printing out the output.

> 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? and depending on the IDE - it didn't use the gdb 
disassembly, but the source?


>  > The next question is - what is the most generic way to keep the memory mapped
>  > register address <-> names?
>  >
>  > I was thinking/hoping that an external xml file would be the best/easiest
>  > way.  (Since we already use something like this for an eclipse plugin).
> 
> 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 you need to map memory addresses to names a simple text  
> file will do the job just as well.

Text files are easy too.

-Robin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]