Re: 1 GCC regressions, 1 new, with your patch on 2001-07-21T09:30:01Z.

Re: 1 GCC regressions, 1 new, with your patch on 2001-07-21T09:30:01Z.

[Geoff Keating]

> The new failures are:
> native gdb.sum gdb.base/selftest.exp:

This was interesting.  After two months, the GCC tree has finally been
stable for long enough for the tester to try to update its binutils
tree.  Unfortunately, this means it updates its _sources_, and it
turns out that selftest.exp requires you keep around the old gdb
sources so it can debug itself.

Since selftest.exp doesn't really test the compiler at all, I have
disabled it.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

remote gdb: reboot system(Linux)

[Michael S. Miles]

I do a lot of Linux remote kernel debugging over serial lines.  I will now
be doing even more of this only the debugger and target system will be at a
remote site.

In a previous life I did a lot of NT kernel debugging with windbg and it had
a command called ".reboot" which if made in windbg would actually cause a
reboot of the target system.  I really need this same capability in gdb when
debugging Linux.  I know that a lot of this functionality was probably
provided in the kernel, but I thought someone might know if this presently
exists or what would be involved with providing it.

thanks for any help or info,
michael

Re: remote gdb: reboot system(Linux)

[Amit S. Kale]

You can set pc to machine_restart function and continue.
That will immediately reboot the machine.

kgdb ( http://kgdb.sourceforge.net/ ) doesn't yet support
gdb remote protocol packets kill, attach and detach.

I'll add it whenever I get some time.

"Michael S. Miles" wrote:
> 
> I do a lot of Linux remote kernel debugging over serial lines.  I will now
> be doing even more of this only the debugger and target system will be at a
> remote site.
> 
> In a previous life I did a lot of NT kernel debugging with windbg and it had
> a command called ".reboot" which if made in windbg would actually cause a
> reboot of the target system.  I really need this same capability in gdb when
> debugging Linux.  I know that a lot of this functionality was probably
> provided in the kernel, but I thought someone might know if this presently
> exists or what would be involved with providing it.
> 
> thanks for any help or info,
> michael

-- 
Amit Kale
Veritas Software ( http://www.veritas.com )

Re: remote gdb: reboot system(Linux)

[Andrew Cagney]

> You can set pc to machine_restart function and continue.
> That will immediately reboot the machine.
> 
> kgdb ( http://kgdb.sourceforge.net/ ) doesn't yet support
> gdb remote protocol packets kill, attach and detach.
> 
> I'll add it whenever I get some time.


Before adding anything I'd carefully read the remote protocol doco, 
especially where it says ``deprecated'' or ``obsolete''.

You may also be interested in the qRcmd packet which allows the user to 
send across arbitrary commands (via ``(gdb) monitor ...'').

	Andrew

Re: remote gdb: reboot system(Linux)

[Amit S. Kale]

Andrew Cagney wrote:
> 
> > You can set pc to machine_restart function and continue.
> > That will immediately reboot the machine.
> >
> > kgdb ( http://kgdb.sourceforge.net/ ) doesn't yet support
> > gdb remote protocol packets kill, attach and detach.
> >
> > I'll add it whenever I get some time.
> 
> Before adding anything I'd carefully read the remote protocol doco,
> especially where it says ``deprecated'' or ``obsolete''.

I'll keep that in mind.
I haven't looked at remote protocol doc in ages.
I need to do the excercise of going through the doc and
chage deprecated functionalities sometime.

> 
> You may also be interested in the qRcmd packet which allows the user to
> send across arbitrary commands (via ``(gdb) monitor ...'').

Great!
I have been using maintenance packets. monitor command is much
better.

Thanks for your suggestions.
-- 
Amit Kale
Veritas Software ( http://www.veritas.com )

Re: 1 GCC regressions, 1 new, with your patch on 2001-07-21T09:30:01Z.

[Nathan Sidwell]

Geoff Keating wrote:
> 
> > The new failures are:
> > native gdb.sum gdb.base/selftest.exp:
>
> Since selftest.exp doesn't really test the compiler at all, I have
> disabled it.
Glad you've sorted this - it confused me as to how removing a testcase
could break the compiler!

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: 1 GCC regressions, 1 new, with your patch on 2001-07-21T09:30:01Z.

[Andrew Cagney]

>> The new failures are:
>> native gdb.sum gdb.base/selftest.exp:
> 
> 
> This was interesting.  After two months, the GCC tree has finally been
> stable for long enough for the tester to try to update its binutils
> tree.  Unfortunately, this means it updates its _sources_, and it
> turns out that selftest.exp requires you keep around the old gdb
> sources so it can debug itself.
> 
> Since selftest.exp doesn't really test the compiler at all, I have
> disabled it.


I'm not sure what you mean,

As far as I know, selftest uses the just built native GDB to test the 
just built native GDB.  The test being skipped when the just built GDB 
isn't native (it doesn't make sense).  I think GCC should retain the 
test since it is testing GDB against a very large program.

	Andrew

Re: 1 GCC regressions, 1 new, with your patch on 2001-07-21T09:30:01Z.

[Geoff Keating]

> Date: Mon, 23 Jul 2001 17:49:36 -0400
> From: Andrew Cagney <ac131313@cygnus.com>

> >> The new failures are:
> >> native gdb.sum gdb.base/selftest.exp:
> > 
> > 
> > This was interesting.  After two months, the GCC tree has finally been
> > stable for long enough for the tester to try to update its binutils
> > tree.  Unfortunately, this means it updates its _sources_, and it
> > turns out that selftest.exp requires you keep around the old gdb
> > sources so it can debug itself.
> > 
> > Since selftest.exp doesn't really test the compiler at all, I have
> > disabled it.
> 
> 
> I'm not sure what you mean,
> 
> As far as I know, selftest uses the just built native GDB to test the 
> just built native GDB.  The test being skipped when the just built GDB 
> isn't native (it doesn't make sense).  I think GCC should retain the 
> test since it is testing GDB against a very large program.

There is no "just-built" gdb.  GCC is tested against a known-working
gdb, built with the system compiler.

-- 
- Geoffrey Keating <geoffk@geoffk.org>