Lpc2000

Robert Adsett wrote:

> At 03:47 PM 2/18/05 +1100, Bruce Paterson wrote:
> 
>>>2/ When I display mixed assembly and code, and single step in this mode
>>>(code was flashed using serial port seperately) the order seems all
>>>screwed. It's like Insight has got which assembly belongs to which bit
>>>of C code all out of whack so the effect is you jump all over the C file
>>
>>Here's an example with just pure assembly. Insight console screen shows
>>this for library function _puts_r.  Note how it isn't sequential !
>>
>>-       0x4224  <_puts_r+8>:            sub     r11, r12, #4    ; 0x4
>>-       0x4228  <_puts_r+12>:           sub     sp, sp, #28     ; 0x1c
>>-       0x422c  <_puts_r+16>:           mov     r4, r0
>>-       0x4234  <_puts_r+24>:           mov     r5, r1
>>-       0x4230  <_puts_r+20>:           mov     r0, r1
>>-       0x4238  <_puts_r+28>:           bl      0x4880 <strlen>
>>-       0x4248  <_puts_r+44>:           mov     r6, r0
>>-       0x4264  <_puts_r+72>:           str     r5, [r11, #-52]
>>-       0x4274  <_puts_r+88>:           str     r6, [r11, #-48]
>>-       0x423c  <_puts_r+32>:           ldr     r3, [pc, #76]   ; 0x4290 <$d>
>>-       0x424c  <_puts_r+48>:           str     r3, [r11, #-44]
>>-       0x4240  <_puts_r+36>:           mov     r2, #1  ; 0x1
>>-       0x4250  <_puts_r+52>:           str     r2, [r11, #-40]
>>-       0x4244  <_puts_r+40>:           add     r12, r0, #1     ; 0x1
>>-       0x4268  <_puts_r+76>:           str     r12, [r11, #-28]
>>-       0x4254  <_puts_r+56>:           sub     r3, r11, #52    ; 0x34
>>-       0x426c  <_puts_r+80>:           str     r3, [r11, #-36]
>>-       0x4258  <_puts_r+60>:           add     r2, r2, r2
>>-       0x4270  <_puts_r+84>:           str     r2, [r11, #-32]
>>-       0x425c  <_puts_r+64>:           ldr     r0, [r4, #8]
>>-       0x4260  <_puts_r+68>:           sub     r1, r11, #36    ; 0x24
>>-       0x4278  <_puts_r+92>:           bl      0xa2bc <__sfvwrite>
> 
> 
> 
> That fit's with what I've seen.  GCC is more prone to re-ordering than 
> other compilers I've used.  Several things to note on the above sequence
>          - The assembly is in strict rising order  (as would be expected)
>          - The assembly maintains the proper sequence.  In particular note 

I'm afraid I don't understand the above statements. Neither the first or 
the 2nd columns are in order. That is, even if we jumped around in the C 
code (middle column with puts_r), I would have expected the 1st column 
to have rising addresses (location of actual assembler code).....but it 
doesn't; It's all over the place as well !

eg:
 >>-       0x4258  <_puts_r+60>:           add     r2, r2, r2
 >>-       0x4270  <_puts_r+84>:           str     r2, [r11, #-32]
 >>-       0x425c  <_puts_r+64>:           ldr     r0, [r4, #8]

> that the order jumps around between function calls  but the function call 
> order does not change and statements are not re-ordered from before to 
> after the function call.  I don't think the former can be done (I'm not 
> sure about the latter, if the statements don't depend on the function calls 
> or global variables)

I have seen order changes before due to compiler optimisation, but what 
I'm getting in Insight is plain bizarre. Also, most importantly, the 
.lss file created by the linker does NOT show these random jumps. The 
assembler associated with each bit of C is much more sensible. I'm sure 
this is a gdb/insight problem, not a compiler issue.

> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try to
> chew a radio signal. "
> 
>                          Kelvin Throop, III
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 


-- 
Cheers,
Bruce
-------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager.

     /\\\/\\\/\\\    /   /      Bruce Paterson
    /  \\\ \\\ \\\  /   /    Senior Design Engineer
   /   /\\\/\\\/\\\/   /   8 Anzed Court, Mulgrave, Vic, 3170
  /   /  \\\ \\\ \\\  /  PO Box 4112, Mulgrave, Vic, 3170, Australia
/   /    \\\/\\\ \\\/   Ph: +61 3 8561 4232   Fax: +61 3 9560 9055
       Tele-IP Ltd.      Email: bruce@...    Icq: #32015991
                         WWW:   http://www.tele-ip.com       VK3TJN
-------------------------------------------------------------------