This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: RE: ctrl-c in GDB
- From: "Vikas K. Prasad" <vikas dot prasad at ittiam dot com>
- To: "Nick Garnett" <nickg at ecoscentric dot com>,<ecos-discuss at sources dot redhat dot com>
- Cc: "Vikas K. Prasad" <vikas dot prasad at ittiam dot com>
- Date: Thu, 30 Sep 2004 12:23:49 +0530
- Subject: RE: [ECOS] RE: ctrl-c in GDB
Nick,
Thank you for giving me the direction. Here is what happens
when I try to put the break point in 'start()'.
(gdb) b *0x4100190
Breakpoint 1 at 0x4100190
(gdb) c
Continuing.
Breakpoint 1, 0x04100190 in start ()
(gdb) s
Single stepping until exit from function start,
which has no line number information.
>From this, I am doubting if the code generation is proper.
Here is a snap shot of target.ld file. There is lots of
stuff generated at 0 (where my SRAM is mapped) and the
usual stuff at 0x4100000 (SDRAM from where I am running
eCos). Please help me on this. I am not getting
sufficient info to generate proper target.ld.
NOTE:
1) My redboot is at 0x4000000
2) Is debug code generation at 0 a problem? Who to get all
related stuff other than vectors at 0x4100000?
MEMORY
{
ram2 : ORIGIN = 0x00000000, LENGTH = 0x00000020
ram : ORIGIN = 0x04100000, LENGTH = 0x00100000
}
SECTIONS
{
.debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .note.arm.ident 0 : { KEEP (*(.note.arm.ident)) }
.vector_table : { . = . ; KEEP (*(.vector_table)) } > ram2
.rom_vectors 0x04100000 : { __rom_vectors_vma = ABSOLUTE(.); . = .; KEEP (*(.vectors)) } > ram __rom_vectors_lma = LOADADDR(.rom_vectors);
.fixed_vectors ALIGN (0x1) : { . = .; KEEP (*(.fixed_vectors)) } > ram
.text ALIGN (0x4) : { _stext = ABSOLUTE(.); PROVIDE (__stext = ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) *(.glue_7) *(.glue_7t) } > ram _etext = .; PROVIDE (__etext = .);
.fini ALIGN (0x4) : { . = .; *(.fini) } > ram
... rest of the stuff in ram region.
Regards,
Vikas
-----Original Message-----
From: Nick Garnett [mailto:nickg@ecoscentric.com]
Sent: Wednesday, September 29, 2004 3:04 PM
To: Vikas K. Prasad
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] RE: ctrl-c in GDB
"Vikas K. Prasad" <vikas.prasad@ittiam.com> writes:
> Nick,
>
> My program has a main, which turns on an LED on the board.
> After that there is a while(1) loop. Could this be the
> problem that somehow GDB is not getting the control back?
>
> NOTE: Putting a breakpoint at main() or cyg_user_start()
> did not help.
You may have to put the breakpoint earlier in the startup code, in
some of the HAL initialization routines. Ultimately, you may have to
plant a breakpoint at the start address and single step from there
until you find out where it goes wrong.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss