FYI: gdbserver branch merges

FYI: gdbserver branch merges

[Daniel Jacobowitz]

I've moved these patches to the branch.  This is all the gdbserver
changes except for x86-64 (which was too invasive, and I don't consider
urgent since x86-64 is not yet a production architecture) since we
branched.  For the signals code I created new files without removing
the old definitions.

gdb/:

2002-03-29  Daniel Jacobowitz  <drow@mvista.com>

        Merge from trunk:

        2002-03-27  Daniel Jacobowitz  <drow@mvista.com>

        * gdbserver/server.c (main): Call target_signal_to_host_p
        and target_signal_to_host on signals received from the remote.
        * gdbserver/remote-utils.c (prepare_resume_reply): Call
        target_signal_from_host on signals sent to the remote.
        * gdbserver/server.h: Add prototypes.  Include "gdb/signals.h".
        * gdbserver/Makefile.in: Add signals.o.  Add -I${INCLUDE_DIR}.


        2002-03-20  Martin M. Hunt  <hunt@redhat.com>

        * gdbserver/remote-utils.c (remote_open): Don't call
        getprotobyname, we're all using TCP here so just use
        IPPROTO_TCP.
        * gdbserver/gdbreplay.c (remote_open): Ditto.


        2002-03-13  Michal Ludvig  <mludvig@suse.cz>

        * gdbserver/remote-util.c (remote_open): Print remote-side's
        IP address when remote debugging over the network.

2002-03-29  Daniel Jacobowitz  <drow@mvista.com>

        Merge from trunk:
        2002-03-27  Daniel Jacobowitz  <drow@mvista.com>

        * signals/signals.c: Include "server.h" in gdbserver build.
        (target_signal_from_name): Don't use STREQ.
        (_initialize_signals): Likewise.  Don't include function in
        gdbserver build.

2002-03-29  Daniel Jacobowitz  <drow@mvista.com>

        Merge from trunk:
        * signals/signals.c: New file, copied from signals.c.

include/:
2002-03-29  Daniel Jacobowitz  <drow@mvista.com>

        Merge from trunk:
        2002-03-10  Daniel Jacobowitz <drow@mvista.com>
        * gdb: New directory.

include/gdb/:
2002-03-29  Daniel Jacobowitz  <drow@mvista.com>

        Merge from trunk:
        2002-03-10  Daniel Jacobowitz  <drow@mvista.com>
        * signals.h: New file, from gdb/defs.h.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: FYI: gdbserver branch merges

[Andreas Jaeger]

Daniel Jacobowitz <drow@mvista.com> writes:

> I've moved these patches to the branch.  This is all the gdbserver
> changes except for x86-64 (which was too invasive, and I don't consider
> urgent since x86-64 is not yet a production architecture) since we
> branched.  For the signals code I created new files without removing
> the old definitions.

For when is 5.2 planned and when is the next release?  Since x86-64 is
currently not production ready, we can make big changes.  The first
hammer systems are going to ship by the end of the year so that I
expect that we'll use GDB 5.2 on them.  Could you rethink this,
please?

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: FYI: gdbserver branch merges

[Daniel Jacobowitz]

On Fri, Mar 29, 2002 at 08:31:57PM +0100, Andreas Jaeger wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > I've moved these patches to the branch.  This is all the gdbserver
> > changes except for x86-64 (which was too invasive, and I don't consider
> > urgent since x86-64 is not yet a production architecture) since we
> > branched.  For the signals code I created new files without removing
> > the old definitions.
> 
> For when is 5.2 planned and when is the next release?  Since x86-64 is

I don't know what the current plan is, but it should be within the next
two/three weeks if all goes well.

> currently not production ready, we can make big changes.  The first
> hammer systems are going to ship by the end of the year so that I
> expect that we'll use GDB 5.2 on them.  Could you rethink this,
> please?

There should be another release by then; I think Andrew was hoping for
one mid-April and one in late September.  If you'd prefer to have the
x86-64 changes on the branch you're welcome to merge them; I was just
doing the bits I was confident in, and the x86-64 changes were too
large for someone who doesn't know anything about the port to merge
safely.  The gdbserver bits also need to bring in all the recent
changes to the tdep files.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: FYI: gdbserver branch merges

[Andrew Cagney]

> On Fri, Mar 29, 2002 at 08:31:57PM +0100, Andreas Jaeger wrote:
> 
>> Daniel Jacobowitz <drow@mvista.com> writes:
>> 
> 
>> > I've moved these patches to the branch.  This is all the gdbserver
>> > changes except for x86-64 (which was too invasive, and I don't consider
>> > urgent since x86-64 is not yet a production architecture) since we
>> > branched.  For the signals code I created new files without removing
>> > the old definitions.
> 
>> 
>> For when is 5.2 planned and when is the next release?  Since x86-64 is
> 
> 
> I don't know what the current plan is, but it should be within the next
> two/three weeks if all goes well.

Yes.  The only thing I'm still trying to resolve is the HP/UX cc -Ae 
patches.  There are some symtab bugs but I'm not going to try to resolve 
them.

That suggests:
	this weekend - snap (2002-04-06)
	next weekend - snap (2002-04-13)
	saturday fortnight - release (2002-04-20)

>> currently not production ready, we can make big changes.  The first
>> hammer systems are going to ship by the end of the year so that I
>> expect that we'll use GDB 5.2 on them.  Could you rethink this,
>> please?
> 
> 
> There should be another release by then; I think Andrew was hoping for
> one mid-April and one in late September.  If you'd prefer to have the
> x86-64 changes on the branch you're welcome to merge them; I was just
> doing the bits I was confident in, and the x86-64 changes were too
> large for someone who doesn't know anything about the port to merge
> safely.  The gdbserver bits also need to bring in all the recent
> changes to the tdep files.

I believe the most recent x86-64 changes have already been pulled into 
the branch (well at least the non-gdbserver bits).

Releases are trying to be ~4 months: Mar-Apr, Jul-Aug and Nov-Dec time 
frames.  (The cron job that tracks the schedule indicates 2002-07-07 so 
I think it is broken).

enjoy,
Andrew

Re: FYI: gdbserver branch merges

[Eli Zaretskii]

On Fri, 29 Mar 2002, Daniel Jacobowitz wrote:

> I've moved these patches to the branch.

Does the manual need any changes as result of these merges?  If so, 
could you please submit the changes for the docs as well?

TIA

Re: FYI: gdbserver branch merges

[Daniel Jacobowitz]

On Sun, Mar 31, 2002 at 07:41:08AM +0200, Eli Zaretskii wrote:
> 
> On Fri, 29 Mar 2002, Daniel Jacobowitz wrote:
> 
> > I've moved these patches to the branch.
> 
> Does the manual need any changes as result of these merges?  If so, 
> could you please submit the changes for the docs as well?
> 
> TIA

No, it doesn't.  Thanks for checking.

I still owe a NEWS entry about gdbserver; I'll do that in a day or two.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: FYI: gdbserver branch merges

[Andrew Cagney]

> On Sun, Mar 31, 2002 at 07:41:08AM +0200, Eli Zaretskii wrote:
> 
>> 
>> On Fri, 29 Mar 2002, Daniel Jacobowitz wrote:
>> 
> 
>> > I've moved these patches to the branch.
> 
>> 
>> Does the manual need any changes as result of these merges?  If so, 
>> could you please submit the changes for the docs as well?
>> 
>> TIA
> 
> 
> No, it doesn't.  Thanks for checking.

Well yes and no :-)  It doesn't introduce any new features (so no) but 
the remote debugging chapter's gdbserver section does need some work (so 
yes) :-).

enjoy,
Andrew