Target options on Insight
2005-02-16 by Nice Guy
Could someone explain what all the target options in insight are for. Wondering what they are for. Mostly interested in the ARM Remote/Serial, and how it is used. Thanks Reggie
Thread
Target options on Insight
Re: [lpc2000] Target options on Insight
2005-02-16 by Bruce Paterson
Nice Guy wrote:
>
> Could someone explain what all the target options in insight are for.
> Wondering what they are for. Mostly interested in the ARM
> Remote/Serial, and how it is used.
I have mine currently set for GDBServerTCP/IP because I'm using
ocdremote as the gdb "server" on port 8888.
This seems to be the correct setting, but I have just started on this
today !
I'm having some odd Insight problems myself someone may be able to point
me in the right direction.
1/ I have to use dir(ectory) command to tell Insight where each bit of C
code is. Doesn't the final elf file contain the paths of the C code
already, somehow ? What have I broken ? Note using -ggdb3 with gcc for
both compile and link stages.
I could use a "source" file to put all my paths in I guess, but
wondering if there's a way around this ?
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
when simply single steping assembler instructions. Have I got an
Endian-ness problem ? If I look at the .lss file created by the link it
seems to have C code and assembler all grouped logically, so I doubt
this is a optimisation issue. (It's wildly all over the place, not just
back and forth a couple). The code sequence I run as single step looks
to be correct wrt the .lss file, it's just Insight has it all wrong.
3/ Can a gdb setup be used to load the code into flash, (assuming I
haven't written my own boot loader yet), or I will always need to use
the serial boot loader/flasher ? (Note code is too big to run from RAM).
--
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
-------------------------------------------------------------------Re: [lpc2000] Target options on Insight
2005-02-18 by Bruce Paterson
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>
- 0x427c <_puts_r+96>: cmp r0, #0 ; 0x0
- 0x4280 <_puts_r+100>: moveq r0, #10 ; 0xa
- 0x4284 <_puts_r+104>: mvnne r0, #0 ; 0x0
- 0x4288 <_puts_r+108>: sub sp, r11, #24 ; 0x18
- 0x428c <_puts_r+112>: ldmia sp, {r4, r5, r6, r11, sp, pc}
--
Cheers,
BruceRe: [lpc2000] Target options on Insight
2005-02-18 by Robert Adsett
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
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)
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, IIIRe: [lpc2000] Target options on Insight
2005-02-21 by Bruce Paterson
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
-------------------------------------------------------------------Re: [lpc2000] Target options on Insight
2005-02-21 by Robert Adsett
At 03:20 PM 2/21/05 +1100, Bruce Paterson wrote:
>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 !
You're right I missed that. I do remember when I was single stepping that
the assembly code did make sense. It also matched the assembly output from
the compiler if I remember correctly.
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