This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [uClinux-dev] m68k gdb server mi crashes uclinux
- From: NZG <ngustavson at emacinc dot com>
- To: uclinux-dev at uclinux dot org, gdb-patches at sourceware dot org
- Cc: "Mike Lavender" <mike at steroidmicros dot com>
- Date: Thu, 19 Jan 2006 17:28:21 -0600
- Subject: Re: [uClinux-dev] m68k gdb server mi crashes uclinux
- References: <MPEGIONFGEOGCAAKHJGPOEBECPAA.mike@steroidmicros.com> <200601191640.35084.ngustavson@emacinc.com>
Digging deeper, it appears that this only happens if the debugger starts
trying to parse through frames before the program begins executing (i.e. a
remote connection is made but no breakpoint is specified and continue is
never called)
In this case gdbserver appears to just be continually feeding random numbers
back, you get this same effect from the command line by running backtrace
before calling continue.
This appears to be erronous on gdbservers side, I'll continue to dig.
NZG.
On Thursday 19 January 2006 4:40 pm, NZG wrote:
> Hi Mike,
> thanks for the tip!
>
> Problem is, high level debuggers (as I'm sure your aware) may not bother to
> include a depth, in order to retrieve the total depth of the stack.
> gdbserver/uClinux does not seem to like this.
> Does this have something to do with it not having an MMU?
>
> I could certainly patch gdb's mi interface to restrict the depth in can
> search when no arguement is passed, but I would like to figure out if
> that's really necessary first.
>
> thx
> NZG.
>
> On Thursday 19 January 2006 4:25 pm, Mike Lavender wrote:
> > Hi NZG,
> >
> > > However, when I use the MI command to retrieve the stack depth:
> > >
> > > -stack-info-depth
> > >
> > > This call takes some time, then returns with a -1 and causes gdbserver
> > > to smash the OS to bits.
> > >
> > > gdbserver :6000 test_target 2 3
> > > Process test_target created; pid = 112
> > > code at 0x810040 - 0x813940, data at 0x813944
> > > Remote debugging using :6000
> > > ad page state at free_hot_cold_page (in process 'gdbserver', page
> > > 00327300)
> > > flags:0x20001000 mapping:00000000 mapcount:0 count:0
> > > Backtrace:
> > > Stack from 00a3af08:<0>
> > > <0> 00a3af18<0> 00a3af90<0> 0002f418<0> 000ebef9<0> 00327300<0>
> > > 00000000<0> 0002f>
> > > <0> 00327300<0> 00000004<0> 00c29260<0> 00327300<0> 0011032c<0>
> > > 0002f9c6<0> 00327>
> > > <0> 00033e54<0> 00327300<0> 00c29260<0> 00a3afc0<0> 00fcf340<0>
> > > 0001ccba<0> 00327>
> > > <0> 00000000<0> 00000001<0> 00000070<0> 00000000<0> 00000001<0>
> > > 00fcf340<0> 00944>
> > > <0> 00327300<0> 001308b8<0> 00a3afc4<0> 000110c6<0> 00fcf340<0>
> > > 00818010<0> 00a3a>
> > > <0> 00000000<0> 00a3a000<0> 00010fce<0> 0080fe94<0> 0080fe94<0>
> > > 00944230<0> 59e70>
> > > Call Trace:<0>
> > > <0> [<00013a0a>]<0>
> > > Trying to fix it up, but a reboot is needed
> > >
> > >
> > > I suspect it's running through it's memory and into something
> > > else, but some
> > > deep ugly gdb debugging is going to be required.
> > >
> > > Somebody please tell me there is a patch for this.
> > > If not, any tips you might have would be appreciated.
> > >
> > > thx,
> > > NZG
> >
> > The -stack-info-depth command takes an optional argument [max_depth]
> > which will limit how far it goes.
> >
> > see here
> > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC481 for
> > info on the mi stack commands.
> >
> >
> > Mike
> >
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev@uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev@uclinux.org
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org