some newbie questions
sebastian ssmoller
sebastian.ssmoller at gmx.net
Wed Feb 18 18:47:56 UTC 2004
i started debugging the start sequence (the monitor supports setting
breakpoints) ...
from objdump i get
0001041c <start>:
1041c: 007c 3000 oriw #12288,%sr
10420: 4ff9 ffc0 03c0 lea ffc003c0 <m360+0x3c0>,%sp
10426: 41fa fbd8 lea %pc@(10000 <_RamBase>),%a0
1042a: 4e7b 8801 movec %a0,%vbr
1042e: 4e7a 1001 movec %dfc,%d1
10432: 7007 moveq #7,%d0
10434: 4e7b 0001 movec %d0,%dfc
....
so i set a breakpoint to 1041c and go on step by step. i get:
BREAK AT 0001041C
*ST
0001041C OR.W #$3000,SR
D0 = 00000000 D1 = 00000000 D2 = 00000000 D3 = 00000000
D4 = 00000000 D5 = 00000000 D6 = 00000000 D7 = 00000000
A0 = 00000000 A1 = 00000000 A2 = 00000000 A3 = 00000000
A4 = 00000000 A5 = 00000000 A6 = 00000000 MS = 000004A0
IS = 000004A0 US = 000004A0 SR = 0000B000 PC = 00010420
VB = 00000000 SF = 00000000 DF = 00000000 CC = 00000000
*ST
00010420 LEA $FFC003C0.L,A7
D0 = 00000000 D1 = 00000000 D2 = 00000000 D3 = 00000000
D4 = 00000000 D5 = 00000000 D6 = 00000000 D7 = 00000000
A0 = 00000000 A1 = 00000000 A2 = 00000000 A3 = 00000000
A4 = 00000000 A5 = 00000000 A6 = 00000000 MS = FFC003C0
IS = 000004A0 US = 000004A0 SR = 0000B000 PC = 00010426
VB = 00000000 SF = 00000000 DF = 00000000 CC = 00000000
*ST
00010426 LEA $10000(PC),A0
D0 = 00000000 D1 = 00000000 D2 = 00000000 D3 = 00000000
D4 = 00000000 D5 = 00000000 D6 = 00000000 D7 = 00000000
A0 = 00010000 A1 = 00000000 A2 = 00000000 A3 = 00000000
A4 = 00000000 A5 = 00000000 A6 = 00000000 MS = FFC003C0
IS = 000004A0 US = 000004A0 SR = 0000B000 PC = 0001042A
VB = 00000000 SF = 00000000 DF = 00000000 CC = 00000000
*ST
and now the board hangs ...
i am not sure whether the "lea" command is the current command executed or
the last one executed successfully but it seems that i have some really
basic problems here :(
the next statement works with vbr which is assumed to be at 0x0. do i have
to let rtems know that ?
thank u for ur help so far and for all ur hints. i will have to check all
the addresses and the linkcmds script again. it seems to be still a problem
with memory mapping, i guess.
the monitor support bdm i guess. unfortunately my system (freebsd) doesnt
support it (no driver). i will setup a linux box these days and i'll try to
run bdm+gdb on it ...
thx
regards,
seb
On Wed, 18 Feb 2004 13:31:42 -0500
Ed Sutter <els at emailbox.hdtv.lucent.com> wrote:
> Seb,
> Does your monitor allow you to hook to any of its resident
> facilities? If it does, then you should be able to hook
> to its printf() functionality to give you a peek into the
> startup of the operating system. ALternatively, you can
> add a global variable to the startup code that is used to
> trace the startup. After the call to start() hangs, you
> can observe the value of the variable to determine how far
> your startup got.
> For example...
>
> int sebs_trace_variable;
>
> start()
> {
> ...
> seb_trace_variable = 1;
> ...
> seb_trace_variable = 2;
> ...
> seb_trace_variable = 3;
> ...
> seb_trace_variable = 4;
> ...
> ect...
> }
>
> Then, after you call start() and it hangs, see what the
> content of that variable is. That will give you an idea
> of where you start() hung.
>
> I may as well mention that MicroMonitor has facilities in it
> to make this process pretty easy to debug. If transitioning
> over to that is a possibility, let me know.
> Ed
>
> Ed Sutter wrote:
> >
> > Seb,
> > You can't call something with printf() in it at this level.
> > Think about it...
> > The guts of printf() requires console IO to be working.
> > Console IO is likely handled by the serial port device
> > driver in RTEMS. Since we're side-stepping the whole
> > RTOS startup here, printf() will certainly not work.
> >
> > Ed
> >
> > sebastian ssmoller wrote:
> > >
> > > hi,
> > > using an "independent" function is of cause a good idea :)
> > > calling this funct does NOT cause the board to hang - so this is one
> > > step into the right direction :)
> > >
> > > i wasnt able yet to get the value of the variable - i have to read
> > > some docs about the monitor first.
> > >
> > > but what i did is, i only include a printf (which causes to inlcude
> > > and use lots of other stuff of course). calling the funct again
> > > caused a bus error. next pc points into the fstat function ...
> > >
> > > this let me believe that my linkcmds file is not correct. so possibly
> > > u could have a look at it ?
> > >
> > > ====== linkcmds from intro (which works) =========
> > > //
> > > // This linker command file was created by Introl-CODE.
> > > //
> > >
> > > // Library modules used by this program
> > >
> > > // Program memory groups
> > > group ROM rom itemalign 2 origin 0x0700 maxsize 0x10000-0x0700;
> > > section .vectors data;
> > >
> > > section .start0 text;
> > > section .start1 text;
> > > section .start2 text;
> > > section .start3 text;
> > > section .start4 text;
> > > section .start5 text;
> > > section .start6 text;
> > > section .start7 text;
> > > section .start8 text;
> > > section .start9 text;
> > > section .startX text;
> > > section .startZ text;
> > >
> > > section ROM.const data = .const .strings;
> > > section ROM.text text = .text;
> > >
> > > section .init;
> > > group ROM;
> > >
> > > set __ROMstart = 0x0700;
> > > set __ROMend = 0x10000;
> > > set __ROMsize = 0x10000-0x0700;
> > >
> > > group RAM ram bss itemalign 2 origin 0x10000 maxsize 0x50000-0x10000;
> > > section .bss comms;
> > > section .data data copiedfrom .init;
> > > section .retm comm;
> > > section .heap expand minsize 0;
> > > section .stack minsize 0;
> > >
> > > section RAM.ubss = .ubss;
> > > group RAM;
> > >
> > > set __RAMstart = 0x10000;
> > > set __RAMend = 0x50000;
> > > set __RAMsize = 0x50000-0x10000;
> > >
> > > group IO io bss origin 0xFFF000 maxsize 0x1000000-0xFFF000;
> > > section .chip;
> > > group IO;
> > >
> > > set __IOstart = 0xFFF000;
> > > set __IOend = 0x1000000;
> > > set __IOsize = 0x1000000-0xFFF000;
> > >
> > > // Link time variable definitions
> > > set __ramstart = startof(.bss);
> > > set __ramend = endof(.bss);
> > > set __heapstart = startof(.heap);
> > > set __heapend = endof(.heap);
> > > set __stackstart = startof(.stack);
> > > set __stackend = endof(.stack);
> > > set __initstart = startof(.init);
> > > set __initend = endof(.init);
> > > set __datastart = startof(.data);
> > > set __dataend = endof(.data);
> > > set __fastend = endof(.start1);
> > > set __chipstart = startof(.chip);
> > >
> > > readline; // Read files from the command line
> > >
> > > end;
> > >
> > > ============ linkcmds intro end ==================
> > >
> > > ============ linkcmds from rtems (with memory values changed)
> > > ========/*
> > > * This file contains GNU linker directives for a generic MC68360
> > > board.* Variations in memory size and allocation can be made by
> > > * overriding some values with linker command-line arguments.
> > > *
> > > * Saskatchewan Accelerator Laboratory
> > > * University of Saskatchewan
> > > * Saskatoon, Saskatchewan, CANADA
> > > * eric at skatter.usask.ca
> > > *
> > > * linkcmds,v 1.20 2003/01/20 20:19:44 joel Exp
> > > */
> > >
> > > /*
> > > OUTPUT_FORMAT("srec");
> > > */
> > >
> > > /*
> > > * Declare some sizes.
> > > * A heap size of 0 means `use all available memory for the heap'.
> > > */
> > > _RamBase = DEFINED(_RamBase) ? _RamBase : 0x10000;
> > > _RamSize = DEFINED(_RamSize) ? _RamSize : 0x50000-0x10000;
> > > _HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0x0;
> > > _StackSize = DEFINED(_StackSize) ? _StackSize : 0x1000;
> > >
> > > /*
> > > * Declare on-board memory.
> > > */
> > > MEMORY {
> > > rom : ORIGIN = 0x0700, LENGTH = 0x10000 - 0x0700
> > > ram : ORIGIN = 0x10000, LENGTH = 0x50000 - 0x10000
> > > dpram : ORIGIN = 0xFFC00001, LENGTH = 0xFFC02000 - 0xFFC00000
> > > }
> > >
> > > /*
> > > * Load objects
> > > */
> > > SECTIONS {
> > > /*
> > > * Boot PROM
> > > */
> > > rom : {
> > > _RomBase = .;
> > > } >rom
> > >
> > > /*
> > > * Dynamic RAM
> > > */
> > > ram : {
> > > _RamBase = .;
> > > } >ram
> > >
> > > /*
> > > * Text, data and bss segments
> > > */
> > > .text : {
> > > *(.text)
> > >
> > > /*
> > > * C++ constructors/destructors
> > > */
> > > *(.gnu.linkonce.t.*)
> > >
> > > /*
> > > * Initialization and finalization code.
> > > */
> > > PROVIDE (_init = .);
> > > *crti.o(.init)
> > > *(.init)
> > > *crtn.o(.init)
> > > PROVIDE (_fini = .);
> > > *crti.o(.fini)
> > > *(.fini)
> > > *crtn.o(.fini)
> > >
> > > /*
> > > * Special FreeBSD sysctl sections.
> > > */
> > > . = ALIGN (16);
> > > __start_set_sysctl_set = .;
> > > *(set_sysctl_*);
> > > __stop_set_sysctl_set = ABSOLUTE(.);
> > > *(set_domain_*);
> > > *(set_pseudo_*);
> > >
> > > /*
> > > * C++ constructors/destructors
> > > */
> > > . = ALIGN (16);
> > > *crtbegin.o(.ctors)
> > > *(.ctors)
> > > *crtend.o(.ctors)
> > > *crtbegin.o(.dtors)
> > > *(.dtors)
> > > *crtend.o(.dtors)
> > >
> > > /*
> > > * Exception frame info
> > > */
> > > . = ALIGN (16);
> > > *(.eh_frame)
> > >
> > > /*
> > > * Read-only data
> > > */
> > > . = ALIGN (16);
> > > _rodata_start = . ;
> > > *(.rodata*)
> > > *(.gnu.linkonce.r*)
> > >
> > > . = ALIGN (16);
> > > PROVIDE (etext = .);
> > > } >ram
> > > .data : {
> > > _copy_start = .;
> > > *(.data)
> > > *(.gnu.linkonce.d*)
> > > *(.gcc_except_table)
> > > *(.jcr)
> > > . = ALIGN (16);
> > > PROVIDE (edata = .);
> > > _copy_end = .;
> > > } >ram
> > > .bss : {
> > > M68Kvec = .;
> > > . += (256 * 4);
> > > _clear_start = .;
> > > *(.bss)
> > > *(COMMON)
> > > . = ALIGN (16);
> > > PROVIDE (end = .);
> > >
> > > . += _StackSize;
> > > . = ALIGN (16);
> > > _stack_init = .;
> > > _clear_end = .;
> > >
> > > _WorkspaceBase = .;
> > > variable = .;
> > > } >ram
> > >
> > > /*
> > > * On-chip memory/peripherals
> > > */
> > > dpram : {
> > > m360 = .;
> > > . += (8 * 1024);
> > > } >dpram
> > >
> > > /* Stabs debugging sections. */
> > > .stab 0 : { *(.stab) }
> > > .stabstr 0 : { *(.stabstr) }
> > > .stab.excl 0 : { *(.stab.excl) }
> > > .stab.exclstr 0 : { *(.stab.exclstr) }
> > > .stab.index 0 : { *(.stab.index) }
> > > .stab.indexstr 0 : { *(.stab.indexstr) }
> > > .comment 0 : { *(.comment) }
> > >
> > > /* DWARF debug sections.
> > > Symbols in the DWARF debugging sections are relative to the
> > > beginning of the section so we begin them at 0. */
> > > /* DWARF 1 */
> > > .debug 0 : { *(.debug) }
> > > .line 0 : { *(.line) }
> > >
> > > /* GNU DWARF 1 extensions */
> > > .debug_srcinfo 0 : { *(.debug_srcinfo) }
> > > .debug_sfnames 0 : { *(.debug_sfnames) }
> > >
> > > /* DWARF 1.1 and DWARF 2 */
> > > .debug_aranges 0 : { *(.debug_aranges) }
> > > .debug_pubnames 0 : { *(.debug_pubnames) }
> > >
> > > /* DWARF 2 */
> > > .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) }
> > >
> > > /* SGI/MIPS DWARF 2 extensions */
> > > .debug_weaknames 0 : { *(.debug_weaknames) }
> > > .debug_funcnames 0 : { *(.debug_funcnames) }
> > > .debug_typenames 0 : { *(.debug_typenames) }
> > > .debug_varnames 0 : { *(.debug_varnames) }
> > > /* These must appear regardless of . */
> > > }
> > > ============ linkcmds rtems end ==================
> > >
> > > i checked the "ca" (call) syntax again and i guess it is correct,
> > > cause it works with introl code and when calling the unique_function
> > >
> > > many thx again
> > > regards,
> > > seb
> > >
> > > On Wed, 18 Feb 2004 12:14:30 -0500
> > > Ed Sutter <els at emailbox.hdtv.lucent.com> wrote:
> > >
> > > > Seb,
> > > > Try starting with something simpler.
> > > > Here's a few suggestions...
> > > >
> > > > In your application add a function and a variable..
> > > >
> > > > long unique_variable;
> > > >
> > > > long
> > > > unique_function(void)
> > > > {
> > > > return(++unique_variable);
> > > > }
> > > >
> > > > Then load your application and instead of calling the entrypoint,
> > > > parse your symbol table and call this function's address. If this
> > > > hangs, you have a more fundamental problem, if it doesn't hang
> > > > the do some more investigation...
> > > > If the "call" command that you have shows the return value of the
> > > > function you called, then you should notice it incrementing.
> > > > If the "call" command doesn't support that, then call the function
> > > > and then display the variable using some other monitor command.
> > > >
> > > > Another thing to try would be to disassemble the the address of
> > > > the application entrypoint and see if it makes sense.
> > > >
> > > > The point here is to test some of the stuff outside of RTEMS.
> > > > Make sure your "call" command is working the way you think, etc...
> > > > For example, maybe "call" gets confused if your address is not
> > > > prefixed with "0x". Or, maybe it gets confused if yoru address IS
> > > > prefixed with "0x".
> > > > Get the idea? These things will just give you a confidence level
> > > > (maybe good maybe not so good) in what you're doing.
> > > >
> > > > Ed
> > > >
>
More information about the users
mailing list