AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Rendell.Fong@lsi.com>,<David.Olien@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	1270832739.26360.416.camel@rendellf
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 9 Apr 2010 12:05:19 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: Rendell Fong <Rendell.Fong@lsi.com>
Cc: "Olien, David" <David.Olien@lsi.com>
Subject: Re: what exactly are these kernels
Message-ID: <20100409120519.5b78e939@ripper.onstor.net>
In-Reply-To: <1270832739.26360.416.camel@rendellf>
References: <6C678488C5CEE74F813A4D1948FD2DC7B7C5C336@cosmail02.lsi.com>
	<20100406115808.2ac6b35a@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7C5C502@cosmail02.lsi.com>
	<20100408142404.0815eb00@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7C5CC8C@cosmail02.lsi.com>
	<20100408153733.7cc68c5a@ripper.onstor.net>
	<6C678488C5CEE74F813A4D1948FD2DC7B7C5CD0D@cosmail02.lsi.com>
	<48CB2A5C4EED4E4BB7E555147EE4D8C1F6AEF713@cosmail03.lsi.com>
	<1270830619.26360.406.camel@rendellf>
	<6C678488C5CEE74F813A4D1948FD2DC7B7C5CE40@cosmail02.lsi.com>
	<1270832739.26360.416.camel@rendellf>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Please work against the version of gdb on the standard workstation
image, which is 6.8-3.  You can get the source with

apt-get source gdb

Hopefully it's quite close to the steath source Rendell was using ~:^)

Then follow the way other packages that we modify are done in
<branch>/linux/Pkgs/source with regards to how the changes are
maintained and the binary version(s) built.  This is how we make it
easier to go to X86 -- by using standard packages and maintaining our
changes as patches checked into perforce.  It's also how we make it
easier to adopt an update of a package.

The changes also need to be submitted upstream at some point.  Unless
you want to keep maintaining them for the rest of your natural life.

Cheerio,

a

On Fri, 9 Apr 2010 11:05:39 -0600 Rendell Fong <Rendell.Fong@lsi.com>
wrote:

> I'm not sure how much of the code in that file is still applicable
> because I'm not too familiar with it.
> 
> The linux kernel uses the gdb stub code in this file
> (arch/mips/kernel/ gdb-stub.c) when a gdb client sets up a remote
> connection.  So perhaps you need to see if the thread functionality
> can be supported somehow. 
> 
> 
> On Fri, 2010-04-09 at 10:53 -0600, Olien, David wrote:
> > Thanks for the information.
> > 
> > I'm not real familiar with gdb internals.
> > So tell me if this is wrong.
> > I'm inclined to build on Rendell's changes to gdb 6.8.
> > It may be more easily moved to the eventual x86 platform.
> > 
> > Max pointed me to the dev branch's nfx-tree/code/sm-except/debug.c
> > as the place where esm threads support has been.
> > 
> > If this isn't what you'd like me to do,
> > Then give me some suggestions.
> > 
> > dave
> > 
> > -----Original Message-----
> > From: Rendell Fong [mailto:Rendell.Fong@lsi.com] 
> > Sent: Friday, April 09, 2010 9:30 AM
> > To: Sharp, Andy
> > Cc: Olien, David
> > Subject: RE: what exactly are these kernels
> > 
> > There is no requirement to use gdb 6.8.  However, I chose it
> > because it was more up to date than the stuff that's checked in and
> > because I felt that it had a better chance of working w/o a lot of
> > tweeking.  I also didn't need to support our threads.
> > 
> > I don't know what was done to the gdb 5.1.1 code that is checked in.
> > 
> > The gdb binary (/n/Build-Trees/gdb/gdb64-tux) was built for mips64
> > target and I used it last year when I got kgdb to work.  It was
> > build from source in ~rendellf/linuxsrc/gdb-6.8 and the src code is
> > not checked in.  I don't recall off hand whether I made any changes
> > to it, but I do have the original tar file.  So all the files can
> > be checked for changes.
> > 
> > I did make a number of changes in the kernel (rcon driver and
> > gdb-stub code) and that is all checked in.
> > 
> > 
> > 
> > On Thu, 2010-04-08 at 23:31 -0600, Sharp, Andy wrote:
> > > Some idiot has screwed with the ssh gateway and made the
> > > filesystem read-only, so I am stuck using OWA, so I have no idea
> > > what my emails are going to look like.  Sorry about that.
> > > 
> > > > The checkin of the gdb that's in the //depot/devtools look
> > > > Like they were mostly made by someone "kenr"?
> > > 
> > > That crap I can safely tell you to completely ignore, it's not
> > > being used by anyone.  Ever.  I believe that we use gdb from the
> > > developer root filesystem on the filer itself.
> > > 
> > > 
> > > ________________________________________
> > > From: Olien, David
> > > Sent: Thursday, April 08, 2010 7:46 PM
> > > To: Sharp, Andy
> > > Subject: RE: what exactly are these kernels
> > > 
> > > OK.
> > > 
> > > I'll ask Rendell about gdb requirements, copy you and max?
> > > 
> > > The checkin of the gdb that's in the //depot/devtools look
> > > Like they were mostly made by someone "kenr"?
> > > 
> > > 
> > > -----Original Message-----
> > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > Sent: Thursday, April 08, 2010 3:38 PM
> > > To: Olien, David
> > > Subject: Re: what exactly are these kernels
> > > 
> > > Hi David,
> > > 
> > > They are all 64-bit: SSC and tuxstor.  They are all the same
> > > processor, just one is 4-cores, and one is single core.  .32
> > > doesn't refer to 32-bit, it refers to ELF-32, which is the only
> > > ELF format that various bin-utils understand.  The symbol table
> > > is not stripped out of any kernels, it's there in all of them.
> > > 
> > > Where is the gdb 6.8 version "requirement" coming from?  If you
> > > have any specific questions about the work that was done, feel
> > > free to email Rendell, as he did all that.  It was a fair bit of
> > > work, with mixing and matching of kernel code and gdb and all
> > > like that.
> > > 
> > > On Thu, 8 Apr 2010 16:20:21 -0600 "Olien, David"
> > > <David.Olien@lsi.com> wrote:
> > > 
> > > > Andy,
> > > >
> > > > Yes, I was interested in usage with gdb/kgdg to examine
> > > > Kernels running on the txrx processors (the tuxrx kernel)
> > > > I have rcon working, and have poked at memory for a running
> > > > Txrx kernel now.
> > > >
> > > > I think the kernel image with the symbols I want is
> > > > the vmlinux file under .../tuxrx/linux/kernel/linux-mips-2.6
> > > >
> > > > That seems to be the only 64-bit linux image that has symbols.
> > > > The kernel running on the txrx processors IS a 64-bit kernel,
> > > > right? Or did I just imagine that from somewhere.  Txrx/fp can
> > > > have a large Physical memory, so 64bits is useful.
> > > >
> > > > Unlike the kernel running on the ssc, which I think is a 32 bit
> > > > one, Since physical memory on the ssc is small (~500 megabytes?)
> > > > 64 bits would just waste physical memory.
> > > >
> > > > Yeah, gdb doesn't know how to read the bootable images.
> > > > The symbol information has been stripped, plus bootup code
> > > > Prepended.
> > > >
> > > > I'm looking over the modifications that were done to the
> > > > Gdb we use for debugging the original cougars.
> > > > I THINK that the debugger's understanding of the threads
> > > > Model is in that code.
> > > >
> > > > But that's gdb version 5.1.1.  Now we want gdb 6.8.
> > > >
> > > > It LOOKS like the checkin of the ONSTOR gdb code was done in
> > > > One step... the first checkin includes the changes made
> > > > For the threads. So I can't use the change history to
> > > > Determine what was changed and why.  I am not expert with
> > > > Perforce yet though, so I could be wrong.
> > > >
> > > > Instead, I've located original source for that version  of
> > > > Gdb I can compare with.
> > > >
> > > > I'm also reading over GNU's gdb internals document.
> > > > It's not complete, but it's a start.
> > > >
> > > > dave
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > > Sent: Thursday, April 08, 2010 2:24 PM
> > > > To: Olien, David
> > > > Subject: Re: what exactly are these kernels
> > > >
> > > > Hi David,
> > > >
> > > > Did this question ever get answered to your satisfaction?  I
> > > > guess my question was, what do you want to do with the symbol
> > > > table?  If your using it as an input file for kgdb, then
> > > > probably the .32 one. The .bin (and, I'm guessing, the .tx
> > > > and .cg) one(s) are the binary versions used for loading since
> > > > we don't have an ELF loading PROM. But they still contain the
> > > > symbol table.  I don't know if gdb knows how to read them or
> > > > not.  The Symbol.map files are just the symbol table, dumped
> > > > out in ASCII.
> > > >
> > > > On Tue, 6 Apr 2010 13:22:54 -0600 "Olien, David"
> > > > <David.Olien@lsi.com> wrote:
> > > >
> > > > > Sorry, I guess I was tired last night.
> > > > >
> > > > > Basic question was, which kernel file still
> > > > > Has symbol table information for the tuxrx kernel?
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Sharp [mailto:andy.sharp@lsi.com]
> > > > > Sent: Tuesday, April 06, 2010 11:58 AM
> > > > > To: Olien, David
> > > > > Subject: Re: what exactly are these kernels
> > > > >
> > > > > What's the larger question?
> > > > >
> > > > > On Mon, 5 Apr 2010 21:15:31 -0600 "Olien, David"
> > > > > <David.Olien@lsi.com> wrote:
> > > > >
> > > > > > I could walk through the Make files (I probably should at
> > > > > > some point).
> > > > > >
> > > > > > But until I do that.  I thought I'd just ask what all the
> > > > > > kernel versions are.
> > > > > >
> > > > > > In the directory:
> > > > > >
> > > > > > Builds/Build-tuxrx-1/tx/dbg/Release/boot
> > > > > >
> > > > > > I see kernel files:
> > > > > >
> > > > > > -rw-r--r-- 1 root root 37219909 2010-04-05 19:49 System.map
> > > > > > -rw-r--r-- 1 root root  2084748 2010-04-05 19:27
> > > > > > System-ssc.map -rwxr-xr-x 1 root root 50427859 2010-04-05
> > > > > > 19:49 vmlinux.32 -rw-r--r-- 2 root root  3112528 2010-04-05
> > > > > > 19:27 vmlinux.bin -rw-r--r-- 2 root root  3112528
> > > > > > 2010-04-05 19:27 vmlinux.cg -rwxr-xr-x 1 root root  4697493
> > > > > > 2010-04-05 19:27 vmlinux-ssc.32 -rw-r--r-- 1 root root
> > > > > > 3564232 2010-04-05 19:49 vmlinux.tx
> > > > > >
> > > > > > vmlinux.32:     ELF 32-bit LSB executable, MIPS, MIPS64
> > > > > > version 1 (SYSV), statically linked, not stripped
> > > > > > vmlinux.bin:    data vmlinux.cg:     data
> > > > > > vmlinux-ssc.32: ELF 32-bit LSB executable, MIPS, MIPS64
> > > > > > version 1 (SYSV), statically linked, not stripped
> > > > > > vmlinux.tx:     data
> > > > > >
> > > > > > vmlinux.cg and vmlinux.bin are identical.
> > > > > > These are the kernels bootable by the SSC?
> > > > > > And vmlinux-ssc.32 holds the symbol table for this.
> > > > > > And System-ssc.map is the map file.
> > > > > >
> > > > > > Vmlinux.tx is of course the kernel for tuxrx.
> > > > > > It's symbols can be found in vmlinux.32?
> > > > > >
> > > > > > All of the kernels that have symbols are 32-bit kernels.
> > > > > > So, all the kernels are 32-bit?
> > > > > >
> > > > > > I notice that in
> > > > > >
> > > > > > tuxrx/linux/kernel/linux-mips-2.6
> > > > > >
> > > > > > there is a vmlinux file with symbols there, which is
> > > > > > a 64-bit kernel.
> > > > > >
> > > > > > Just trying to sort it all out.
> > > > > >
> > > > > > dave
> > 
> 
