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