Yes, I think, I have found a problem in my linker script. The problem might be: (in application's linker script) we should not put rom_vectors in the real vector address. Upon the execution of the application, the application's vector will be moved to the real vector space. The handler address of pre-fetch abort, data abort, IRQ and FIQ will be updated. Because the undefined_instruction handler is not updated, if we have previously loaded the redboot, we can enter gdb stub when the exception occurs. Is this correct? :)
BR, On Wed, Oct 29, 2008 at 2:06 PM, Andrew Lunn <[EMAIL PROTECTED]> wrote: > On Wed, Oct 29, 2008 at 09:36:11AM +0800, Fu-Yuan Lee wrote: >> Thanks a lot. >> >> Can you please kindly hints us a little more on this part? >> >> The vector part (from address 0x20 to 0x3C) are always changed when we load >> a new application (ELF file) using the "load" gdb command. And after that we >> failed to enter gdb-stub. So is the solution to keep some redboot's >> vector pointers >> (e.g. undefined_instruction, software_interrupt, abort_data...) ? > > It sounds like you have somehthing wrong with the configuration of > your application. It should not be modifying these vectors. Take a > look at > > packages/hal/arm/arch/current/src/vectors.S > > Depending on the values of CYG_HAL_STARTUP_RAM and > CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS it will or will not change the > vectors. > > Andrew > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > > -- Lee, Fu-Yuan Distributed System and Network Security Lab. Dept. of Comp. Sci. & Info. Eng Nat'l Chiao Tung Univ. Hsinchu, Taiwan 30050, ROC E-Mail: [EMAIL PROTECTED] -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
