From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Gumb To: "'ecos-discuss@sourceware.cygnus.com'" Subject: RE: [ECOS] gdb 'next' problem with i386 HAL Date: Thu, 23 Aug 2001 02:54:00 -0000 Message-id: <00533D13955AD411AF3800A0C9B426391EF086@ThisAddressDoesNotExist> X-SW-Source: 2001-08/msg00756.html 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...