From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Faylor To: gdb@sourceware.cygnus.com Subject: Re: About unified debug register handling for i386 CPU. Date: Wed, 06 Sep 2000 10:10:00 -0000 Message-id: <20000906130917.B13889@cygnus.com> References: <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl> <3.0.6.32.20000906001339.00b0ae90@idefix.wisa.be> <200009060608.CAA06709@indy.delorie.com> X-SW-Source: 2000-09/msg00064.html 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 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 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 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 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 > 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 To: Mike Stump 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 > > > 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