Problem about install gdb5.0 configured with WDB support under cygwin.

shanyecunfu888@sohu.com shanyecunfu888@sohu.com
Sat Jun 5 03:24:00 GMT 2004


-----  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( &registers[REGISTER_BYTE(PC_REGNUM)],
		&buf.pc,
		sizeof(buf.pc) );
	memcpy( &registers[REGISTER_BYTE(FP_REGNUM)],
		&buf.ebp,
		sizeof(buf.ebp) );
	memcpy( &registers[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.







More information about the Gdb mailing list