RE: [ECOS] gdb 'next' problem with i386 HAL

[John Gumb <JGumb at Ridgeway-Sys dot com>]

Folks,

>For what it's worth I get proper 'gdb next' behavior with the same
>gcc/gdb/binutil tool chain with an ancient, pre-redboot, 1.3.1 version of
>eCos.
many thanks - this is useful.

I originally saw this under RedHat 7.1 and a recent (around 10 Aug) cvs
tree.

To rule out Linux (and get a feel for how well the tools run under
NT/cygwin), 
I've managed to build the example images under NT using this morning's
ecos-latest.tar.gz snapshot from ftp://ftp.skynet.ie/cvs/ and I see exactly 
the same behaviour.

I built the i386-elf-xxx tools from source under NT successfully
(gcc-2.95.2, insight-5.0, binutils-2.10.1).

To see if I stuffed up building redboot, I've just downloaded the pre-built
redboot binary and I see exactly the same behaviour using that.

> Perhaps it might behave better if the debugged app was built with no
> optimization. Other than that, you'll need to investigate further
> (e.g. by using "set debug remote 1" and seeing where GDB sets its 
> "next" breakpoint and see if that's valid).

I tried 'set debug remote 1' but not being intimately familiar with the
innards of 
remote gdb the output didn't mean a lot. Here's a log of what I see when
'nexting'
at the initial printf in 'twothreads'. You can see I get bored and hit
CTRL-C and
we drop nicely back into gdb.

bash-2.05$ i386-elf-gdb -nw --command=~/.gdbinit
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=i386-elf".
0x97ac in ?? ()
(gdb) load twothreads.exe
Loading section .text, size 0xc1df lma 0x108000
Loading section .rodata, size 0x2ed lma 0x1141e0
Loading section .data, size 0x230 lma 0x1144d0
Start address 0x108000 , load size 50940
Transfer rate: 67920 bits/sec, 74 bytes/write.
(gdb) symbol twothreads.exe
Reading symbols from twothreads.exe...done.
(gdb) b cyg_user_start
Breakpoint 1 at 0x10860a: file twothreads.c, line 25.
(gdb) cont
Continuing.
[New thread 1]
[Switching to thread 1]

Breakpoint 1, cyg_user_start () at twothreads.c:25
25        printf("Entering twothreads' cyg_user_start() function\n");
Current language:  auto; currently c
(gdb) info registers
eax            0x118320 1147680
ecx            0x4      4
edx            0x1182e0 1147616
ebx            0x4      4
esp            0x115770 0x115770
ebp            0x115788 0x115788
esi            0x17f20  98080
edi            0x11aa6c 1157740
eip            0x10860a 0x10860a
eflags         0x2      2
cs             0x8      8
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) set debug remote 1
(gdb) next
Sending packet: $s#73...Ack
Packet received: T05thread:00000001;08:0d861000;04:64571100;
Sending packet: $m10860a,1#2a...Ack
Packet received: 83
Sending packet: $X10860a,1:Ì#1b...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T05thread:00000001;08:12861000;04:60571100;
Sending packet: $s#73...Ack
Packet received: T05thread:00000001;08:a4dd1000;04:5c571100;
Sending packet: $m11575c,4#33...Ack
Packet received: 01000000
Sending packet: $g#67...Ack
Packet received:
2083110004000000e0821100040000005c57110088571100207f01006caa110
0a4dd100007000000080000000000000000000000
Sending packet: $m1,1#fb...Ack
Packet received: e7
Sending packet: $X1,1:Ì#ec...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received:
O456E746572696E672074776F7468726561647327206379675F757365725F73
7461727428292066756E6374696F6E0A
Entering twothreads' cyg_user_start() function
Packet received:
O426567696E6E696E6720657865637574696F6E3B2074687265616420646174
6120697320300A
Beginning execution; thread data is 0
Packet received:
O426567696E6E696E6720657865637574696F6E3B2074687265616420646174
6120697320310A
Beginning execution; thread data is 1
Packet received:
O54687265616420303A20616E64206E6F7720612064656C6179206F66203233
3920636C6F636B207469636B730A
Thread 0: and now a delay of 239 clock ticks
Packet received:
O54687265616420313A20616E64206E6F7720612064656C6179206F66203233
3020636C6F636B207469636B730A
Thread 1: and now a delay of 230 clock ticks
remote_interrupt called
remote_stop called
Packet received: T02thread:00000001;08:15821000;04:d05e1100;

Program received signal SIGINT, Interrupt.
Sending packet: $X1,1:ç#07...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received:
96010000000000006058110014b91000d05e1100fc5e1100000011110000111
11582100007020000080000000000000000000000
Sending packet: $X10860a,1:\203#d2...Ack
Packet received: OK
0x108215 in hal_idle_thread_action ()
    at
/d/home/jag/ecos/packages/language/c/libc/startup/current/src/atexit.cxx:
123
123     } // atexit()
Current language:  auto; currently c++
(gdb)

-----Original Message-----
From: Allan Young [mailto:AYoung@YottaYotta.com]
Sent: 22 August 2001 20:20
To: ecos-discuss@sourceware.cygnus.com
Subject: RE: [ECOS] gdb 'next' problem with i386 HAL


I've been playing around with a recent (via anonymous cvs, grabbed around
August 10th) version of eCos and I've also observed the i386 gdb "next that
continues" problem too.  This is repeatable with the redboot floppy I've
built from sources as well as one created with the pre-built redboot binary
available at the redhat/ecos site.

Like Boris I'm also using gdb version 5.0 but I'm running on RedHat 7.1.
Also, the problem is repeatable when gdb is connected by serial port or
ethernet.

For what it's worth I get proper 'gdb next' behavior with the same
gcc/gdb/binutil tool chain with an ancient, pre-redboot, 1.3.1 version of
eCos.

> Perhaps it might behave better if the debugged app was built with no
> optimization. Other than that, you'll need to investigate further
> (e.g. by using "set debug remote 1" and seeing where GDB sets its 
> "next" breakpoint and see if that's valid).

It will take me a while to decode the gdb packet information from my 'gdb
next' test with debug remote set to 1.  Unfortunately, I won't have time to
look at this for at least a few days...