Re: An article about the Cygnus tree

Re: An article about the Cygnus tree

[Alexandre Oliva]

On Sep  6, 2000, Jeffrey A Law <law@cygnus.com> wrote:

> Because CVS doesn't DTRT with symlinks.  At least that what I was
> told.

I've never had any problem with symlinks of directories.  It indeed
doesn't work well with symlinks of files.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: An article about the Cygnus tree

[Russ.Shaw]

Its just that crossgcc traffic seems a bit on the low side
for some reason. BTW, is all this cross-posting bad? A
newsgroup is better suited for a wide range of questions
and seems more 'publicly accessible' for beginners to
ask all kinds of stupid questions.

Michael Sokolov wrote:
> 
> "Russ.Shaw" <russell@webaxs.net> wrote:
> 
> > I think there should be a newsgroup for the gnu tools etc, for applications
> > involving embedded systems. comp.arch.embedded is more hardware oriented.
> > What about a comp.gnu.embedded for all questions on installation, development,
> > use, and abuse of gnu/cygnus/open-source tools for embedded systems?
> 
> How is the crossgcc mailing list not enough for you for this purpose? That's
> exactly what it's for.

-- 
*******************************************
*   Russell Shaw, B.Eng, M.Eng(Research)  *
*      email: russell@webaxs.net          *
*      Victoria, Australia                *
*******************************************
From kettenis@wins.uva.nl Tue Sep 05 17:06:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 17:06:00 -0000
Message-id: <200009060006.e8606og01806@delius.kettenis.local>
References: <20000901192328.A28312@valinux.com> <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> <200009051546.LAA06234@indy.delorie.com>
X-SW-Source: 2000-09/msg00043.html
Content-length: 2540

   Date: Tue, 5 Sep 2000 11:46:48 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.com>

   > Date: Tue, 5 Sep 2000 15:33:54 +0200 (MET DST)
   > From: Mark Kettenis <kettenis@wins.uva.nl>
   > 
   > I was thinking of having some sort of register cache for the
   > debugging registers but didn't immedeately see the right solution to
   > do that.  Perhaps they should simply be added to the register cache?

   I think all we need is to store the debug registers somewhere.  They
   need to be accessed by (1) the x86-dependent code which is called by
   GDB's application level to insert and remove watchpoints; (2) the
   target-specific code which actually calls ptrace or the equivalent
   syscall to pass the values into the inferior's registers before
   resuming it, and set bits after the inferior stops to indicate which
   watchpoint(s) triggered; and (3) by stopped_by_watchpoint's target
   end.

   It's possible that the register cache is as good place as any to store
   DRi, even though they slightly differ from the rest of the registers.

Yep, and that's where I got distracted by more urgent problems :-(.

   > I also couldn't directly see how the hardware watchpoint supports
   > interacts with multiple threads

   Sorry, I'm not sure I see the problem.  Could you please elaborate?
   (I'm afraid I don't know much about Linux threads.)

Me neither :-(.  I'm not sure whether the debug registers are
per-thread or per-VM-space in Linux.  I'll probably need to look into
the kernel source.

   > especially in presence of the nifty way the go32 code maps multiple
   > waitchpoints on a single debugging register.

   I don't think this should matter.  The reference counts are just a
   means to know which register is used and which isn't.  As far as the
   higher-level GDB code is concerned, what's important is (a) which
   address, if any, triggered a watchpoint; and (b) which thread caused
   the watchpoint to trigger.

If you can set the debug registers per-thread, we might need a
reference count for every thread.  If the debug registers are
per-VM-space there might be a potential problem with finding out the
right triggering address for the right thread.

   However, if I'm missing the point, and there's some additional
   infrastructure that is required to make this work with multiple
   threads, please tell what is, or might be, missing.

It's something that needs to be investigated.  But since DJGPP doesn't
seem to support multiple threads I certainly don't expect you to do
that :-).

Mark
From shebs@apple.com Tue Sep 05 18:02:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: hjl@lucon.org, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 18:02:00 -0000
Message-id: <39B59772.F3E69072@apple.com>
References: <20000901192328.A28312@valinux.com> <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>
X-SW-Source: 2000-09/msg00044.html
Content-length: 1397

Eli Zaretskii wrote:
> 
> >   Date: Mon, 4 Sep 2000 23:32:22 -0700
> >   From: "H . J . Lu" <hjl@lucon.org>
> >
> >   If you can generalize it for ia32, I will implement it for Linux/ia32.
> 
> The code on go32-nat.c manipulates an array which represents the ia32
> debug registers, including the status and control registers.  It
> leaves it to resume() and its subroutines on the target end to
> actually insert the watchpoints when the inferior is resumed and
> remove them when the inferior stops and control is passed to GDB.
> 
> If this model suits most or all ia32 targets, pulling the code from
> go32-nat.c into a separate module (probably, as part of i386-nat.c)
> would be very easy for me.  If not, I'd ask the relevant maintainers
> to tell what provisions should I make for other platforms to fit in.
> 
> >   If it won't be fixed in 5.1, I will follow your hints and implement a
> >   Linux only solution when it happens to me again.
> 
> I can do this Very Soon (tm) provided that I hear a GO from The Powers
> That Be.  Andrew?  Stan?  What say you?

Uh, is there any reason not to?  We tell people that GDB can support
h/w watchpoints, seems like we ought to deliver it on our most popular
platforms.  Perhaps I could be evil and insist on adding a testsuite test
that would take 24 hours to run if h/w watchpoints don't work... think
that would help motivate anyone? :-)

Stan
From jason-swarelist@molenda.com Tue Sep 05 18:21:00 2000
From: Jason Molenda <jason-swarelist@molenda.com>
To: scottb@netwinder.org, hjl@lucon.org, nickc@redhat.com, gdb@sources.redhat.com
Subject: Re: src/ltcf-c.sh
Date: Tue, 05 Sep 2000 18:21:00 -0000
Message-id: <20000905182042.A7301@shell17.ba.best.com>
X-SW-Source: 2000-09/msg00045.html
Content-length: 1400

I haven't been following this thread, but...

scottb> Actually on further testing, it gets me the file on checkout, but not
scottb> on an update.

hjl> You have to use checkout on binutils and gdb.

It isn't all that horrible.  A 'checkout' will act like an update if the
tree is already populated by files.

If you normally do

 % cd /somewhere/src
 % cvs update

do this instead:

 % cd /somewhere
 % cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb
 % cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co binutils

and you'll see it pulling over only the new/updated files/directories
in to your tree.

It is a bit less efficient to use a checkout instead of an update.
The update will send deltas (patches) over the wire to update your
work area, whereas a checkout sends the files in their entirety.

In either case, compressing the cvs operation is always a good
idea. Add  the '-z9' command line option directly after 'cvs',
or put

  cvs -q -z9

in your $HOME/.cvsrc.


Jason

PS-  If you guys are talking about a file in the top-level directory,
then a checkout is not necessary, an update will pick it up.  The only
thing an update won't get you are newly created directories.  If an
update _isn't_ getting some file, I'd look over your CVS/Entries file
in that directory to see if there might be something in there that is
confusing cvs.  This behavior does not sound correct.
From shebs@apple.com Tue Sep 05 18:23:00 2000
From: Stan Shebs <shebs@apple.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, eliz@is.elta.co.il, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 18:23:00 -0000
Message-id: <39B59C92.37799057@apple.com>
References: <20000901192328.A28312@valinux.com> <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> <20000905084923.C15547@lucon.org>
X-SW-Source: 2000-09/msg00046.html
Content-length: 1625

"H . J . Lu" wrote:
> 
> On Tue, Sep 05, 2000 at 03:33:54PM +0200, Mark Kettenis wrote:
> >
> >    >   If it won't be fixed in 5.1, I will follow your hints and implement a
> >    >   Linux only solution when it happens to me again.
> >
> > A generic x86 solution would be preferable, but a clean, well
> > documented Linux-only solution is certainly welcome.
> 
> Given do it clean, do it fast and make it to work, you can only
> pick 2 if I am the only one to do it. Since I don't have much time
> to do it, I have to pick do it fast.

I feel like I should say something here - doing things fast for GNU/Linux
has been a continuing source of problems.  All this stuff is going
to take the same amount of time in the end, whether we kludge now and
rewrite over and over later, or do it right the first time.  GDB Linux
thread hacking has been going on for a couple years, and it's still not
quite done; if I had known it was going to take this long, I would
have taken a harder line about accepting the original expedient version.

If you don't think that you're getting enough time to do things right,
then you should take it up with your management.  Since VA Linux thinks
highly enough of you to feature your picture prominently in their Linux
World booth :-), you should have enough pull to say "this is how long
it needs to take".  If you supply me with names, I will be happy to
take it up with them myself too - VA Linux' business depends heavily on
its reputation for good Linux engineering, and I doubt they want to
become known as the company that is pushing hacky forked versions of GDB
out into the world.

Stan
From hjl@lucon.org Tue Sep 05 18:33:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Stan Shebs <shebs@apple.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, eliz@is.elta.co.il, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 18:33:00 -0000
Message-id: <20000905183312.A17823@lucon.org>
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> <20000905084923.C15547@lucon.org> <39B59C92.37799057@apple.com>
X-SW-Source: 2000-09/msg00047.html
Content-length: 763

On Tue, Sep 05, 2000 at 06:23:31PM -0700, Stan Shebs wrote:
> 
> If you don't think that you're getting enough time to do things right,
> then you should take it up with your management.  Since VA Linux thinks

The gdb work has nothing to do with my job at VA :-). I don't even
know they are aware of it. I only work on gdb because I don't want to
wait for a few hours when debugging the code nor start all over when
I use up all hardware registers. If it is a must-fix for gdb 5.1, I
am willing to pitch in. If noone else wants to spend time on it, I
will come up with some kludge for myself.

BTW, it has been a long standing problem for gdb. It seems that I
am the only one who thinks gdb sucks under Linux/ia32 and is willing
to do something about it.


H.J.
From jason@molenda.com Tue Sep 05 19:08:00 2000
From: Jason Molenda <jason@molenda.com>
To: scottb@netwinder.org, hjl@lucon.org, nickc@redhat.com, gdb@sources.redhat.com
Subject: Re: src/ltcf-c.sh
Date: Tue, 05 Sep 2000 19:08:00 -0000
Message-id: <20000905190824.A14877@shell17.ba.best.com>
References: <20000905182042.A7301@shell17.ba.best.com>
X-SW-Source: 2000-09/msg00048.html
Content-length: 971

I looked into this a bit (after sending my mail note saying there should
be no problem, of course :-).  I can reproduce Scott's reported problem.

An update with the an SSH or pserver access methods does not pick
up files added in the src/ directory.  I honestly don't know why.

It doesn't have anything to do with the modules file - that file
is only relevant at check-out time; after that, cvs knows nothing
of the module you checked out.

I poked around trying to figure out what is going on this this
directory, but failed (or rather, I have to get back to my real
work :-).  For what it's worth, though, this behavior we're seeing
with the top level of the /cvs/src directory is neither expected
nor correct.  Something is up with the RCS files here.  Or maybe
there is some odd case of cvs that I don't understand and it's
coming up here, but that's not as likely.

As people have suggested, check out binutils/gdb again from the top
level as a workaround.

Jason
From kevinb@cygnus.com Tue Sep 05 19:12:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: drepper@cygnus.com (Ulrich Drepper), Daniel Berlin <dan@cgsoftware.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, hjl@lucon.org, amylaar@cygnus.co.uk, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 05 Sep 2000 19:12:00 -0000
Message-id: <1000906021234.ZM22676@ocotillo.lan>
References: <Pine.LNX.4.21.0009041104140.3814-100000@propylaea.anduin.com> <m33djg81kh.fsf@otr.mynet.cygnus.com> <drepper@redhat.com>
X-SW-Source: 2000-09/msg00049.html
Content-length: 5036

On Sep 4, 11:16am, Ulrich Drepper wrote:

> > i forwarded them along to various gdb people, but the consensus was
> > that it didn't actually fix the real problem.
> 
> Well, then fix it correctly.  I'm using the patches for years without
> experiencing negative side effects.  Only with them is it possible to
> debug ld.so.

I took a look at these patches in late July in the hope that they
would fix some problems that I was seeing (on a not-to-be-named
platform) with relocating the main executable.  Below is a portion of
a message that I sent to one of the internal Red Hat lists concerning
Uli's solib.c patches.  In order to make sense of some of my comments,
it helps to know that I needed the read-only and read/write sections
to be relocated by different amounts.  This isn't terribly relevant
for the discussion at hand, but I think that any solution we come
up with needs to handle this case.  (My comments immediately preceding
Uli's patch *are* relevant though.)

......................................................................

I tried them and they didn't work for me.  There are several problems
with these patches for my situation:

    1)  The exec_bfd isn't marked DYNAMIC.  (But the OS is relocating
	it anyway; according to the ABI, this is okay.) Anyway, since
	it isn't marked DYNAMIC, Uli's code for relocating the symbols
	doesn't get a chance to run.

    2)  The stop_pc when this code is hit is at the _start symbol in
        the dynamic linker.  But I want to relocate the main executable
	whose _start symbol hasn't been hit yet.

    3)  Even if the preceding two problems could be reconciled, the
        .text and .data sections need to be relocated by different
	amounts.

[...]

I'm going to back out Uli's patch from my sandbox.  It didn't build
cleanly in my sandbox, so I'm posting below a cleaned up version which
does build.  We'll need to incorporate something like this into gdb at
some point.  Before we do though, I'd like to understand why the
changes to breakpoint.c are necessary.  Also, we need to consider the
situation where exec_bfd is not the dynamic linker, but is marked
DYNAMIC for some reason.  If this should happen, Uli's code will get
hit and the symbols in exec_bfd / symfile_objfile will get improperly
relocated.

Index: solib.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/solib.c,v
retrieving revision 1.146
diff -u -p -r1.146 solib.c
--- solib.c	2000/05/28 01:25:33	1.146
+++ solib.c	2000/07/26 17:50:36
@@ -54,6 +54,7 @@
 #include "environ.h"
 #include "language.h"
 #include "gdbcmd.h"
+#include "objfiles.h"
 
 #define MAX_PATH_SIZE 512	/* FIXME: Should be dynamic */
 
@@ -1984,6 +1985,39 @@ solib_create_inferior_hook ()
     {
       warning ("shared library handler failed to enable breakpoint");
       return;
+    }
+
+  if ((bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
+      && bfd_get_start_address (exec_bfd) != stop_pc)
+    {
+      /* We have to relocate the debug information.  */
+      static CORE_ADDR last_displacement;
+      CORE_ADDR displacement = stop_pc - exec_bfd->start_address;
+
+      if (last_displacement != displacement)
+	{
+	  CORE_ADDR correction = displacement - last_displacement;
+	  struct section_offsets *new_offsets;
+	  int i;
+
+	  new_offsets = alloca (symfile_objfile->num_sections
+				* sizeof (*new_offsets));
+
+	  for (i = 0; i < symfile_objfile->num_sections; ++i)
+	    ANOFFSET (new_offsets, i) =
+	      ANOFFSET (symfile_objfile->section_offsets, i);
+
+	  ANOFFSET (new_offsets, SECT_OFF_TEXT (symfile_objfile)) += displacement;
+	  ANOFFSET (new_offsets, SECT_OFF_DATA (symfile_objfile)) += displacement;
+	  ANOFFSET (new_offsets, SECT_OFF_BSS (symfile_objfile)) += displacement;
+	  ANOFFSET (new_offsets, SECT_OFF_RODATA (symfile_objfile)) += displacement;
+
+	  objfile_relocate (symfile_objfile, new_offsets);
+	  breakpoint_re_set ();
+
+	  /* Remember the current displacement.  */
+	  last_displacement = displacement;
+	}
     }
 
 #if !defined(SVR4_SHARED_LIBS) || defined(_SCO_DS)
Index: breakpoint.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/breakpoint.c,v
retrieving revision 1.294
diff -u -p -r1.294 breakpoint.c
--- breakpoint.c	2000/06/04 00:35:16	1.294
+++ breakpoint.c	2000/07/26 17:50:44
@@ -7108,6 +7108,7 @@ breakpoint_re_set_one (bint)
       return 0;
     case bp_breakpoint:
     case bp_hardware_breakpoint:
+    case bp_shlib_event:
     case bp_catch_load:
     case bp_catch_unload:
       if (b->addr_string == NULL)
@@ -7246,10 +7247,6 @@ breakpoint_re_set_one (bint)
 
       /* This breakpoint is special, it's set up when the inferior
          starts and we really don't want to touch it.  */
-    case bp_shlib_event:
-
-      /* Like bp_shlib_event, this breakpoint type is special.
-	 Once it is set up, we do not want to touch it.  */
     case bp_thread_event:
 
       /* Keep temporary breakpoints, which can be encountered when we step

Re: An article about the Cygnus tree

[Michael Sokolov]

David Edelsohn <dje@watson.ibm.com> wrote:

> I find your "Introduction to the Cygnus Tree" to be riddled with
> incorrect statements.  I do not understand why you apparently made no
> attempt to investigate the facts before publicly releasing a thoroughly
> inaccurate document.

I *did* investigate most of the facts. I have been watching these facts unfold
for a while now, I've been saving all the important bits of information about
this stuff I've come across in the past (even though I didn't need them then),
and I've done some CVS repo archaelogy. I did miss a few fine points, but you
could have certainly been a little more polite in pointing them out.

> Cygnus, as a company, never has been the official FSF-appointed
> maintainer of *ANY* GNU Project package.

I didn't say that they were FSF-appointed maintainers. That is politics that
I prefer to stay out of. I was and am focusing on the *technical* aspect of the
transition. First there were GNU packages with all their "meat" at the top
directory level. The Cygnus tree had versions of them grafted under the top-
level configure script and Makefile. What was so remarkable about the
transition from FSF's gcc2 to EGCS/GCC, and the much earlier transition in
Binutils and GDB that I, perhaps incorrectly, referred to as Cygnus takeover,
is that the FSF packages with the "meat" at the top directory level *went away*
and the version of the program in the Cygnus tree became the master one, with
all subsequent EGCS or FSF tarballs being made from the Cygnus tree and
carrying top-level configure scripts and Makefiles telling curious code readers
about the rest of the tree.

Also when I say "Cygnus tree", I'm not picking on them as a company. (And yes,
I know that they are Red Hat now.) I call it the Cygnus tree for exactly the
same reason why the configure script at its top is universally known as Cygnus
configure and called this way by everyone, and why the Automake option enabling
special rules for this tree is named cygnus. In fact, I took the name Cygnus
tree from configure.texi, before I read that I didn't know how to call it.

And while I think this is stated clearly enough in the article itself, let me
repeat: the previous point (that I wasn't even sure what to call it) is the
essense of the problem that needs a solution: there is a sore lack of public
tutorial information on this animal. There is a home for the GNU project and
there are home pages for all GNU projects, and as a result, everyone knows what
they are and where to get them. But it's very hard to explain to a newcomer
what the Cygnus tree is. See below.

> Daily and weekly snapshots of
> the various packages (gcc, gas, gdb, and binutils) were available to all
> active developers prior to the public CVS repositories;

I know this, and I never said otherwise.

> The hosting of the gcc.gnu.org site by Cygnus/Red Hat is not a
> "dirty little secret".

When writing that, I assumed that everyone reading those words would understand
them as tongue-in-cheek. Your reaction shows that I was wrong. Sorry 'bout
that. That and all the language about "conspiracies" was intended to convey
that the lack of a home for the tree overall, as opposed to its individual
modules, makes it look like a conspiracy. *Of course* I know that everyone
working on this code is extremely devoted to free software and that there are
no conspiracies. I was pointing it out that there is a problem with not having
a home for the unified Cygnus tree and that it makes it look like a conspiracy.

> Whatever ax you have to grind [...]

I don't have any axes to grind, and I'm very sorry that you have so completely
misinterpreted my article. I really don't think I could have made any clearer:
in the article itself I have clearly stated more than once why I wrote it and
what I'm trying to achieve.

I think I have explained it as well as it could be in the article, so repeating
it here would be just wasting bandwidth, but let me repeat it very briefly. I
have projects that use the Cygnus tree instead of discrete releases from
ftp.gnu.org. These projects have found it unacceptable to build bfd and opcodes
twice and libiberty three times. I, being a developer and knowing the "secrets"
(tongue-in-cheek) which most developers know but which are not written down in
ASCII anywhere, have no problem with this and have found the compilation time
reduction and ease of development tracking very pleasant. But right now I'm in
the process of preparing a release, and this is where I hit a problem. It's
trivial to tell your users "this system uses GCC, Binutils, and GDB, go get
them". But it's infinitely harder to tell them that a system uses the Cygnus
tree, given that there is no home for it where people can learn what it is,
that there is no single repository to get it from, and that a lot people don't
even know that such a thing exists (been there myself).

First all I wanted to do was to explain the procedure for piecing together the
tree from the two repos. But before I even got there, I at least had to say
*what* does one need to build. I needed to refer to the Cygnus tree. It's
trivial to say "this system uses GCC" and point to its WWW page. But for the
Cygnus tree there isn't any. In Free Software when you need something that does
not exist, you create it. This is exactly what I did in writing my article. And
of course after having explained the horrible procedure for piecing together
the tree when the correct solution (repo unification) is obvious, it was only
proper to make a call for action to actually implement this correct solution.

> [...] before you start patting yourself on the back for getting
> things rolling.

I was never planning on doing that actually.

Anyway, I have checked in version 1.4 of cygnus-tree-intro with the language
changed so that hopefully fewer people will get offended by it and more people
will gain useful insight from it, which was its original intent. It is in
ivan.Harhan.ORG:/pub/embedded/cygnus-tree-intro.

--
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 jbuck@racerx.synopsys.com Mon Sep 04 21:24:00 2000
From: Joe Buck <jbuck@racerx.synopsys.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: Mon, 04 Sep 2000 21:24:00 -0000
Message-id: <200009050423.VAA26546@racerx.synopsys.com>
References: <0009050030.AA26952@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00023.html
Content-length: 1327

> OK, I checked this in:

> ! was a public project and competed with FSF's gcc project. Finally, in spring
> ! 1999 FSF closed their gcc project and EGCS was renamed into GCC.

Still wrong.  The FSF never "closed their gcc project".  This *is* the gcc
project.  Same people for the most part, same code base.  We were always
careful with egcs to do things in a way that would prevent a permanent
fork.  What we were doing, in essence, was to demonstrate to the FSF that
there was a better way of doing things.  It is difficult to do these
things without offending people; there were some very sensitive politics
involved.  But the end result has been a great success.

What happened in April 1999 was that the 2.8.x and egcs lines of
development were merged and the egcs maintainers were given charge of the
whole project.  The current way of working is more in line with FSF
principles than what we had before (restricting who can get snapshots
seems at least to violate the spirit of the GPL, even if it is technically
allowed).

> BTW, what did EGCS stand for?

eggs.  (hence the logo).  Actually there were several suggested meanings
for the "E": "experimental" was the most common one, and it was presented
to RMS as an experiment.  He was kept informed and gave his sometimes
grudging approval for the major decisions.

Re: An article about the Cygnus tree

[Russ.Shaw]

I think there should be a newsgroup for the gnu tools etc, for applications
involving embedded systems. comp.arch.embedded is more hardware oriented.
What about a comp.gnu.embedded for all questions on installation, development,
use, and abuse of gnu/cygnus/open-source tools for embedded systems?


Michael Sokolov wrote:
> 
> And while I think this is stated clearly enough in the article itself, let me
> repeat: the previous point (that I wasn't even sure what to call it) is the
> essense of the problem that needs a solution: there is a sore lack of public
> tutorial information on this animal. There is a home for the GNU project and
> there are home pages for all GNU projects, and as a result, everyone knows what
> they are and where to get them. But it's very hard to explain to a newcomer
> what the Cygnus tree is. See below.
> 

-- 
*******************************************
*   Russell Shaw, B.Eng, M.Eng(Research)  *
*      email: russell@webaxs.net          *
*      Victoria, Australia                *
*******************************************
From eliz@delorie.com Mon Sep 04 22:49:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Mon, 04 Sep 2000 22:49:00 -0000
Message-id: <200009050548.BAA05890@indy.delorie.com>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org>
X-SW-Source: 2000-09/msg00025.html
Content-length: 1721

> 
> Date: Mon, 4 Sep 2000 16:44:58 -0700
> From: "H . J . Lu" <hjl@lucon.org>
> 
> 1. Delete hardware watchpoints to free hardware debug registers. Set 4
> hardware watchpoints. Then delete/disable one hardware watchpoint. Set
> another hardware watchpoint. Can gdb free a hardware debug register
> when I delete/disable the hardware watchpoint which uses it?
> 2. Watch for different values on a viariable with one hardware debug
> register. That is do
> 
> (gdb) watch foobar == 1
> (gdb) watch foobar == 2
> (gdb) watch foobar == 3
> (gdb) watch foobar == 4
> (gdb) watch foobar == 5
> 
> only using one hardware debug register.
> 
> I have reported them long before 5.0 was released. But at least #1
> still doesn't work right in 5.0 under Linux/ia32.

These are not GDB/ia32 issues per se: the above features are all
implemented in the DJGPP port of GDB and work in v5.0.  Every
x86-based target should be able to lift the relevant parts of
go32-nat.c and use them almost verbatim.  You get debug register
sharing through reference counts, and the ability to watch large
regions (up to 16 bytes) using multiple registers.  (The required
infrastructure in high-level GDB application code, mostly in
breakpoint.c, is also working since v5.0.)

What is missing is something that we discussed here some time ago: a
unified handling for debug registers common for ALL ia32 targets.  If
you want to get this done before 5.1 is out, I'm for it.  I said in
the past that I'm willing to volunteer to pull the code out of
go32-nat.c and generalize it as appropriate, as the first step towards
this goal.  Provided that it's decided to do that for 5.1, of course
(otherwise, I have too many other important things to do ;-).

Re: An article about the Cygnus tree

[Michael Sokolov]

David Edelsohn <dje@watson.ibm.com> wrote:

> I do not understand why you incorrectly insist on using such
> hostile and confrontational language in your description of EGCS.

I certainly didn't mean to be hostile or confrontational to the former EGCS. If
something in my description of it appears hostile or confrontational to you,
please point it out, also indicating how you would like it to be different (in
diff -c format).

Now you may find hostile or confrontational my criticism of first EGCS' and now
GCC's reluctance to move to the unified tree, but I think it's fair criticism.

Sorry guys for hurting your feelings if I did. I didn't intend to. I just want
the unified tree to become a reality, and in the current state of affairs there
isn't even a site or a mailing list for the Cygnus tree overall, necessitating
something like my article to be written to get the ball rolling.

--
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 Mon Sep 04 19:19: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: Mon, 04 Sep 2000 19:19:00 -0000
Message-id: <200009050218.WAA22284@mal-ach.watson.ibm.com>
References: <0009050114.AA27252@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00019.html
Content-length: 1774

	I find your "Introduction to the Cygnus Tree" to be riddled with
incorrect statements.  I do not understand why you apparently made no
attempt to investigate the facts before publicly releasing a thoroughly
inaccurate document.

	Cygnus, as a company, never has been the official FSF-appointed
maintainer of *ANY* GNU Project package.  Daily and weekly snapshots of
the various packages (gcc, gas, gdb, and binutils) were available to all
active developers prior to the public CVS repositories; they were not
developed solely by Cygnus or the FSF behind closed doors.  EGCS was not
run by Cygnus and characterizing it as competition with FSF's gcc project
is just one of numerous places where the description is far from
objective.  The hosting of the gcc.gnu.org site by Cygnus/Red Hat is not a
"dirty little secret".

	Whatever ax you have to grind, I would appreciate if you would
take it elsewhere instead of applying your prism to everyone else.  I
personally find your terminology and inferences highly offensive.
Spreading this sort of disinformation does not help the Free Software
Movement or help encourage a unified source tree and CVS repository for
GNU toolchain packages.

	The various maintainers and steering committees are not composed
of public relations experts, so we probably have been less communicative
and less quick to refute incorrect rumours than we should have been.
Filling in the missing information with conspiracies and accepting the
negative rumours is a normal human instinct, but easily resolved with a
little bit of investigation before producing a draft document.  I would
appreciate if you would demonstrate some comprehension and productive
involvement before you start patting yourself on the back for getting
things rolling.

David
From kettenis@wins.uva.nl Mon Sep 04 21:04:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jjenkins@jetstream.com
Cc: jjenkins@jetstream.com, gdb@sourceware.cygnus.com
Subject: Re: Real-Time signals & GDB
Date: Mon, 04 Sep 2000 21:04:00 -0000
Message-id: <200009050403.e8543uU01262@delius.kettenis.local>
References: <27A2DAA6CAD9D311BF970050DACB2250013E571F@mail.jetstream.com>
X-SW-Source: 2000-09/msg00020.html
Content-length: 190

   From: Jeff Jenkins <jjenkins@jetstream.com>
   Date: Mon, 4 Sep 2000 17:53:34 -0700 

   I am using gdb 4.18 on Solaris 7/SPARC UltraIII.

Try 5.0 (if you can get it to compile).  

Mark
From aoliva@redhat.com Mon Sep 04 21:06:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: Jan Dvorak <johnydog@go.cz>
Cc: Michael Sokolov <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: Mon, 04 Sep 2000 21:06:00 -0000
Message-id: <orzolnh49r.fsf@guarana.lsd.ic.unicamp.br>
References: <0009050030.AA26952@ivan.Harhan.ORG> <20000905031308.A853@napalm.go.cz>
X-SW-Source: 2000-09/msg00021.html
Content-length: 621

On Sep  4, 2000, Jan Dvorak <johnydog@go.cz> wrote:

> On Mon, Sep 04, 2000 at 07:30:59PM -0500, Michael Sokolov wrote:
>> BTW, what did EGCS stand for?

> EGCS stands for Extended GNU Compiler System

AFAIK, the E in EGCS could also stand for Experimental and Enhanced,
depending on the reader.  There was no official wording :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me