Re: [microblaze-uclinux] GDB with uClinux

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Walt,

White, Walt J (GE Infrastructure) wrote:

> I expanded the tarball in the user/gdbserver dir, updated entry.S and ptrace.c from CVS and put the mb-gdb-user next to mb-gdb.  
> 
> I rebuilt everything and loaded the ./images/pImage.romfs onto the target as usual and booted it.  It comes up like this:
> 
[snip]

> Linux version 2.4.26-uc0-GEIS (root@WaltsLinuxBox) (gcc version 2.95.3-4 Xilinx
> EDK 6.2.1 Build EDK_Gm.12.3) #4 Thu Mar 24 12:54:35 PST 2005

[snip]

> I don't know why I'm getting the kernel BUG.  I enabled full symbolic debugging from the menuconfig->kernel hacking area, assuming it would be useful for gdb.  However, I then built and ran it without the symbolic debugging enabled and get this:
> 
[snip]

> Looks like it hit the kernel bug and performed a reset.  Any ideas on what could be wrong?

I'm almost certain this is versionitis, and a particularly nasty strain 
which I will call intra-kernel version skew!  Your kernel is reporting 
2.4.26, the CVS sources  are now up at 2.4.29.  I guess you've made a 
snapshot of an earlier kernel, and are working on this?

What's happened is that the new version of entry.S that you've updated, 
is mismatched with the rest of your kernel - thus major wierdness that 
you have witnessed.

There was a subtle but important architectural change made to the system 
call interface (e.g. entry.S) back in November, where we migrated to use 
the brki instruction (break), rather than bralid (branch).  This was 
necessary for reasons of stability and cleanness.  You've now updated to 
the new entry.S, but not the rest of the kernel.

Your options here are several:

1. roll forward (in a quarantined test area) to the latest kernel 
sources.  Depending on how much work you've been doing in your private 
kernel you may have a little work to do in forward-porting your changes. 
  I suspect you will have very little work to do.

You will also need to get fresh versions of the files in 
uClibc/libc/sysdeps/linux/microblaze directory.  This is uClibc's 
version of the system call interface - it must match the kernel's or 
nothing will work.

I strongly recommend that you choose this approach.  If you don't, you 
will remain cut-off from ongoing improvements in the kernel.

2. do some forensic diffing between your previous (e.g. pre this-week) 
pre-gdb versions of entry.S and ptrace.c (ptrace shouldn't matter, 
entry.S is crucial), and the current CVS head.  Then manually back-port 
the ptrace/gdb specific changes in entry.S, into your older version.

Actually, it looks like the version of entry.S revision 1.12 should 
probably work.  You could try "cvs update -C -r 1.12 entry.S", and see 
how that goes.

You need to decide and resolve you kernel versionitis before anything 
else will make sense.  It's just bad luck that you chose to snapshot 
before the BRK/BRANCH change in the syscall interface.  This was the 
most fundamental architectural restructure since the microblaze port 
began, and you've just ended up with one foot on either side of the 
divide.

Regards,

John



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/