Re: xfer_memory(..., attrib, ...) post mortem

Re: xfer_memory(..., attrib, ...) post mortem

[Fernando Nasser]

> Comments, 

Good idea!

> volunteers?

No way! :-)


Andrew Cagney wrote:
> 
> Hello,
> 
> J.T. recently tried to modify the target vector by adding an ``attrib''
> parameter to the xfer_memory() method.  Unfortunatly, a few of the
> ``xfer_memory()'' methods were missed (I think I've found the last of
> them - patch to follow).  I figure a little P.M. is in order :-)
> 
> First however, I think I should congratulate J.T. for at least
> attempting the ``right thing'' (tm)!  If you look through the sources
> you'll find plenty of examples where others, when faced with that same
> challenge, have just run away and hidden behind MACROs.  Just check the
> TODO file:
> 
> --
> Move remote_remove_hw_breakpoint, remote_insert_hw_breakpoint,
> remote_remove_watchpoint, remote_insert_watchpoint into target vector.
> --
> 
> So anyway, back to the P.M. - there has to be a better way.  In fact, if
> we're to ever make GDB async, there had better be a better way :-)
> 
> It should be possible to modify the target vector without having to
> grep/examine every line of source and potentially breaking every target.
> 
> With that in mind, I'd like to draw on the experience of
> gdbarch.{sh,h.c}  and propose that the target vector be redone so that
> it is more along the lines of ``struct gdbarch *''.
> 
> Doing that should make it possible for people to pull the now pretty
> standard hack of, instead of changing an existing interface, introduce a
> new one and rename the old to deprecated_*. A legacy function could be
> used to maintain compatibility.
> 
> Comments, volunteers?
> 
>         Andrew

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: xfer_memory(..., attrib, ...) post mortem

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Depends on what you mean by ``flag day''.
Andrew>
Andrew> I can see the following ongoing process occuring:
Andrew>
Andrew> 	o	new interfaces being introduced
Andrew> 		(see gdbarch_register_{read,write})
Andrew>
Andrew> 	o	redundant interfaces (from above)
Andrew> 		being deprecated or deleted
Andrew>
Andrew> 	o	targets that are full of deprecated
Andrew> 		code being obsoleted.
Andrew>
Andrew> The emphasis being on a continuum of change rather than single ``flag
Andrew> days''.  That way, at any stage, GDB should still be working and
Andrew> stable.  I could, in theory, cut a new GDB release at any time - the
Andrew> project shouldn't be able to go down the rat hole of wildly osolating
Andrew> between radical new development and stablizing for the next release.

I can't argue with anything you've said.  Whether it will work or not
depends on our committent to execute the above plan.  I have no doubts
about the first step, it's the second two that give me pause.  If the
backwards compatible infrastructure "works" well enough, there is no
incentive to complete the process.  When it comes to the decision to
obsolete an target because no one has bothered to update to the new
interfaces, we can't be swayed by the argument that we can't do that
because the target is important.  IMO if it was really important, it 
would have been kept up to date.

Andrew> 	o	the old/redundant interfaces be
Andrew> 		deprecated and/or that code be updated

Andrew> 		This is probably where GDB has
Andrew> 		been falling down.  I intend
Andrew> 		being really agressive with
Andrew> 		applying the mechanical operation
Andrew> 		s/interface/deprecated_interface/.

Good to hear.  I approve.

        --jtc

-- 
J.T. Conklin
RedBack Networks

xfer_memory(..., attrib, ...) post mortem

[Andrew Cagney]

Hello,

J.T. recently tried to modify the target vector by adding an ``attrib''
parameter to the xfer_memory() method.  Unfortunatly, a few of the
``xfer_memory()'' methods were missed (I think I've found the last of
them - patch to follow).  I figure a little P.M. is in order :-)

First however, I think I should congratulate J.T. for at least
attempting the ``right thing'' (tm)!  If you look through the sources
you'll find plenty of examples where others, when faced with that same
challenge, have just run away and hidden behind MACROs.  Just check the
TODO file:

--
Move remote_remove_hw_breakpoint, remote_insert_hw_breakpoint,
remote_remove_watchpoint, remote_insert_watchpoint into target vector.
--

So anyway, back to the P.M. - there has to be a better way.  In fact, if
we're to ever make GDB async, there had better be a better way :-)

It should be possible to modify the target vector without having to
grep/examine every line of source and potentially breaking every target.

With that in mind, I'd like to draw on the experience of
gdbarch.{sh,h.c}  and propose that the target vector be redone so that
it is more along the lines of ``struct gdbarch *''.

Doing that should make it possible for people to pull the now pretty
standard hack of, instead of changing an existing interface, introduce a
new one and rename the old to deprecated_*. A legacy function could be
used to maintain compatibility.

Comments, volunteers?

	Andrew

Re: xfer_memory(..., attrib, ...) post mortem

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> It should be possible to modify the target vector without
Andrew> having to grep/examine every line of source and potentially
Andrew> breaking every target.
Andrew>
Andrew> With that in mind, I'd like to draw on the experience of
Andrew> gdbarch.{sh,h.c} and propose that the target vector be redone
Andrew> so that it is more along the lines of ``struct gdbarch *''.
Andrew>
Andrew> Doing that should make it possible for people to pull the now
Andrew> pretty standard hack of, instead of changing an existing
Andrew> interface, introduce a new one and rename the old to
Andrew> deprecated_*. A legacy function could be used to maintain
Andrew> compatibility.
Andrew
Andrew> Comments, [...] 

I want to point out that it is possible to take backwards
compatibility too far.  Experience has told me that when you have
a "flag day" conversion, there is a little pain as loose ends are
cleaned up, but then it's over and down with.  But if backwards
compatible interfaces are maintained, chances are good that nothing
will be done.  There is no incentive for change.  In the end, the
system is saddled with the complexity of multiple implementations.

That's why I approve (in principle) of the discussion to remove the
sync event loop even though it will likely break my remote-wdb.c back
end.

If anything, I think that we haven't been aggressive enough wrt.
flushing these from GDB.  e.g. changing FRAME_FIND_SAVED_REGS to
FRAME_INIT_SAVED_REGS is a reasonably easy change, but many ports
have yet to make the switch.

In short, I have no problems with global changes with unforseen rough
edges that get cleaned up in a few days for actively maintained
targets, and perhaps a bit longer for those targets that aren't.
I believe this results in better code in the long term, and the
occasional pain isn't great enough to outweigh this.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: xfer_memory(..., attrib, ...) post mortem

[Andrew Cagney]

"J.T. Conklin" wrote:

> I want to point out that it is possible to take backwards
> compatibility too far.  Experience has told me that when you have
> a "flag day" conversion, there is a little pain as loose ends are
> cleaned up, but then it's over and down with.  But if backwards
> compatible interfaces are maintained, chances are good that nothing
> will be done.  There is no incentive for change.  In the end, the
> system is saddled with the complexity of multiple implementations.

Depends on what you mean by ``flag day''.

I can see the following ongoing process occuring:

	o	new interfaces being introduced
		(see gdbarch_register_{read,write})

	o	redundant interfaces (from above)
		being deprecated or deleted

	o	targets that are full of deprecated
		code being obsoleted.

The emphasis being on a continuum of change rather than single ``flag
days''.  That way, at any stage, GDB should still be working and
stable.  I could, in theory, cut a new GDB release at any time - the
project shouldn't be able to go down the rat hole of wildly osolating
between radical new development and stablizing for the next release.

However, I do see something very similar to a ``flag day'' looming.  A
line needs to be draw in the sand after which point any target (read x86
and arm) that isn't using gdbarch will be obsoleted.  

That line should probably be called ``5.2''.

> In short, I have no problems with global changes with unforseen rough
> edges that get cleaned up in a few days for actively maintained
> targets, and perhaps a bit longer for those targets that aren't.
> I believe this results in better code in the long term, and the
> occasional pain isn't great enough to outweigh this.

I'm expecting to see the following process:

	o	a new interface being introduced

	o	where applicable legacy code
		for the previous interface being
		provided.

	o	that new interface evolve and
		stablize.

		This is important, it allows the
		new interface to stablize without
		the need to constantly change all
		the existing targets.

	o	the old/redundant interfaces be
		deprecated and/or that code be updated

		This is probably where GDB has
		been falling down.  I intend
		being really agressive with
		applying the mechanical operation
		s/interface/deprecated_interface/.

As an example, consider the gdbarch_register_{read,write} and associated
changes.  I wouldn't expect existing code to rush out and use this now. 
Rather, I'd expect people maintaining existing targets to wait a little
and then leap frog the current interface going straght to what is
hopefully the final version.

Any way, in the end it is a balancing act between keeping GDB stable and
allowing new development :-)

	Andrew

Re: xfer_memory(..., attrib, ...) post mortem

[Eli Zaretskii]

On Wed, 21 Mar 2001, Andrew Cagney wrote:

> However, I do see something very similar to a ``flag day'' looming.  A
> line needs to be draw in the sand after which point any target (read x86
> and arm) that isn't using gdbarch will be obsoleted.  
> 
> That line should probably be called ``5.2''.

IMHO, this requires that a document be written explaining how to move
a target to multi-arch, with practical suggestions and examples.  I've
read what's available about this (several times), and I cannot say I
understand what needs to be done.
From ac131313@cygnus.com Fri Mar 23 09:30:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sources.redhat.com>
Subject: TODO vs bug data base
Date: Fri, 23 Mar 2001 09:30:00 -0000
Message-id: <3ABA1637.18A2EE1C@cygnus.com>
X-SW-Source: 2001-03/msg00253.html
Content-length: 505

Random thought for the day (and not original.  I happened to be talking
to a mozilla maintainer and they are already doing this).

Does the bug tracking database superseed the bulk of the TODO file?

I don't think the bug system can completly replace the TODO file - I'll
still expect to see it used to publically record GDB's release status
and file more generic TODO items.

As a corollary, should ``Fix:'' generally be reserved for ``fixes'' -
i.e. patches (Show me the money^D^D^D patch :-).

	Andrew
From aj@suse.de Fri Mar 23 09:30:00 2001
From: Andreas Jaeger <aj@suse.de>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jiri Smid <smid@suse.cz>, gdb@sources.redhat.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: Port to x86-64
Date: Fri, 23 Mar 2001 09:30:00 -0000
Message-id: <hon1aedyvy.fsf@gee.suse.de>
References: <s8v4rwosl3l.fsf@naga.suse.cz> <3AB8D41C.790A7B60@cygnus.com>
X-SW-Source: 2001-03/msg00254.html
Content-length: 1869

Andrew Cagney <ac131313@cygnus.com> writes:

> Jiri Smid wrote:
> > 
> >  Hello,
> > 
> > My name is Jiri Smid and I work for SuSE CR.
> > SuSE works on porting Linux to new 64-bit AMD processors.
> > I will work on port GDB.

If we do introductions here, let's continue: I'm one of the glibc
developers and port glibc to x86-64.  I might work in some parts
together with Jiri on gdb.

> This is good, really good - you've raised the flag early!
> 
> I can note/suggest the following:
> 
> 	o	get that assignment in order

I'll send assign.future and the company disclaimer to Jiri, I hope
that's all.  My papers are already ok, they've been filed last year.

> 		Remember, GDB can only accept the code
> 		if the copyright of the work is all
> 		in order.  It is best to start working
> 		on this one now so that you don't get
> 		hit with it at the end.
> 
> 		Part of this is ensuring that all
> 		people contributing to your GDB have
> 		a valid assignment in place.
> 
> 	o	submit the configury mess early
> 
> 		even if you don't have real code
> 		could I suggest thinking about
> 		separating this out so that
> 		you can get on with the real
> 		work.
> 
> 		This also avoids the age old
> 		problem of things going into
> 		a tail spin while people agree
> 		on the correct name :-)
> 
> 	o	Your code will need to use
> 		the multi-arch framework.
> 	o	You should watch out for
> 		the GNU coding standard.
> 		As they say, no pain, no gain :-)
> 
> I also wonder if you actually need a separate CVS repository and
> couldn't just live on a branch of the official GDB repository?  It
> should make merging a lot easier.

Working on a branch might be the better idea.  Shall Jiri send his ssh
key to you for setting this up?  Jiri, what do you prefer?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj
From ac131313@cygnus.com Fri Mar 23 09:30:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Andreas Jaeger <aj@suse.de>
Cc: Jiri Smid <smid@suse.cz>, gdb@sources.redhat.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: Port to x86-64
Date: Fri, 23 Mar 2001 09:30:00 -0000
Message-id: <3ABA1CD0.E44BD96B@cygnus.com>
References: <s8v4rwosl3l.fsf@naga.suse.cz> <3AB8D41C.790A7B60@cygnus.com> <hon1aedyvy.fsf@gee.suse.de>
X-SW-Source: 2001-03/msg00256.html
Content-length: 620

> Working on a branch might be the better idea.  Shall Jiri send his ssh
> key to you for setting this up?  Jiri, what do you prefer?

Just FYI, there is a bit of a dance to follow here.  To get access to
the CVS repository you need to do the following:

	o	have assignments et.al. in place

	o	have access to SSH

	o	demonstrate the ability
		to submit patches that follow
		both GDB's and the FSF conventions.

		I suggest starting with something
		small and mindless.

Among other things, this provides a mechanism through which new
contributors can publically and transparently establish their
credentials.

	Andrew
From bronson@trestle.com Fri Mar 23 09:30:00 2001
From: bronson@trestle.com (Scott Bronson)
To: gdb@sourceware.cygnus.com
Subject: Trapping system calls
Date: Fri, 23 Mar 2001 09:30:00 -0000
Message-id: <20010322105918.H16210@trestle.com>
X-SW-Source: 2001-03/msg00255.html
Content-length: 401

Is there any way to break into GDB when a particular system call
is made?  I want to trap every ioctl of a certain type.  Short
of scattering thousands of breakpoints throughout the code, I could
find no way of doing this.

In other words, I'm looking for the equivalent of "atb WaitNextEvent"
(if there are any other ex-Mac hackers out there :).

Am I missing the truly obvious?  Thanks,

	- Scott

Re: xfer_memory(..., attrib, ...) post mortem

[Andrew Cagney]

> I can't argue with anything you've said.  Whether it will work or not
> depends on our committent to execute the above plan.  I have no doubts
> about the first step, it's the second two that give me pause.  If the
> backwards compatible infrastructure "works" well enough, there is no
> incentive to complete the process.  When it comes to the decision to
> obsolete an target because no one has bothered to update to the new
> interfaces, we can't be swayed by the argument that we can't do that
> because the target is important.  IMO if it was really important, it 
> would have been kept up to date.

(Did I reply?)

Yes.  Ensuring that this happens could be politically tricky.  So far 
it's worked though - obsoleting targets has resulted in them being fixed.

To my amasement, that ARI table, has also turned out to be a useful tool 
in this task.  It lets me see what I should be atacking next.

	Andrew