disassembly options

disassembly options

[Robin Getz]

Today in objdump, MIPS supports a -M reg-names=ARCH option, where the 
disassembler will print CPU-specific register names as appropriate for the 
selected CPU or architecture.

I was wondering if it made sense to extend this so it not only named core 
registers, but memory mapped registers as well...

For example, in Blackfin when we want to access a memory mapped register, we 
load the address into a pointer register, and do a read or write. Today the 
Disassembler puts out something like:

    20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
    20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
    20ec:       10 95           R0 = W[P2] (Z);

Since we don't have 32-bit atomic loads, we need to load up each 16-bit half 
into a register, and then dereference it.

It would be nice to have something that automatically told me that the MMR at 
0xffc00000 == "PLL_CTL", (the name actually means something - and is 
referenced in the standard processor documentation), and get something that 
looks like:

    20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
    20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
    20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;

Thoughts? I thought if this was a nice thing for all SoC devices (ARM, MIPS, 
Blackfin, AVR32, FRV, SH, PPC, etc), I would try to do things in as generic 
way as possible. If everyone thinks this is stupid, then I will continue to 
look things up by hand...

-Robin

Re: disassembly options

[Nick Clifton]

Hi Robin,

> It would be nice to have something that automatically told me that the MMR at 
> 0xffc00000 == "PLL_CTL", (the name actually means something - and is 
> referenced in the standard processor documentation), and get something that 
> looks like:
> 
>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;

I think that this would be useful.

You may find however that implementing it in a nice generic way will mean that 
you will have to rewrite the symbol/address decoding part of the disassembler. 
  Not that this would be a bad thing, it could certainly use a tidy up.

Cheers
   Nick

RE: disassembly options

[Dave Korn]

On 07 September 2007 15:52, Nick Clifton wrote:

> Hi Robin,
> 
>> It would be nice to have something that automatically told me that the MMR
>> at 0xffc00000 == "PLL_CTL", (the name actually means something - and is
>> referenced in the standard processor documentation), and get something
>> that looks like: 
>> 
>>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
>>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
>>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
> 
> I think that this would be useful.
> 
> You may find however that implementing it in a nice generic way will mean
> that you will have to rewrite the symbol/address decoding part of the
>   disassembler. Not that this would be a bad thing, it could certainly use
> a tidy up. 

  Won't the real tricky bit be in performing the data flow analysis?  There
are relocs on those two assignments.  There's nothing on the load indirect.  I
don't see how it could handle (sorry, don't speak bfin assembler, so this is a
bit made up) stuff like:

  P2.H = 0xffc0   /* 0xffc01f24 */;
  P2.L = 0x0      /* 0xffc00000 */;
  if (condition) goto LABEL
  P2.H = 0xffc0   /* 0xffc01f28 */;
  P2.L = 0x0      /* 0xffc00000 */;
LABEL:
  R0 = W[P2] (Z)  /* ???Don't know??? */;

or 

SUBROUTINE:
  R0 = W[P2] (Z)  /* ???Was set on entry, could be anything ??? */;

or even just

  P2.H = 0xffc0   /* 0xffc01f24 */;
  P2.L = 0x0      /* 0xffc00000 */;
  ( lots of instructions that don't alter P2)
  R0 = W[P2] (Z)  /* ???Don't know??? */;

...?  

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: disassembly options

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Friday 07 September 2007, Dave Korn wrote:
> On 07 September 2007 15:52, Nick Clifton wrote:
> > Hi Robin,
> >
> >> It would be nice to have something that automatically told me that the
> >> MMR at 0xffc00000 == "PLL_CTL", (the name actually means something - and
> >> is referenced in the standard processor documentation), and get
> >> something that looks like:
> >>
> >>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
> >>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
> >>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
> >
> > I think that this would be useful.
> >
> > You may find however that implementing it in a nice generic way will mean
> > that you will have to rewrite the symbol/address decoding part of the
> >   disassembler. Not that this would be a bad thing, it could certainly
> > use a tidy up.
>
>   Won't the real tricky bit be in performing the data flow analysis?  There
> are relocs on those two assignments.  There's nothing on the load indirect.
>  I don't see how it could handle (sorry, don't speak bfin assembler, so
> this is a bit made up) stuff like:

there are no relocs ... everything in the 0xffc00000 - 0xffffffff range are 
MMR's on a Blackfin proc
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

RE: disassembly options

[Dave Korn]

On 07 September 2007 16:03, Mike Frysinger wrote:

> On Friday 07 September 2007, Dave Korn wrote:
>> On 07 September 2007 15:52, Nick Clifton wrote:
>>> Hi Robin,
>>> 
>>>> It would be nice to have something that automatically told me that the
>>>> MMR at 0xffc00000 == "PLL_CTL", (the name actually means something - and
>>>> is referenced in the standard processor documentation), and get
>>>> something that looks like: 
>>>> 
>>>>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
>>>>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
>>>>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
>>> 
>>> I think that this would be useful.
>>> 
>>> You may find however that implementing it in a nice generic way will mean
>>> that you will have to rewrite the symbol/address decoding part of the
>>>   disassembler. Not that this would be a bad thing, it could certainly
>>> use a tidy up.
>> 
>>   Won't the real tricky bit be in performing the data flow analysis?  There
>> are relocs on those two assignments.  There's nothing on the load indirect.
>>  I don't see how it could handle (sorry, don't speak bfin assembler, so
>> this is a bit made up) stuff like:
> 
> there are no relocs ... everything in the 0xffc00000 - 0xffffffff range are
> MMR's on a Blackfin proc
> -mike

  (That doesn't necessarily mean that there aren't hi/lo relocs against *ABS*
on those two assignments to P2.H, but I may have been reading too much in to
that '1f24' which I otherwise couldn't see where it comes from.)

  In any case, regardless of whether there are relocs or the data is already
in-place, the question of how to handle anything other than an exact sequence
of load-pointer-by-halves-then-immediately-dereference-it remains the same.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: disassembly options

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

On Friday 07 September 2007, Dave Korn wrote:
> On 07 September 2007 16:03, Mike Frysinger wrote:
> > On Friday 07 September 2007, Dave Korn wrote:
> >> On 07 September 2007 15:52, Nick Clifton wrote:
> >>> Hi Robin,
> >>>
> >>>> It would be nice to have something that automatically told me that the
> >>>> MMR at 0xffc00000 == "PLL_CTL", (the name actually means something -
> >>>> and is referenced in the standard processor documentation), and get
> >>>> something that looks like:
> >>>>
> >>>>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
> >>>>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
> >>>>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
> >>>
> >>> I think that this would be useful.
> >>>
> >>> You may find however that implementing it in a nice generic way will
> >>> mean that you will have to rewrite the symbol/address decoding part of
> >>> the disassembler. Not that this would be a bad thing, it could
> >>> certainly use a tidy up.
> >>
> >>   Won't the real tricky bit be in performing the data flow analysis? 
> >> There are relocs on those two assignments.  There's nothing on the load
> >> indirect. I don't see how it could handle (sorry, don't speak bfin
> >> assembler, so this is a bit made up) stuff like:
> >
> > there are no relocs ... everything in the 0xffc00000 - 0xffffffff range
> > are MMR's on a Blackfin proc
>
>   (That doesn't necessarily mean that there aren't hi/lo relocs against
> *ABS* on those two assignments to P2.H, but I may have been reading too
> much in to that '1f24' which I otherwise couldn't see where it comes from.)

i think it'd be impossible to have an ABS reloc where the upper 16bits pointed 
to anything in 0xffc0 or higher on the Blackfin processor ...

>   In any case, regardless of whether there are relocs or the data is
> already in-place, the question of how to handle anything other than an
> exact sequence of load-pointer-by-halves-then-immediately-dereference-it
> remains the same.

what we have at the moment is a simple state machine that tracks all the 
registers and displays after any load to high or load as gcc may rearrange 
things on us, so there is no guarantee as to the order as such
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: disassembly options

[Nick Clifton]

Hi Dave,

>   In any case, regardless of whether there are relocs or the data is already
> in-place, the question of how to handle anything other than an exact sequence
> of load-pointer-by-halves-then-immediately-dereference-it remains the same.

My assumption is that whatever algorithm Robin uses it will not guarantee to 
detect these special memory addresses, it will only try its best.  ie it would 
detect simple instruction sequences or maybe well known patterns of 
instructions and leave it at that.  (In fact if Robin is being really clever 
the algorithm might take as input a set of regular expressions to match 
instruction patterns and return a name of the memory location when a hit occurs).

Cheers
   Nick

Re: disassembly options

[Robin Getz]

On Fri 7 Sep 2007 10:59, Dave Korn pondered:
> On 07 September 2007 15:52, Nick Clifton wrote:
> 
> > Hi Robin,
> > 
> >> It would be nice to have something that automatically told me that the
> >> MMR at 0xffc00000 == "PLL_CTL", (the name actually means something - 
> >> and is referenced in the standard processor documentation), and get
> >> something that looks like: 
> >> 
> >>     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
> >>     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
> >>     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
> > 
> > I think that this would be useful.
> > 
> > You may find however that implementing it in a nice generic way will mean
> > that you will have to rewrite the symbol/address decoding part of the
> >   disassembler. Not that this would be a bad thing, it could certainly use
> > a tidy up. 
> 
>   Won't the real tricky bit be in performing the data flow analysis? 

Yes - my first example sucked/was wrong. It would be nice to do it with flow,
but at the present, I don't think that is possible in objdump, as everything 
is linear.

A better/actually possible idea is:

     P2.L = 0x1f24   /* P2=0x12f4 */
bunch of instructions
     P2.H = 0xffc0   /* P2=0xffc01f24(MDMA1_D0_CURR_ADDR) */;
     P2.L = 0x0      /* P2=0xffc00000(PLL_CTL) */;
bunch of instructions
     R0 = W[P2] (Z);

The First load, since the address 12f4 is not a label, nor a MMR, it doesn't
print anything.

The next time the high part is loaded, P2=ffc01f24, which is a valid MMR, so it
prints out the name.

The P2 load half load is P2=0xffc00000, which again is a valid MMR, (PLL_CTL),
so it prints the name.

It is up to the human reading the code to look back and see what P2 really is,
for the exact code flow reasons you mentioned. Otherwise - you might as well
do it in a simulator (which wasn't my intention). 

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.

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?).

-Robin

RE: disassembly options

[Dave Korn]

On 08 September 2007 05:15, Robin Getz wrote:

>      P2.L = 0x1f24   /* P2=0x12f4 */
> bunch of instructions
>      P2.H = 0xffc0   /* P2=0xffc01f24(MDMA1_D0_CURR_ADDR) */;
>      P2.L = 0x0      /* P2=0xffc00000(PLL_CTL) */;
> bunch of instructions
>      R0 = W[P2] (Z);
> 
> The First load, since the address 12f4 is not a label, nor a MMR, it doesn't
> print anything.
> 
> The next time the high part is loaded, P2=ffc01f24, which is a valid MMR,
> so it prints out the name.
> 
> The P2 load half load is P2=0xffc00000, which again is a valid MMR,
> (PLL_CTL), so it prints the name.
> 
> It is up to the human reading the code to look back and see what P2 really
> is, for the exact code flow reasons you mentioned. Otherwise - you might as
> well do it in a simulator (which wasn't my intention).
> 
> 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.
 
> 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.  It could get confused if somebody's not disassembling in a straight line, but we're only hoping for an approximation anyway.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: disassembly options

[Robin Getz]

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

Re: disassembly options

[Nick Clifton]

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

Re: disassembly options

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 12:40:48PM +0100, Nick Clifton wrote:
> 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.

A lot of the time it doesn't; it's disassembling some other code
rather than the current code.  It would be able to sometimes, though.

Also GDB already has XML support.

-- 
Daniel Jacobowitz
CodeSourcery

Re: disassembly options

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Monday 17 September 2007, Nick Clifton wrote:
>  > 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.

we're looking at doing XML because the proprietary Blackfin toolchain group at 
ADI already maintains a bunch of XML files that describe all Blackfin 
parts ... that way we dont have to maintain them :)

but with a little xsltproc glue, we could easily transform those XML files 
into a flat address <-> name mapping ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: disassembly options

[Daniel Jacobowitz]

On Mon, Sep 17, 2007 at 01:41:03PM -0400, Mike Frysinger wrote:
> we're looking at doing XML because the proprietary Blackfin toolchain group at 
> ADI already maintains a bunch of XML files that describe all Blackfin 
> parts ... that way we dont have to maintain them :)
> 
> but with a little xsltproc glue, we could easily transform those XML files 
> into a flat address <-> name mapping ...

There's some evil examples of doing that in gdb/features/, FYI.

-- 
Daniel Jacobowitz
CodeSourcery

Re: disassembly options

[Robin Getz]

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

Re: disassembly options

[Nick Clifton]

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

Re: disassembly options

[Robin Getz]

On Tue 18 Sep 2007 06:36, Nick Clifton pondered:

> >> 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.
> 

OK - simple text file it is.

-Robin

Re: disassembly options

[Robin Getz]

On Fri 7 Sep 2007 10:52, Nick Clifton pondered:
> Hi Robin,
> 
> > It would be nice to have something that automatically told me that the 
> > MMR at 0xffc00000 == "PLL_CTL", (the name actually means something - 
> > and is referenced in the standard processor documentation), and get
> > something that looks like:
> > 
> >     20e4:       4a e1 c0 ff     P2.H = 0xffc0   /* 0xffc01f24 */;
> >     20e8:       0a e1 00 00     P2.L = 0x0      /* 0xffc00000 */;
> >     20ec:       10 95           R0 = W[P2] (Z)  /* PLL_CTL */;
> 
> I think that this would be useful.
> 
> You may find however that implementing it in a nice generic way will 
> mean that you will have to rewrite the symbol/address decoding part 
> of the disassembler.  Not that this would be a bad thing, it could 
> certainly use a tidy up. 

OK - I will have a look at this. I was thinking of doing something separate, 
(as opposed to put it in the common symbol lookup) to allow the arch specific 
implementation to get it only when it thought it was necessary. At least for 
Blackfin, there might be times when we don't want symbols, but only MMR names 
or visa versa.


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).

if '-M mmr-names=ARCH' is given, it looks for the './ARCH.xml' file. (as well 
as --include=dir). (assuming that we don't really want to recycle reg-names).

This allows new SOC to be supported without releasing/testing new toolchain 
binaries (just update/drop in some xml files beside your existing toolchain).

This would use the hated/loved expat lib which is already used/tested in gdb, 
and would include addition configure options (as in gdb):

  --with-libexpat-prefix[=DIR]  search for libexpat in DIR/include and DIR/lib
  --without-libexpat-prefix     don't search for libexpat in includedir and 
libdir

Comments/complaints welcome...

-Robin

Re: disassembly options

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Saturday 08 September 2007, Robin Getz wrote:
> This would use the hated/loved expat lib which is already used/tested in
> gdb, and would include addition configure options (as in gdb):
>
>   --with-libexpat-prefix[=DIR]  search for libexpat in DIR/include and
> DIR/lib --without-libexpat-prefix     don't search for libexpat in
> includedir and libdir

i imagine this could be made a lot less painful if we dlopen-ed libexpat ... 
then again, using libdl brings along its own host of haters ;)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: disassembly options

[Robin Getz]

On Sat 8 Sep 2007 01:25, Mike Frysinger pondered:
> On Saturday 08 September 2007, Robin Getz wrote:
> > This would use the hated/loved expat lib which is already used/tested in
> > gdb, and would include addition configure options (as in gdb):
> >
> >   --with-libexpat-prefix[=DIR]  search for libexpat in DIR/include and
> > DIR/lib --without-libexpat-prefix     don't search for libexpat in
> > includedir and libdir
> 
> i imagine this could be made a lot less painful if we dlopen-ed libexpat ... 
> then again, using libdl brings along its own host of haters ;)

I am open to do it either way - as long as their is some feeling that the 
direction is acceptable.

-Robin