usermode gdb / remote gdb

Hi,

I am trying to configure gdb to debug usermode on my mips box. i have two choices: one is to use "native"-compiled gdb, ot remote debugging on x86 box via serial or IP.

Currently I have no luck making any of the two configurations.

For "native" gdb I try to

$ CC=mips-linux-gcc ./configure mips-linux
and eventually I get
configure: error: *** Gdb does not support host mips-mips-linux-gnu

For remote debugging, I use

$ ./configure --target=mips
which succeded, and I even am able to get cross 'mips-gdb' which understands mips executables. However, when trying to configure gdbserver,

$ cd gdb/gdbserver
$ ../../configure mips-linux
*** ./configure.in has no "per-host:" line.
*** Hmm, looks like this directory has been autoconfiscated.
*** Running the local configure script.
creating cache config.cache
checking host system type... mips-mips-linux-gnu
checking target system type... mips-mips-linux-gnu
checking build system type... mips-mips-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
configure: error: *** GDB remote does not support host mips-mips-linux-gnu

Too bad, have seen it before, so I just tried to

$ ../../configure --host=mips --target=mips
*** ./configure.in has no "per-host:" line.
*** Hmm, looks like this directory has been autoconfiscated.
*** Running the local configure script.
loading cache config.cache
checking host system type... mips-mips-elf
checking target system type... mips-mips-elf
checking build system type... mips-mips-elf
checking for a BSD compatible install... /usr/bin/install -c
configure: error: *** GDB remote does not support host mips-mips-elf

And the last try (like the one that worked before):

$ ../../configure --target=mips
Configuring for a i686-pc-linux-gnu host.
*** ./configure.in has no "per-host:" line.
*** Hmm, looks like this directory has been autoconfiscated.
*** Running the local configure script.
loading cache config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... mips-mips-elf
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
updating cache config.cache
creating ./config.status
creating Makefile
linking ./../config/i386/xm-linux.h to xm.h
linking ./../config/mips/tm-embed.h to tm.h
linking ./../config/nm-empty.h to nm.h

which clearly misconfigured, because of host system type set to x86, and nm.h is pointing to nm-emty.h (?).

From what I see, I cannot use neither mips-linux nor mips-elf for host specification. On the other hand, I have seen lately a lot of discussion for gdb support for MIPS (bot kernel and usermode).

I just wonder what I am missing from all this story. Your help is greatly appreciated.

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: [email protected]
web: http://www.jungo.com
Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233
Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide)

Hi Michael,

I can't really comment on self hosted debugging with a native compiled gdb. However I have been working on host target debugging with the kernel gdbstub and gdbserver. As you're not interested in kernel debugging I won't say any more about the kernel stub.

The (host side) gdb I've been using was configured with ./configure --target=mipsel-linux-elf (my target is an IDT MIPS 79S334 evaluation board). I too am using an x86 host. I used a development version of gdb-5.0 (I found the 'official' 5.0 had problems with the add-symbol-file command that I use for kernel module debugging, and more importantly for you... breakpoints didn't work) These problems are gone in the later version.

Yesterday I got gdbserver working correctly on my target (over IP or serial). It's a combination of Martin Rivers' mips port and my 'fixes'. At this stage the build is hand cranked and neither of us have put it under the control of the gdb configuration files. However, we (lineo) will now start doing this.

I hope this helps in some way. Please let me know if there is anything I can help with. It might also be worth contacting Fabrice, as it sounds like he has a working gdb and gdbserver.

Best regards,
Ian

To start with, mips-linux-elf is not supported by gdbserver either with out-of-the-box 5.0:

$ ../../configure --target=mips-linux-elf --host=mips-linux-elf
*** ./configure.in has no "per-host:" line.
*** Hmm, looks like this directory has been autoconfiscated.
*** Running the local configure script.
loading cache config.cache
checking host system type... mips-linux-elf
checking target system type... mips-linux-elf
checking build system type... mips-linux-elf
checking for a BSD compatible install... (cached) /usr/bin/install -c
configure: error: *** GDB remote does not support host mips-linux-elf

Can you tell me which sources do you use?

Happy to hear that you got working GDB. I hope to make one too. For this I need to know where to get the MIPS port and your patches. Can you send them to me?

These are indeed good news.

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: [email protected]
web: http://www.jungo.com
Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233
Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide)

Hi Michael,

No, I meant configuring the 'cross-debugging' gdb that I use on the x86 host. I think standard 5.0 will support the mipsel-linux-elf target also (but something later is better). As for gdbserver... yes, you'll be out of luck... that's why I have to hand build (cross compile) it (pending getting the config stuff sorted out).

It's actually a tar bundle that we include on one of our CDs. I think it's a gdb snapshot dating from around August or September last year. I'll see if I can dig out some more info and let you know. Or you could try the latest snapshots, I haven't tried them, but they're probably OK.

Sure, just give me a bit of time to get something together... it's a bit rough round the edges at the moment :)

Best regards,
Ian

Hmm, I added linux-mips target for gdbserver in gdb 4.17. And I thought Ralf sent the patch back to FSF (as I had to fill out some copyright forms). Perhaps it is lost somewhere?

Anyhow, here is the patch that I submitted. Hopefully it helps.

Jun

@@ -3,6 +3,8 @@
 XM_FILE= xm-llinux.h
 NAT_FILE= nm-linux.h
 NATDEPFILES= infptrace.o inftarg.o mipslinux-nat.o corelow.o core-regset.o fork-child.o solib.o
+GDBSERVER_DEPFILES= low-linux.o
+GDBSERVER_LIBS=
 
 MMALLOC =
 MMALLOC_CFLAGS = -DNO_MMALLOC

@@ -31,3 +31,6 @@
 #define HAVE_TERMIOS
 #define HAVE_SIGSETMASK 1
 #define USG
+
+#define REGISTER_U_ADDR(addr, blockend, regno)          \
+	addr = regno

@@ -32,7 +32,7 @@
      char *string;
 {
   extern int sys_nerr;
-  extern char *sys_errlist[];
+  extern const char * const sys_errlist[];
   extern int errno;
   char *err;
   char *combined;

@@ -44,11 +44,17 @@
 char buf2[MAX_REGISTER_RAW_SIZE];
 /***************End MY defs*********************/
 
-#include <sys/ptrace.h>
+#include <asm/ptrace.h>
 #if 0
+#include <sys/ptrace.h>
 #include <machine/reg.h>
 #endif
 
+/* [jsun] if NUM_FREGS is not defined, it probably should be 0 */
+#if !defined(NUM_FREGS)
+#define		NUM_FREGS		0
+#endif
+
 extern char **environ;
 extern int errno;
 extern int inferior_pid;

@@ -72,7 +78,7 @@
 
   if (pid == 0)
     {
-      ptrace (PTRACE_TRACEME, 0, 0, 0);
+      ptrace (PTRACE_TRACEME, 0, 0, 0); 
 
       execv (program, allargs);
 

@@ -165,6 +171,7 @@
     - KERNEL_U_ADDR
 #endif
 
+#if defined(__i386)
 /* this table must line up with REGISTER_NAMES in tm-i386v.h */
 /* symbols like 'EAX' come from <sys/reg.h> */
 static int regmap[] = 

@@ -198,6 +205,8 @@
     return (blockend + 4 * regmap[regnum]);
   
 }
+#endif		/* defined(__i386) */
+
 
 CORE_ADDR
 register_addr (regno, blockend)

@@ -215,7 +224,6 @@
 }
 
 /* Fetch one register.  */
-
 static void
 fetch_register (regno)
      int regno;

@@ -257,7 +265,7 @@
 {
   if (regno == -1 || regno == 0)
     for (regno = 0; regno < NUM_REGS-NUM_FREGS; regno++)
-      fetch_register (regno);
+	  fetch_register (regno);
   else
     fetch_register (regno);
 }

@@ -41,7 +41,7 @@
      char *string;
 {
   extern int sys_nerr;
-  extern char *sys_errlist[];
+  extern const char *const sys_errlist[];
   extern int errno;
   char *err;
   char *combined;

As most of the 4.17 work was done by David Miller it's not upto me to contribute the patches back.

Ralf

I have ported 4.17 changes to 5.0. They are available at my FTP site. I
have submitted changes I wrote myself to the gdb team. I have submitting other changes on my to-do list -- it requires checking the changes against the current CVS version and contacting all interested parties. As I lack time at the moment I cannot promise I'll do it in the foreseeable future. If anyone wants to do it -- feel free.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email protected], PGP key available        +

Jun,

Could I use similar updates
for mips(EB)?
Anyway, in my default gdb-5.0 gdb/config/mips/ doesn't contain any ?m-linux.h headers. That's why
configure fails, I suppose.

Thanks,
Michael.

Sure. Go ahead!

Jun

Jun,

I have a problem with your patch:

CVS/           irix5.mh       nm-mips.h       tm-mips.h tm-vr5000el.h  vxmips.mt
bigmips.mt     irix5.mt       nm-news-mips.h  tm-mips64.h    tm-vxmips.h 
   wince.mt
bigmips64.mt   littlemips.mh  nm-riscos.h     tm-mipsm3.h    tm-wince.h 
    xm-irix3.h
decstation.mh  littlemips.mt  riscos.mh       tm-mipsv4.h    tx39.mt 
    xm-irix4.h
decstation.mt  mipsm3.mh      tm-bigmips.h    tm-tx39.h      tx39l.mt 
    xm-irix5.h
embed.mt       mipsm3.mt      tm-bigmips64.h  tm-tx39l.h     vr4100.mt 
    xm-mips.h
embed64.mt     mipsv4.mh      tm-embed.h      tm-vr4100.h    vr4300.mt 
    xm-mipsm3.h

irix3.mt       nm-irix4.h     tm-irix3.h      tm-vr4xxxel.h  vr5000.mt
irix4.mh       nm-irix5.h     tm-irix5.h      tm-vr5000.h    vr5000el.mt

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: [email protected]
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

You can probably look around and find the official gdb-4.17 release.

A better bet is to get from the mvista CDK 1.2 release:

ftp://ftp.mvista.com/pub/CDKit/1.2/cd/Source/SRPMS/hhl-gdb-5.0-1.src.rpm

It says gdb 5.0, but I think gdb-4.17 is "embedded" in it. (If not, let me know).

If you try to add linux-mips to gdb 5.0, you might want to look into the new multi-arch structure introduced in gdb 5.0. It *might* be the reason why original MIPS stuff is removed.

Good luck.

Jun

Jun,

Having seen your recent posting regarding gdb, I am wondering if you could help me. I downloaded gdb from your web site, and tried compiling gdb-4.17 for a mipsel target.

I got gdb to compile OK, but I couldn't get gdbserver to compile. My problems seem similar to the problems Michael Shmulevich had.

I couldn't find any documentation on what order to apply patches, or which patches to apply, so I patched with the following in the following order :

gdb-4.17-mips.patch
gdb-4.17-mips-gdbserver.patch
gdb-4.17-xref.patch

I configured gdb with :
./configure -target=mips-linux-elf

It configured OK and then built OK.

Then I configured gdbserver with :

../../configure --target=mipsel-linux-elf

And then tried compiling.This compiled so far and then gave numerous undefined references to functions such as create_inferior,mywait, myresume etc which are defined in low-linux.c.

So following the previous thread on gdbserver from Micheal Shmulevich, I decided to try :

../../configure --host=mipsel-linux --target=mipsel-linux-elf This gave the following output :
gdbserver/configure.in:host is mipsel-unknown-linux-gnu,target is gdbserver/configure.in:host_cpu is mipsel, target cpu is mipsel
Linked "xm.h" to "./../config/mips/xm-linux.h". Linked "tm.h" to "./../config/mips-tm-embedl.h". Linked "nm.h" to "./../config/nm-empty.h". Created "Makefile" /usr/local/src/gdb-5.0/gdb-4.17/gdb/gdbserver using "../config/mips/mipsel-linux.mh" and "../config/mips/embedl.mt"

I then build with : make CC=mipsel-linux-gcc.

The first file it tries to compile is low-linux.c and immediately errors with :
low-linux.c:In function 'fetch_register':
low-linux.c:248: 'PT_READ_U' undeclared (first use in function)

Looking at the source I believe PT_READ_U is undefined because the link from nm.h to nm-linux.h is not made, Michael made the same observation.

From what I have written can you tell me where I am going wrong ?

Any help would be greatly appreciated

Michael: If you have any tips on how to get gdbserver working they will be warmly welcome.

TIA

Wayne

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

I am trying to bring up a mips based board using the serial console outputing to a serial terminal. Everything seems to boot OK, I see the various printk messages of the kernel booting right up until the execve calls in init/main.c init().
After this point the board stops printing to the serial console, but if I hit return at the terminals keyboard, the terminal's cursor moves down one line. But I still have no command prompt.

Up until now I have been successfully booting the board with the 2.2.13 kernel using nfs as the file system. The problem kernel is my attempt at porting 2.4.0 test 9 to the same board, using the same nfs.

I suspect I have a setup problem with the serial configuration in the kernel ( not the filesystem since 2.2.13 is OK ), maybe it's not selecting the right terminal or not directing output correctly ? But I am not sure how to fix it and would appreciate any help, references to texts that would help me.

Wayne

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

I would suggest you first start by loading ash.static or some other statically compiled shell (boot with "init=/bin/bash or init=/bin/ash.static, depending on what shell you have) and then go from there. If even that doesn't work, try cross compiling a static hello world and load that as the init (something like "init=/bin/hello").

What does you /etc/inittab look like?

Pete

Wayne,

As Pete was wondering most likely you are missing a line in your inittab

# Run gettys in standard runlevels
t0:123:respawn:/sbin/getty ttyS0 DT115200 <------------
1:2345:respawn:/sbin/getty tty1
2:2345:respawn:/sbin/getty tty2
3:2345:respawn:/sbin/getty tty3
4:2345:respawn:/sbin/getty tty4
5:2345:respawn:/sbin/getty tty5
6:2345:respawn:/sbin/getty tty6

Pete, Scott,

Thanks for your input.

I tried booting with init=/bin/ash.static and with a simple "hello world type app". None of them gave me any output to the serial terminal. I also have console defined as a boot param :

xxx console=ttyS0 xxx

I tried modifying my /etc/inittab as per Scott's suggestion, but that also didn't give me any output.

my inittab was :

-----------------------

# Run gettys in standard runlevels
1:12345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

------------------

One further thing I tried was adding a printk( "a" ); in the serial interrupt handler, whenever I hit the return key, it prints out the "a". So I know the serial link still works and is at the correct baud rate etc.

I can use gdb on the board to step through the code and was thinking that if I knew the path of how the kernel :

a, receives a key from the serial terminal
b, processes the key
c, echoes it back to the serial trminal

I may be able to trace the problem. Does anyone know roughly what functions to set breakpoints in to trace program flow as shown above ?

Wayne

serial_outc(

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Dear All,

I have a problem with load_elf_binary() stalling my linux 2.4.0-test9 kernel. Through the use of printk's I have traced program flow all the way up to a call to clear_user( (void *) elf_bss, nbyte ), called from binfmt_elf.c padzero(). A printk immediately after this fucntion call never gets printed out to the serial console.

I said stall above because although the machine appears to "hang", it will still print out to the serial console on receiving a character over the serial port - I have a printk( "+" ) in the serial interrupt.

I looked into clear_user() and see that it makes a call to " __bzero ". From a preliminary search on the web I think __bzero is a library function and so not defined in the kernel ( tried searching kernel sources too ).

If __bzero is a library function, my first thoughts would be to suspect it and the library that contains it. But I have successfully compiled and ran a 2.4.0-test9 kernel for ANOTHER mips development board using the same compiler libraries etc. The variable in this case seems to be my port not the supporting tools.

What I would like to know are :

a, are there any docs explaining __bzero, or could someone explain what it does.

b, does anyone have any idea why clear_user would hang like this ? eg not set up memory correctly etc etc

c, any tips for looking into the problem and tracking down the cause

TIA

Wayne

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/