This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re:Re: Problem about install gdb5.0 configured with WDB support under cygwin.
- From: <shanyecunfu888 at sohu dot com>
- To: <gdb at sources dot redhat dot com>
- Date: Sat, 5 Jun 2004 11:24:18 +0800 (CST)
- Subject: Re:Re: Problem about install gdb5.0 configured with WDB support under cygwin.
----- Original Message -----
From: Brian Ford
To: shanyecunfu888@sohu.com
Cc: gdb@sources.redhat.com ;binutils@sources.redhat.com
Subject: Re: Problem about install gdb5.0 configured with WDB support under
cygwin.
Sent: Wed May 19 04:16:08 CST 2004
> I think you would have much better luck on the gdb mailing list. As such,
> I have redirected this discussion there (gdb at sources dot redhat dot
> com)...
>
> On Tue, 18 May 2004, shanyecunfu888 wrote:
>
> > Hi there,
> >
> > I am running a Win2000 host system and installed Cygwin successfully.
> > The building of a GCC cross compiler was also successfully for a
> > powerpc-vxworks based target system.
> > Now I want to install GDB on my host(on Cygwin) and build it with wdb
> > support for my target. By using GDB5.0 ,patched by Mr.till's file named
> > "gdb-5.0-wdbpatch-1.1",the configure script " <dirPath>/configure
> > --prefix=/gdb5.0 --target=powerpc-vxworks --enable-vxwdb" works fine.
>
> explaining who Mr. Till is and where this patch came from would probably
> help.
The URL for gdb-5.0-wdbpatch-1.1: http://www.slac.stanford.edu/~strauman/gdb/index.html.
You can see the detail specifiy.I think that may be meaningful for me to add gdb x86 cpu with WDB support.
>
> > But when I want to build it, I get the following error message:
> >
> > gcc -g -O2 -o gdb.exe main.o libgdb.a vx-wdb/libwdb.a ../bfd/libbfd.a .
> > ./readline/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libibert
> > y/libiberty.a `if test -r ../libtermcap/libtermcap.a; then echo ../libtermcap/li
> > btermcap.a; else echo -ltermcap; fi` -lm ../libiberty/libiberty.a -luser32
> >
> > libgdb.a(remote-vx.o)(.text+0x9c): In function `net_load':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:242: undefined reference to `_xdr_wrap
> > string'
>
> xdr functions are related to the Sun RPC library. Check to see if you
> have the sunrpc package installed and read:
>
> /usr/share/doc/Cygwin/sunrpc-4.0-2.README
>
> to see if that helps. Try linking with -lrpclib.
Thanks for your advice.I solved the problem by adding rpc library search path -I/cygdrive/d/cygwin/usr/include/rpc -lrpclib in gcc's switch in gdb5.0/gdb/Makefile when
compileing gdb.exe.Being newer in this field, so I am really sorry I cannot explain the reason how the native gcc can find librpc.lib and compile modules in libwdb.a while not when compiling gdb.exe :).
>
> > libgdb.a(remote-vx.o)(.text+0x25d): In function `wdb_breakpoint_del':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:382: undefined reference to `_xdr_void
> > '
> > libgdb.a(remote-vx.o)(.text+0x966): In function `wdb_wait':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:732: undefined reference to `_xdr_void
> > '
> > libgdb.a(remote-vx.o)(.text+0xa54): In function `wdb_quit_step_resume':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:793: undefined reference to `_xdr_void
> > '
> > libgdb.a(remote-vx.o)(.text+0xada):/gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:804
> > : undefined reference to `_xdr_void'
> > libgdb.a(remote-vx.o)(.text+0xb95): In function `vx_xfer_memory':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:969: undefined reference to `_xdr_void
> > '
> > libgdb.a(remote-vx.o)(.text+0x1184):/gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:13
> > 39: more undefined references to `_xdr_void' follow
> > libgdb.a(remote-vx.o)(.text+0x1194): In function `net_get_boot_file':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:1339: undefined reference to `_xdr_wra
> > pstring'
> > libgdb.a(remote-vx.o)(.text+0x11d1): In function `net_get_symbols':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:1357: undefined reference to `_xdr_voi
> > d'
> > libgdb.a(remote-vx.o)(.text+0x1265): In function `vx_lookup_symbol':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:1380: undefined reference to `_xdr_wra
> > pstring'
> > libgdb.a(remote-vx.o)(.text+0x12fe): In function `net_check_for_fp':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:1407: undefined reference to `_xdr_voi
> > d'
> > libgdb.a(remote-vx.o)(.text+0x130e):/gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:14
> > 07: undefined reference to `_xdr_bool'
> > libgdb.a(remote-vx.o)(.text+0x14b3): In function `net_connect':
> > /gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:1455: undefined reference to `_get_mya
> > ddress'
> > libgdb.a(remote-vx.o)(.text+0x14f9):/gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:14
> > 63: undefined reference to `_clnttcp_create'
> > libgdb.a(remote-vx.o)(.text+0x1541):/gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:14
> > 66: undefined reference to `_clntudp_create'
> > libgdb.a(remote-vx.o)(.text+0x1559):/gnutooli3860/src/gdb-5.0/gdb/remote-vx.c:14
> > 85: undefined reference to `_xdr_void'
> >
> >
> > ...
> >
> > /gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c:31: undefined reference to `_xd
> > r_enum'
> > libgdb.a(xdr_rdb.o)(.text+0x87): In function `xdr_arg_value':
> > /gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c:47: undefined reference to `_xd
> > r_char'
> > libgdb.a(xdr_rdb.o)(.text+0xad):/gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c
> > :52: undefined reference to `_xdr_short'
> > libgdb.a(xdr_rdb.o)(.text+0xbe):/gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c
> > :57: undefined reference to `_xdr_int'
> > libgdb.a(xdr_rdb.o)(.text+0xcf):/gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c
> > :62: undefined reference to `_xdr_float'
> > libgdb.a(xdr_rdb.o)(.text+0xe0):/gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c
> > :67: undefined reference to `_xdr_double'
> > libgdb.a(xdr_rdb.o)(.text+0x10a): In function `xdr_func_call':
> > /gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.c:82: undefined reference to `_xd
> > r_int'
> > libgdb.a(xdr_rdb.o)(.text+0x14a):/gnutooli3860/src/gdb-5.0/gdb/vx-share/xdr_rdb.
> > c:85: undefined reference to `_xdr_array'
> > libgdb.a(xdr_rdb.o)(.text+0x17c): In function `xdr_arg_one':
> >
> > ...
> >
......
Now I meet a new problem,that is how to get x86 CPU's program counter register's value through vxWorks WDB agent.I want to make gdb work with x86-vxworks target's application through WDB agent.But the vx_read/write_register() function I cannot write correctly,the reading/writing of program counter register puzzles me.
vxWorks's WDB agent define's a struct REG_SET,such as
typedef struct /* REG_SET - 80x86 register set */
{
unsigned long edi; /* general register */
unsigned long esi; /* general register */
unsigned long ebp; /* frame pointer register */
unsigned long esp; /* stack pointer register */
unsigned long ebx; /* general register */
unsigned long edx; /* general register */
unsigned long ecx; /* general register */
unsigned long eax; /* general register */
unsigned long eflags; /* status register (must be second to last) */
INSTR *pc; /* program counter (must be last) */
} REG_SET;
pc is announced as INSTR(unsigned char*) type.Does that mean pc is a pointer to a target's memory region if gdb calls WDB's get/fetch register function?If gdb only get pc pointer's value, can it control target application?
In gdb's vx_read_register() function,I write such codes:
...
REG_SET buf;
...
memcpy( ®isters[REGISTER_BYTE(PC_REGNUM)],
&buf.pc,
sizeof(buf.pc) );
memcpy( ®isters[REGISTER_BYTE(FP_REGNUM)],
&buf.ebp,
sizeof(buf.ebp) );
memcpy( ®isters[REGISTER_BYTE(SP_REGNUM)],
&buf.esp,
sizeof(buf.esp) );
Is it right? When I use native gdb debug my cross-gdb,I got a WDB unknown exception,though I donnot know how to map a vector number on the target to a target signal number,I am sure the problem comes from vx_read_register function.Could you explain something to me?
Cheers,Lize,Wang.