Re: About unified debug register handling for i386 CPU.

[Chris Faylor <cgf@cygnus.com>]

On Wed, Sep 06, 2000 at 02:08:10AM -0400, Eli Zaretskii wrote:
>>   Remember also that the win32 API does not support 
>> hardware debug registers
>
>Really?  So you cannot have hardware-assisted debugging in Win32
>applications?

I am not aware of any way to do this with the Win32 debugging API
but I'd be thrilled to be proved wrong.

cgf
From msokolov@ivan.Harhan.ORG Wed Sep 06 12:45:00 2000
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: An article about the Cygnus tree
Date: Wed, 06 Sep 2000 12:45:00 -0000
Message-id: <0009061944.AA08064@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00065.html
Content-length: 4651

Joe Buck <jbuck@racerx.synopsys.com> wrote:

> I am starting to see the problem.  You are confusing several things
> together and mashing them into one concept that you are calling "the
> Cygnus tree".

No, I'm not confusing anything.

> But
> what you're failing to see is that this system was designed so that
> a GNU source directory can be made a subdirectory and then built *without
> changing it*.

No, I'm not failing to see this, I know this very well.

> Since you don't appreciate that, you falsely believe that
> a huge change had to be made to gcc to get it to build within this
> structure.

No, I know that there was no big change at that early stage. The big changes
came when the original non-Cygnus-tree GNU packages went away and the ones in
the Cygnus tree became the only ones remaining, at the same time undergoing a
transformation to become dependent on the top level and on other modules. This
was certainly much more significant for Binutils and GDB, but I'm arguing that
GCC is really no different.

I'm sorry that you've failed to see the whole point of my article, which is to
persuade the powers that be to merge the src and gcc repos. What's keeping GCC
in its own repo are the people on the GNU side of things who see it as
independent from the Cygnus tree. But what I'm arguing in my article is that
this perception of GCC's independence from the Cygnus tree by some GCC
maintainers is bogus. To become really independent, they would have to really
break all ties with the Cygnus tree, removing the top-level configure script
and Makefile that support the rest of the tree and taking away the single tree
build. I very seriously doubt that they'll be able to do that, unless they
commit the change anonymously so that the angry mob of embedded developers
using the single tree build doesn't get them, and if they are not going to do
that, they are still tied to the Cygnus tree whether they are in the main repo
with the master copies of the top-level files or using stale mirrors of those
files in their own repo, and everyone would benefit and no one would lose
anything from switching to the former.

> Concept #2 is the CVS archive that Cygnus (now Red Hat) makes releases
> from for their own customers.  This tree is *not* the same as the "net"
> version of gcc (or egcs before it).  In many cases, work that Cygnus did
> went to customers first and only later was merged into the egcs or GCC
> distribution.

I know that there are two Cygnus trees, one internal and one public, with the
former being very old and the latter not being complete yet because of
someone's reluctance to merge /cvs/src and /cvs/gcc on the Sourceware box. This
is explained in my article too, clearly enough I think. And I also know that
the differences between the two are generally kept to a minimum. Also don't
forget that before the public CVS repos were created, there were still public
daily or weekly snapshots. I can bet that those were made directly from the
trunk of Cygnus' internal repo, proving that it can't be too far away from what
the public is allowed to see. As for customer stuff, that's on branches, not on
the trunk, or so I've heard.

And still note the big problem with your wording. When you talk about the
public tree, you are again talking about a separate tree for GCC or EGCS rather
the a public version of the full Cygnus tree. *There is no separate GCC or EGCS
tree, other than as a nuisance to the developers and users in the two-repo
arrangement*. There is a public Cygnus tree now, in /cvs/src on the Sourceware
box, which closely mirrors the structure of the old internal tree and contains
all of its components that Cygnus was willing to make public, whether they are
used in GNU projects (like bfd, opcodes, etc) or are completely non-GNU (like
newlib, libgloss, winsup, etc). GCC is the only remaining exception, and I'm
doing everything I can to persuade the powers that be to realise that it's no
different from everyone else (including Binutils and GDB, which are just as GNU
but happily live in the unified public Cygnus tree) and to merge the src and
gcc repos.

Haven't you noticed lately that every change to the top level has to be
carefully applied to both /cvs/src and /cvs/gcc repos? If you have, how can you
still think of a separate GCC tree?

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)
From dje@watson.ibm.com Wed Sep 06 13:05:00 2000
From: David Edelsohn <dje@watson.ibm.com>
To: msokolov@ivan.Harhan.ORG (Michael Sokolov)
Cc: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: An article about the Cygnus tree 
Date: Wed, 06 Sep 2000 13:05:00 -0000
Message-id: <200009062005.QAA14472@mal-ach.watson.ibm.com>
References: <0009061944.AA08064@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00066.html
Content-length: 2009

>>>>> Michael Sokolov writes:

Michael> I'm sorry that you've failed to see the whole point of my article, which is to
Michael> persuade the powers that be to merge the src and gcc repos. What's keeping GCC
Michael> in its own repo are the people on the GNU side of things who see it as
Michael> independent from the Cygnus tree. But what I'm arguing in my article is that
Michael> this perception of GCC's independence from the Cygnus tree by some GCC
Michael> maintainers is bogus. To become really independent, they would have to really
Michael> break all ties with the Cygnus tree, removing the top-level configure script
Michael> and Makefile that support the rest of the tree and taking away the single tree
Michael> build. I very seriously doubt that they'll be able to do that, unless they
Michael> commit the change anonymously so that the angry mob of embedded developers
Michael> using the single tree build doesn't get them, and if they are not going to do
Michael> that, they are still tied to the Cygnus tree whether they are in the main repo
Michael> with the master copies of the top-level files or using stale mirrors of those
Michael> files in their own repo, and everyone would benefit and no one would lose
Michael> anything from switching to the former.

	No one sees the trees as independent and no one is trying to keep
the independent.  No one is arguing against merging the trees.  It simply
takes time and effort which no one has time to tackle at the moment.  The
only concern is being able to make a single, coordinated distribution in
the face of the different schedules of the various packages.  One still
can create a release branch and stabilize the various dependent components
in that branch for a particular package (gcc, binutils, gdb, etc.).

	I do not understand why you insist on looking for conspiracies and
attributing ulterior motives where there are none.  Have you ever heard of
"Occam's razor"?  If there is a simple explanation, it most likely is
correct.

David
From Stephane.Carrez@worldnet.fr Wed Sep 06 13:53:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb@sourceware.cygnus.com
Subject: Monitor support in machine -tdep.c file?
Date: Wed, 06 Sep 2000 13:53:00 -0000
Message-id: <39B6CBFB.9462A94E@worldnet.fr>
X-SW-Source: 2000-09/msg00067.html
Content-length: 1194

Hi!

I'm adding the support for Buffalo monitor for 68hc11 in Gdb (using the CME11E9
board from Axiom Manufacturing). I'm using the Gdb generic monitor framework.

Is it acceptable to put such monitor support in my m68hc11-tdep.c file?

For other monitors, it's true that a separate file is defined for each kind
of monitor.  But I would like to avoid introducing a new file in Gdb for
something that will always be there for 68hc11.

I understand that in the past the various monitors were selected based on
the configury stuff.  With the multi-arch, it seems to me we should always
have those monitors.  In that context, do we really need to separate the
monitor from the machine specific part? (most monitors are machine specific).

Thanks for any opinions about that,

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France
From mrs@windriver.com Wed Sep 06 17:49:00 2000
From: Mike Stump <mrs@windriver.com>
To: dje@watson.ibm.com, msokolov@ivan.Harhan.ORG
Cc: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: An article about the Cygnus tree
Date: Wed, 06 Sep 2000 17:49:00 -0000
Message-id: <200009070049.RAA21087@kankakee.wrs.com>
X-SW-Source: 2000-09/msg00068.html
Content-length: 797

> To: msokolov@ivan.Harhan.ORG (Michael Sokolov)
> Date: Wed, 06 Sep 2000 16:05:27 -0400
> From: David Edelsohn <dje@watson.ibm.com>

> No one is arguing against merging the trees.  It simply takes time
> and effort which no one has time to tackle at the moment.

Out of curiosity, would a sym link in the repo from src/gcc over to
egcs/gcc not fix the bulk of the problem?  If it does, could that be
done to sync most of the files, with very little effort?  It sounds
like if that were done, and a forced merge for include and maybe two
more symlinks for libiberty and include, that almost the entire
problem would be solved.  From there, new modules work and
rationalizing the toplevel files, and testing, and then sym link from
cvs/egcs over to cvs/src would drive it the rest of the way home.
From law@cygnus.com Wed Sep 06 17:54:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: Mike Stump <mrs@windriver.com>
Cc: dje@watson.ibm.com, msokolov@ivan.Harhan.ORG, binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: An article about the Cygnus tree 
Date: Wed, 06 Sep 2000 17:54:00 -0000
Message-id: <3145.968288162@upchuck>
References: <200009070049.RAA21087@kankakee.wrs.com>
X-SW-Source: 2000-09/msg00069.html
Content-length: 555

  In message < 200009070049.RAA21087@kankakee.wrs.com >you write:
  > > To: msokolov@ivan.Harhan.ORG (Michael Sokolov)
  > > Date: Wed, 06 Sep 2000 16:05:27 -0400
  > > From: David Edelsohn <dje@watson.ibm.com>
  > 
  > > No one is arguing against merging the trees.  It simply takes time
  > > and effort which no one has time to tackle at the moment.
  > 
  > Out of curiosity, would a sym link in the repo from src/gcc over to
  > egcs/gcc not fix the bulk of the problem?
Because CVS doesn't DTRT with symlinks.  At least that what I was
told.

jeff