gdbserver调试遇到的问题

hitgyh

前段时间感谢峰峰版主和macarthor等大虾的指点,交叉调试环境终于眼看成功了,可是却碰到一个小问题:
通过minicom我在开发板端输入:gdbserver 192.168.0.11:5050 foo,出现下面信息:
Process foo created; pid=31
code at 0c39c040-0c39d160, data at 0c39d164
然后我在宿主机输入:gdb -q
                                      (gdb) target remote 192.168.0.100:5050
过一会儿后宿主机出现如下信息:
                                     Remote debugging using 192.168.0.100:5050
                                     Couldn't establish connection to remote target
                                     Reply contains invalid hex digit 59
在minicom(开发板端)出现如下信息:
                        Remote debugging using 192.168.0.11:5050
                         Readchar : Got EOF
                        Remote side has terminated connection. GDBserver will reopen the connection
(注:192.168.0.11是PC的IP,192.168.0.100是开发板的IP,
       foo是我要调试的程序,我已经将它编译到内核,开发板上电运行操作系统后,从   minicom里能够看见它位于文件甲bin下,我启动gdbserver前已经进入bin的目录下了)

hitgyh

刚才查了资料,好像要用交叉调试工具,我用的是:arm-elf-tools-20030314.sh,可是我起动不了arm-elf-gdb,但是arm-elf-gcc能用.当我输入arm-elf-gdb时出现以下信息:
arm-elf-gdb:error while loading shared libraries:libncurses.so.4:cannot open shared object file : No such file or diectory
怎么回事情呢?我的arm-elf-gdb不能用?

macarthor

见清华上的回复

hitgyh

郁闷,重装了,系统的arm-elf-gdb能运行了,按照上面的步骤还是有问题,宿主机信息:
(gdb)target remote 192.168.0.100:5050
Remote debugging using 192.168.0.100:5050
Couldn't establish connection to remote target
Reply contains invalid hex digit 59
\开发板信息:
Remote debugging using 192.168.0.100:5050
readchar:Got EOF
Remote side has terminated connection. GDBserver will reopen the connection

hitgyh

PC端:
[root@gyh foo]# arm-elf-gdb foo.gdb
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-linux-gnu --target=arm-elf"...
(gdb) target remote 192.168.0.100:2352
Remote debugging using 192.168.0.100:2352
Couldn't establish connection to remote target
Reply contains invalid hex digit 59
(gdb)
开发板端:
# gdbserver 192.168.0.100:2352 foo
Process foo created; pid = 32
code at 0c3a4040 - 0c3a5160, data at 0c3a5164
Remote debugging using 192.168.0.100:2352
readchar: Got EOF
RemotRxLength more long than 5ea
e side has terminated connection.  GDBserver will reopen the connection.

xiazhi_hit

我还是详细讲一下我的情况比较好。
我的应用程序：foo.c的内容：
#include <stdlib.h>
#include <stdio.h>
main ()
{
  printf("Hello world! This is my first app. From WangZF,2002/11/04\n");
}
Makefile的内容：
EXEC=foo
OBJS=foo.o
all(EXEC)
$(EXEC)(OBJS)
        $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)
romfs:
        $(ROMFSINST) /bin/$(EXEC)
clean:
        rm -f $(EXEC) *.elf *.gdb *.o
由于我装的是:arm-elf-tools-20030314.sh
装的时候我直接运行的：./arm-elf-tools-20030314.sh
我想它默认的就该是arm-elf-gcc和arm-elf-gdb吧
所以我的Makefile中的CC我想就默认为arm-elf-gcc吧
然后：
[root@gyh foo]# make
cc    -c -o foo.o foo.c
cc  -o foo foo.o
[root@gyh foo]# ./foo
Hello world! This is my first app. From WangZF,2002/11/04
我把foo编译到uclinux内核，运行uclinux后执行：
ls bin
arp        date       foo        init       mv         sh         umount
basename   dd         ftp        kill       ping       telnet     uptime
boa        df         ftpd       lash       portmap    telnetd    version
busybox    dmesg      gdbserver  ln         ps         tftp
cat        du         getty      ls         pwd        tftpd
chmod      echo       hostname   mkdir      rm         tinylogin
clear      env        ifconfig   mknod      rmdir      tip
cp         expand     inetd      mount      route      touch
cd /bin
/bin> ./foo
Hello world! This is my first app. From WangZF,2002/11/04
由上可见我的程序在uclinux下是可以执行的，
但是用gdbserver的时候出现我楼顶的问题。

然而，我又做了个工作却使我迷茫了，我直接将我的程序mount到uclinux,如下：
/> portmap &
[27]
/> cd var
/var> ls
config  lock    log     run     tmp
/var> ls tmp
/var> mount -t nfs 192.168.0.11:/root/gyh/uClinux-dist/user/foo tmp
/var> cd tmp
/var/tmp> ls
Makefile  foo       foo.c     foo.gdb   foo.o
于是看见了我宿主机上的foo程序文件夹里的东西
此时执行：
/var/tmp> ./foo
./foo: Unknown error 13
从这个角度来讲好像是我程序有问题，居然不能在uclinux下运行，但能在宿主机上运行
但为什么按照上面的方法编译到内核能够运行呢？
于是我又做了个工作，使我觉得好像真的是arm-elf-gcc的问题，工作如下：
先删除foo，foo.gdb,foo.o，只留下foo.c和Makefile
不用Makefile,直接执行：
[root@gyh foo]# arm-elf-gcc  -o foo foo.c
/usr/local/lib/gcc-lib/arm-elf/2.95.3/libgcc.a(__main.o): In function `__do_global_ctors':
__main.o(.text+0xc4): undefined reference to `__CTOR_LIST__'
/usr/local/lib/gcc-lib/arm-elf/2.95.3/libgcc.a(__main.o)(.data+0x0): undefined reference to `__DTOR_LIST__'
collect2: ld returned 1 exit status
根本就不行，但我用make却可以，难道make里的CC不是arm-elf-gcc

希望有经验的热心的大虾能够帮忙分析分析，并提出解决的办法，
谢谢先！

renbagshoes

为什么不在Makefile文件里面加上一句：
CC=arm-elf-gcc

编译问题可以读下这里的文章
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=106835

有一个小技巧就是用file命令查看你的二进制文件是什么格式的，如：
file filename

hitgyh

renbagshoes 给我推荐的文章看了，按照上面的做了，回报如下：
[root@gyh foo]# arm-elf-gcc -w1 -elf2flt -o foo foo.c
arm-elf-gcc: unrecognized option `-w1'
[root@gyh foo]# arm-elf-gcc -W1 -elf2flt -o foo foo.c
cc1: Invalid option `-W1'
[root@gyh foo]# arm-elf-gcc -W1,-elf2flt -o foo foo.c
cc1: Invalid option `-W1,-elf2flt'
不知道-W1起什么作用，在这里不能用，不要-W1的话：
[root@gyh foo]# arm-elf-gcc -elf2flt -o foo foo.c
[root@gyh foo]# ls
foo  foo.c  foo.gdb
察看foo的格式：
[root@gyh foo]# file foo
foo: data
并没有出现希望的信息
想运行：
[root@gyh foo]# ./foo
bash: ./foo: cannot execute binary file
可能只能在开发板上运行这种格式的吧，把foo文件夹mount到板子上后执行：
/var/tmp> ls
Makefile  foo       foo.c     foo.gdb
/var/tmp> ./foo
./foo: Unknown error 13
可见也不行，是不是应为最开始编译的时候没有要-W1的缘故呢？可是不能用
呀。怎么回事？

hitgyh

刚才编译成功了，但是mount到板子上运行不了：

[root@gyh foo]# arm-elf-gcc  -Wall  -O2  -Wl, -elf2flt -o  armfoo  foo.c
[root@gyh foo]# ls
armfoo  armfoo.gdb  foo.c
[root@gyh foo]# ./armfoo
bash: ./armfoo: cannot execute binary file

nfs mount到板子上的/var/tmp：
/var> portmap &
[29]
/var> mount -t nfs 192.168.0.11:/root/gyh/uClinux-dist/user/foo /var/tmp
/var> ls
/var> cd tmp
/var/tmp> ls
Makefile    armfoo      armfoo.gdb  foo.c

运行：
/var/tmp> ./armfoo
./armfoo: Unknown error 13

应该没有问题的，怎么回事呢？

是不是运行不了，就gdbserver不了，反正我是没有搞通交叉调试环境。