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]

Re: Difference between CTRLC & BREAK support on GDB stubs


>From: Jesper Skov <jskov@redhat.com>
>To: "Rosimildo daSilva" <rosimildo@hotmail.com>
>CC: jskov@redhat.com, ecos-discuss@sourceware.cygnus.com
>Subject: Re: [ECOS] Difference between CTRLC & BREAK support on GDB stubs
>Date: Tue, 17 Oct 2000 09:31:01 +0200 (CEST)
>
> >>>>> "Rosimildo" == Rosimildo daSilva <rosimildo@hotmail.com> writes:
>Rosimildo> You are absolutely right. This is the behavior that I am
>Rosimildo> seeing.  But, the "breakpoint" reached is inside of the
>Rosimildo> "ctrlc_isr", so the same "line number, file name" is
>Rosimildo> reported. I'd like to change that behavior and add the
>Rosimildo> breakpoint to the address of the interrupted routine.
>
>When I look at the vrc4373 platform HAL in the 1.3.1 release code, I
>see that it relies on stubs (in cyg_hal_user_break) to do the
>magic. Is that your problem? Have you enabled
>CYGSEM_HAL_USE_ROM_MONITOR_GDB_stubs and do you actually have a stub
>in place which does the right thing?


Jesper or anyone else:

The macro is not defined CYGSEM_HAL_USE_ROM_MONITOR_GDB_stubs.

I have not made myself clear before, so let me try
again:

  + I have a "GDB stub" that works, except the "Ctrl-c"
    feature. A can set breakpoints, step, etc. Whenever
    a hit "Ctrl-C", the stub stops as expected( see below ).
    The problem is that from then on, every step hits
    a "break" instruction. In another works, I cannot
    "cont" the executation of the application.

Below is a GDB session of what is happening:

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin 
--target=mipsel-r3041-elf"...
(gdb) target remote com2
Remote debugging using com2
0xbfc0515c in ?? ()
(gdb) load
Loading section .rom_vectors, size 0xd4 lma 0x80008000
Loading section .text, size 0x29d8c lma 0x800080d4
Loading section .ctors, size 0x34 lma 0x80031e60
Loading section .dtors, size 0x20 lma 0x80031e94
Loading section .rodata, size 0x1638 lma 0x80031eb4
Loading section .data, size 0xfcc lma 0x800334f0
Start address 0x800080c4 , load size 181432
Transfer rate: 65975 bits/sec, 506 bytes/write.


Rosimildo: "hello.exe" loaded properly.


(gdb) list cyg_user_start
24      /* and now a mutex to protect calls to the C library */
25      cyg_mutex_t cliblock;
26
27      /* we install our own startup routine which sets up threads */
28      void cyg_user_start(void)
29      {
30        printf("Entering twothreads' cyg_user_start() function\n");
31
32        cyg_mutex_init(&cliblock);
33
(gdb) b 30
Breakpoint 1 at 0x800086dc: file hello.c, line 30.


Rosimildo: breakpoint set ok.


(gdb) cont
Continuing.
Breakpoint 1, cyg_user_start () at hello.c:30
30        printf("Entering twothreads' cyg_user_start() function\n");
Current language:  auto; currently c
(gdb) display/i $pc
1: x/i $pc  0x800086dc <cyg_user_start+16>:     lui     $a0,0x8003


Rosimildo: GDB stub reached breakpoint fine.


(gdb) continue
Continuing.
Entering twothreads' cyg_user_start() function
Beginning execution; thread data is 0
Beginning execution; thread data is 1
Thread 0: and now a delay of 239 clock ticks
Thread 1: and now a delay of 230 clock ticks
Thread 1: and now a delay of 221 clock ticks
Thread 0: and now a delay of 214 clock ticks
Thread 1: and now a delay of 224 clock ticks
Thread 0: and now a delay of 243 clock ticks

Rosimildo: "Ctrl-C" on the host side.


user_isr: data=0, pc=80035D30
Program received signal SIGTRAP, Trace/breakpoint trap.
cyg_hal_user_break (regs=0x80035d30)
    at 
/ecos/sos/scmxx/ECOS-1.3.1/packages/hal/mips/scm1x/v1_3_1/src/plf_misc.c:
190
190             HAL_BREAKPOINT(breakinst);
1: x/i $pc  0x8000aa30 <cyg_hal_user_break>:    break   0x5
Current language:  auto; currently c
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
cyg_hal_user_break (regs=0x80035d30)
    at 
/ecos/sos/scmxx/ECOS-1.3.1/packages/hal/mips/scm1x/v1_3_1/src/plf_misc.c:
190
190             HAL_BREAKPOINT(breakinst);
1: x/i $pc  0x8000aa30 <cyg_hal_user_break>:    break   0x5
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
cyg_hal_user_break (regs=0x80035d30)
    at 
/ecos/sos/scmxx/ECOS-1.3.1/packages/hal/mips/scm1x/v1_3_1/src/plf_misc.c:
190
190             HAL_BREAKPOINT(breakinst);
1: x/i $pc  0x8000aa30 <cyg_hal_user_break>:    break   0x5
(gdb)

------------------------------------------------------------------

I do not understand how the other MIPS do, because if I understand
this correctly, the "HAL_BREAKPOINT()" macro would raise a trap
exception. The problem is that the stub seems to save the current
PC ( "break instruction" ), and when I "cont" from GDB, it restore
the "break instruction", and it cannot get out of this loop.

What I am doing wrong ?


Thanks a lot for your help so far.

Rosimildo.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


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