This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos 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: 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


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