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 Sun 9 Sep 2007 17:34, Dave Korn pondered:
> On 08 September 2007 05:15, Robin Getz wrote:
> > 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 guess it depends on the sort of code the compiler tends to generate on
>   your target.  Depending how scheduled it is, it might well be the case
>   that you almost always get the right answer.  So I reckon it's still
>   useful, but maybe you want to make it a --verbose option, and slap a
>   medium-sized health warning on the docs.    

I didn't see a --verbose option in objdump, are you recommending that I add
that? (No problem in doing so, I'm just asking for clarification).

> > What I was hoping to do was be able to handle instructions like:
> > 
> >   R0 = W[P2 + 4] (Z);
> > 
> > and be able to identify which register was being read, but I don't think
> > this is possible. (Unless someone has a smarter idea than I?).
> 
>   Well, if you're going for a linear analysis, you might as well keep a
>   last-known P2 value kicking around, mightn't you. 

Yes - that is exactly when I am doing.

>   It could get confused 
>   if somebody's not disassembling in a straight line, but we're only hoping
>   for an approximation anyway.   

That is my concern - most code has these pesky jumps, and isn't very linear...

It would work fine for code like this (which is part of the linux kernel for 
Blackfin):

  P2.H = 0xffe0;       /* (-32)        P2=0xffe02ec0(-2085184) */
  R0.H = 0xffa0;       /* (-96)        R0=0xffa0fff4(-6225932) */
  P2.L = 0x2008;       /* (8200)       P2=0xffe02008(-2088952) */
  R0.L = 0x100c;       /* (4108)       R0=0xffa0100c <_evt_nmi>(-6287348) */
  [P2] = R0;           /* P2 = 0xffe02008 <EVT2> */
  R0.H = 0xffa0;       /* (-96)        R0=0xffa0100c <_evt_nmi>(-6287348) */
  R0.L = 0xa5c;        /* (2652)       R0=0xffa00a5c <_trap>(-6288804) */
  [P2 + 0x04 ] = R0;   /* P2 + 4 = 0xffe0200c <EVT3> */
  R0.H = 0xffa0;       /* (-96)        R0=0xffa00a5c <_trap>(-6288804) */
  R0.L = 0xf80;        /* (3968)       R0=0xffa00f80 <_evt_ivhw>(-6287488) */
  [P2 + 0x0c] = R0;    /* P2 + 12 = 0xffe0200c <EVT3> */
  R0.H = 0xffa0;       /* (-96)        R0=0xffa00f80 <_evt_ivhw>(-6287488) */
  R0.L = 0x1010;       /* (4112)       R0=0xffa01010 <_evt_timer>(-6287344) */
  [P2 + 0x10] = R0;    /* P2 + 16 = 0xffe02018 <EVT6> */
  R0.H = 0xffa0;       /* (-96)        R0=0xffa01010 <_evt_timer>(-6287344) */
  R0.L = 0x1028;       /* (4136)       R0=0xffa01028 <_evt_evt7>(-6287320) */
  [P2 + 0x14] = R0;    /* P2 + 20 = 0xffe0201C <EVT7> */

and this:

  P5.H = 0x13;         /* ( 19)        P5=0x130000 */
  P5.L = 0xabec;       /* (-21524)     P5=0x13abec <_loops_per_jiffy> */
  R0 = 0x1000 (X);     /*              R0=0x1000 <_run_init_process>(4096) */
  [P5] = R0;           /* P5 = 0x13abec <_loops_per_jiffy> */


but not this (where pointer indirection is encountered):

  P2.H = 0xac;         /* (172)        P2=0xac9a0c <_dma_pages> */
  P1 = R2;
  P2.L = 0x9a08;       /* (-26104)     P2=0xac9a08 <_dma_page> */
  P2 = [P2];           /* P2 = 0xac9a08 <_dma_page> */
  P2 = P2 + (P1 << 0x2);
  R0 += 0x1;           /* (  1) */
  [P2++] = R2;         /* I have no idea what P2 is */

-Robin


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