[ECOS] Question eCOS debugging. Thanks a lot.

[QiangHuang]

Thank you very much Jonathan.

Can I make the calling graphic as following (Please correct me if anything
wrong here) Thanks a lot.

(For ARM)
Step 1: undefined intruction exception --> Step 2:
call_exception_handler() --> Step 3: exception_handler()--> Step 4: save ARM
registers and "_hal_registers" --> Step 5: __handle_exception()--> Step 6:
__cleanup_vec () (handle_exception_cleanup)--> Step 7: Update
"GDB_Registers" --> Step 8: hal_syscall_handler() --> Step 9:  get the saved
GDB_Register (from Step 7)

    func = get_register(R0);
    arg1 = get_register(R1);
    arg2 = get_register(R2);
    arg3 = get_register(R3);
    arg4 = *(unsigned int *)(get_register(SP) + 4);

--> Step 10: __do_syscall(func, arg1, arg2, arg3, arg4, &err, &sig), call
into RedBoot
--> Step 11:  In RedBoot __do_syscall()
    switch (func)
{
....
case SYS_write:  cyg_hal_gdbfileio_write/read((int)arg1, (const void *)arg2,
(size_t)arg3, (int *)sig);
}

--> Step 12: cyg_hal_gdbfileio_write/read() called
--> Step 13: gdbfileio_common_sendpkt( __remcomOutBuffer, sig ) called to
send out the packet

Question 1.
I can't understand in Step 11 that why the parameter (func=="R0"?) passed
from Step 10 will be a flag rather than ARM register R0 or where is R0 in
GDB_Register set to flag, while it is R0 of the ARM register? (Am I wrong
for this?)

Question 2.
In step 11, arg1=R1 (ARM register), arg2=R2 (ARM register), arg3=R3 (ARM
register), which will be served as file descriptor, buffer and count in Step
12 expected by cyg_hal_gdbfileio_write/read( ) function. How/Where are those
register set to those (file descriptor, buffer and count? Isn't arg0=R0,
arg1=R1, arg2=R2, arg3=R3 are the saved ARM registers just before
exception?)

Thank you very much indeed.

Qiang


-----Original Message-----
From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
Sent: 01 August 2003 01:21
To: QiangHuang
Cc: 'Ecos-Discuss'
Subject: Re: [ECOS] Question eCOS debugging. Thanks a lot.


QiangHuang wrote:
> Hi all:
>      I am trying to get a clear calling path of RedBoot with the hal stub
> and GDB debugger. I can't understand the following, could anybody please
> give me some idea? Thanks a lot.
>
> In HAL/ARM function "hal_syscall_handler()" getting the saved ARM register
> by calling:

hal_syscall_handler is called when a trap is made. This is intended to be
used by newlib based apps.

> Step 1. func = get_register(R0);   arg1 = get_register(R1);    arg2 =
> get_register(R2);    arg3 = get_register(R3);
> Step 2. and later call into RedBoot by function "__do_syscall(func, arg1,
> arg2, arg3, arg4, &err, &sig)",
> Step 3. in turns call into gdb_fileio function: "cyg_hal_gdbfileio_xxx()",
> take write for example: cyg_hal_gdbfileio_write((int)arg1, (const void
> *)arg2, (size_t)arg3, (int *)sig);
> Here arg2 will be treated as a buffer pointer, but Isn't "arg2" = "saved
ARM
> register R2"? so where is this pointer pointing to?

Yes, R2 when the syscall was invoked. See newlib's
libgloss/arm/redboot-syscalls.c, e.g.
int
_write(int fd, const char *buf, int nbytes)
{
     int err;

     err = __syscall(SYS_write, fd, buf, nbytes);
     if (err<0)
       {
         errno = -err;
         return -1;
       }
     return err;
}


> I would like to know how the processor registers are retrieved (by the HAL
> Stub and RedBoot) and display on the GDB debugger(Insight)? Thanks a lot.

Loosely, processor context is saved in vectors.S. Exception handler VSR
chains to hal_misc.c's "exception_handler()" which calls into the GDB stub
with _handle_exception after setting the global _hal_registers to the
saved state. Later on the GDB stub then uses HAL_GET_GDB_REGISTERS from
the arch HAL's include/hal_arch.h to convert the saved register state into
the state GDB needs.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss