Mention signal fixes in NEWS

Mention signal fixes in NEWS

[Andrew Cagney]

Hello,

The attached makes mention of all the signal changes in the NEWS file.

Thoughts?

Andrew
2004-05-12  Andrew Cagney  <cagney@redhat.com>

	* NEWS: Mention signal fixes.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.148
diff -p -u -r1.148 NEWS
--- NEWS	7 May 2004 14:34:35 -0000	1.148
+++ NEWS	12 May 2004 18:38:19 -0000
@@ -3,6 +3,14 @@
 
 *** Changes since GDB 6.1:
 
+* Signal trampoline code overhauled
+
+Many generic problems with GDB's signal handling code have been fixed.
+These include: support for sigaltstack and sigaction; backtrace from a
+NULL pointer call; backtrace through a signal trampoline; step into
+and out of signal handlers; and single-stepping in the signal
+trampoline.
+
 * Cygwin support for DWARF 2 added.
 
 * Fixed build problem on IRIX 5
From cagney@gnu.org Wed May 12 19:23:00 2004
From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: Robert Picco <Robert.Picco@hp.com>, gdb-patches@sources.redhat.com
Subject: Re: new gdb remote packet type
Date: Wed, 12 May 2004 19:23:00 -0000
Message-id: <40A279AF.30603@gnu.org>
References: <407F2BAB.4060408@hp.com> <40802711.3040104@gnu.org> <4087E8C0.30806@hp.com> <4087EE4B.4010805@gnu.org> <40912015.7070902@hp.com> <40928D64.8010209@gnu.org> <4097D9DE.2030004@hp.com> <40993C21.1040500@gnu.org> <409A95AB.6020101@hp.com> <40A26AF4.4050001@gnu.org> <20040512183055.GA32460@nevyn.them.org>
X-SW-Source: 2004-05/msg00378.html
Content-length: 781

This patch (if 'p' were implemented for gdbserver; I have this lying
around, as it happens) would make register fetches default to using
individual 'p' packets for every register; this would hurt latency, a
lot.
That isn't true.  The T packet should have previously returned all the 
important registers (and is needed anyway to make single step fast). 
This "p" would just fill in the gaps.

If after this we still have problems, we can investigate transfering 
registers in bigger chunks using qPart:<regset> (it was concluded that, 
for the moment, it is too bigger sledge hammer for this simple nut).

Robert, wouldn't it be good enough for you to work with
!reg->in_g_packet?
The original problem is that all registers are in the g-packet and that 
it was too big.

Andrew

Re: Mention signal fixes in NEWS

[Daniel Jacobowitz]

On Wed, May 12, 2004 at 03:07:49PM -0400, Andrew Cagney wrote:
> Hello,
> 
> The attached makes mention of all the signal changes in the NEWS file.
> 
> Thoughts?

Gives the suggestion it will work for the reader's target, whatever
that may be.  Lots of our targets still don't support this.

-- 
Daniel Jacobowitz

Re: Mention signal fixes in NEWS

[Andrew Cagney]

On Wed, May 12, 2004 at 03:07:49PM -0400, Andrew Cagney wrote:

Hello,

The attached makes mention of all the signal changes in the NEWS file.

Thoughts?


Gives the suggestion it will work for the reader's target, whatever
that may be.  Lots of our targets still don't support this.
Bah, wrong patch ....


2004-05-12  Andrew Cagney  <cagney@redhat.com>

	* NEWS: Mention signal fixes.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.148
diff -p -u -r1.148 NEWS
--- NEWS	7 May 2004 14:34:35 -0000	1.148
+++ NEWS	12 May 2004 21:03:28 -0000
@@ -3,6 +3,17 @@
 
 *** Changes since GDB 6.1:
 
+* Signal trampoline code overhauled
+
+Many generic problems with GDB's signal handling code have been fixed.
+These include: support for sigaltstack and sigaction; backtrace from a
+NULL pointer call; backtrace through a signal trampoline; step into
+and out of signal handlers; and single-stepping in the signal
+trampoline.
+
+Note that kernel and architecture specific limitations may still
+restrict this functionality (ref PR gdb/1639).
+
 * Cygwin support for DWARF 2 added.
 
 * Fixed build problem on IRIX 5
From drow@false.org Wed May 12 21:05:00 2004
From: Daniel Jacobowitz <drow@false.org>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Mention signal fixes in NEWS
Date: Wed, 12 May 2004 21:05:00 -0000
Message-id: <20040512210545.GA4198@nevyn.them.org>
References: <40A27605.70805@gnu.org> <20040512205638.GC3728@nevyn.them.org> <40A29175.10801@gnu.org>
X-SW-Source: 2004-05/msg00388.html
Content-length: 557

On Wed, May 12, 2004 at 05:04:53PM -0400, Andrew Cagney wrote:
> >On Wed, May 12, 2004 at 03:07:49PM -0400, Andrew Cagney wrote:
> >
> >>>Hello,
> >>>
> >>>The attached makes mention of all the signal changes in the NEWS file.
> >>>
> >>>Thoughts?
> >
> >
> >Gives the suggestion it will work for the reader's target, whatever
> >that may be.  Lots of our targets still don't support this.
> 
> Bah, wrong patch ....
> 
> 

> 2004-05-12  Andrew Cagney  <cagney@redhat.com>
> 
> 	* NEWS: Mention signal fixes.

Beautiful! :)  Thanks.

-- 
Daniel Jacobowitz

Re: Mention signal fixes in NEWS

[Eli Zaretskii]

> Date: Wed, 12 May 2004 15:07:49 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> The attached makes mention of all the signal changes in the NEWS file.
> 
> Thoughts?

Okay, but:

> +Many generic problems with GDB's signal handling code have been fixed.
> +These include: support for sigaltstack and sigaction;

I'd prefer that we spell out what this ``support for sigaltstack and
sigaction'' means, in user-level terms.  That is, what exactly didn't
work before and now does, when sigaltstack and sigaction are involved?

> +Note that kernel and architecture specific limitations may still
> +restrict this functionality (ref PR gdb/1639).

How about being more explicit here?  What configurations have this
new support, and which don't?  Can we list at least the more popular
platforms in each category?

Re: Mention signal fixes in NEWS

[Andrew Cagney]

+Many generic problems with GDB's signal handling code have been fixed.
+These include: support for sigaltstack and sigaction;


I'd prefer that we spell out what this ``support for sigaltstack and
sigaction'' means, in user-level terms.  That is, what exactly didn't
work before and now does, when sigaltstack and sigaction are involved?
... include: backtraces through non-contigious stacks (see 
sigaltstack(2)); recognition of sa_sigaction signal trampolines (see 
sigaction(2)); ...

+Note that kernel and architecture specific limitations may still
+restrict this functionality (ref PR gdb/1639).


How about being more explicit here?  What configurations have this
new support, and which don't?  Can we list at least the more popular
platforms in each category?
That gets complicated.  Since some features only work on specific 
patched kernels.  However we can probably safely state that the features 
do work on ``i386 GNU/Linux systems that include a 2.4 kernel''.

Andrew

Re: Mention signal fixes in NEWS

[Eli Zaretskii]

> Date: Thu, 13 May 2004 14:33:40 -0400
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > I'd prefer that we spell out what this ``support for sigaltstack and
> > sigaction'' means, in user-level terms.  That is, what exactly didn't
> > work before and now does, when sigaltstack and sigaction are involved?
> 
> ... include: backtraces through non-contigious stacks (see 
> sigaltstack(2)); recognition of sa_sigaction signal trampolines (see 
> sigaction(2)); ...

I think it's enough to add this text (even without the references to
the functions' man pages).

> However we can probably safely state that the features do work on
> ``i386 GNU/Linux systems that include a 2.4 kernel''.

That's good enough, I think.

Re: Mention signal fixes in NEWS

[Andrew Cagney]

Here's the entire updated text:

* Signal trampoline code overhauled

Many generic problems with GDB's signal handling code have been fixed.
These include: backtraces through non-contigious stacks; recognition
of sa_sigaction signal trampolines; backtrace from a NULL pointer
call; backtrace through a signal trampoline; step into and out of
signal handlers; and single-stepping in the signal trampoline.
These fixes were tested on i386 GNU/Linux systems that include a 2.4
kernel.
?

Andrew

Re: Mention signal fixes in NEWS

[Eli Zaretskii]

> Date: Fri, 14 May 2004 11:44:16 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> Here's the entire updated text:
> 
> > * Signal trampoline code overhauled
> > 
> > Many generic problems with GDB's signal handling code have been fixed.
> > These include: backtraces through non-contigious stacks; recognition
> > of sa_sigaction signal trampolines; backtrace from a NULL pointer
> > call; backtrace through a signal trampoline; step into and out of
> > signal handlers; and single-stepping in the signal trampoline.
> > 
> > These fixes were tested on i386 GNU/Linux systems that include a 2.4
> > kernel.
> 
> ?

Thanks, I'm happy now.

Re: Mention signal fixes in NEWS

[Andrew Cagney]

Thanks, I'm happy now.
Here's it as committed.

thanks,

Andrew

2004-05-17  Andrew Cagney  <cagney@redhat.com>

	* NEWS: Mention signal fixes.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.148
diff -p -u -r1.148 NEWS
--- NEWS	7 May 2004 14:34:35 -0000	1.148
+++ NEWS	17 May 2004 19:14:30 -0000
@@ -3,6 +3,17 @@
 
 *** Changes since GDB 6.1:
 
+* Signal trampoline code overhauled
+
+Many generic problems with GDB's signal handling code have been fixed.
+These include: backtraces through non-contiguous stacks; recognition
+of sa_sigaction signal trampolines; backtrace from a NULL pointer
+call; backtrace through a signal trampoline; step into and out of
+signal handlers; and single-stepping in the signal trampoline.
+
+These fixes were tested on i386 GNU/Linux systems that include a 2.4
+kernel.
+
 * Cygwin support for DWARF 2 added.
 
 * Fixed build problem on IRIX 5
From cagney@gnu.org Mon May 17 19:49:00 2004
From: Andrew Cagney <cagney@gnu.org>
To: Mark Kettenis <kettenis@chello.nl>
Cc: gdb-patches@sources.redhat.com, freebsd-hackers@freebsd.org, tech-toolchain@netbsd.org
Subject: Re: [PATCH/RFC] *BSD kernel debugging
Date: Mon, 17 May 2004 19:49:00 -0000
Message-id: <40A9172B.9000300@gnu.org>
References: <200405171132.i4HBW0h5012696@elgar.kettenis.dyndns.org>
X-SW-Source: 2004-05/msg00503.html
Content-length: 866

+void
+_initialize_bsd_kvm (void)
+{
+  bsd_kvm_ops.to_shortname = "kvm";
+  bsd_kvm_ops.to_longname = "Kernel memory interface";
+  bsd_kvm_ops.to_doc = "XXX";
+  bsd_kvm_ops.to_open = bsd_kvm_open;
+  bsd_kvm_ops.to_close = bsd_kvm_close;
+  bsd_kvm_ops.to_fetch_registers = bsd_kvm_fetch_registers;
+  bsd_kvm_ops.to_xfer_memory = bsd_kvm_xfer_memory;
+  bsd_kvm_ops.to_stratum = process_stratum;
+  bsd_kvm_ops.to_has_memory = 1;
+  bsd_kvm_ops.to_has_stack = 1;
+  bsd_kvm_ops.to_has_registers = 1;
+  bsd_kvm_ops.to_magic = OPS_MAGIC;
+
+  add_target (&bsd_kvm_ops);
+}
Can the deck chairs be re-arange a little here?  Instead of having:
	bsd_kvm_supply_pcb
picked up by accident, add an _initialize to the *-nat.c files where 
they can do something more explicit vis:

	_initialize_foobsd_nat ()
	{
	  add_bsd_kvm_target (foobsd_kvm_supply_pcb);
	}
Andrew