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


Hi Robin,

A better/actually possible idea is:

P2.L = 0x1f24 /* P2=0x12f4 */

Shouldn't this be:


P2.L = 0x1f24 /* P2=0x000012f4 */

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.


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) */;

(Btw is the semi-colon necessary ?)


Mind you this whole tracking of the values in registers business is going to very complicated to do in a generic way. Since each architecture has different instructions for loading registers there is going to have to be a lot of call outs in your generic framework to target specific detection and analysis routines. Or at least a whole set of target specific instruction pattern matching expressions to locate the load and transfer instructions.


Also lots of targets load addresses like this from constant pools, rather than constructing them via instructions, so you may need to do some analysis to locate the address of the constant being loaded.


I think doing it like I was thinking before might provide 80% of the right
answers, but for those 20% where it is wrong, it could confuse the casual reader, and lead them down the wrong path during a debugging session.

I think that even 80% might be a bit optimistic. 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.



> 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). If you need to map memory addresses to names a simple text file will do the job just as well.

Cheers
  Nick


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