Re: gdb doesn't work very well with dynamic linked binaries

Re: gdb doesn't work very well with dynamic linked binaries

[James Cownie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

This threads seems really to have morphed to be about using the
hardware watchpoint registers on IA32.

So :-

Note that there are a couple of linux kernel bugs in 2.2 (one of which
was fixed in 2.2.17) which affect the use of the debug registers.

The first bug (which was fixed in 2.2.17) was that the debug status
register wasn't being saved where it could be seen by ptrace, so if
you were relying on looking at the hardware status register you were
stuffed.

The second (which isn't yet fixed) I described with a test case in a
previous mail here. ( http://sources.redhat.com/ml/gdb/2000-08/msg00072.html )
Basically the kernel ignores all hardware
watchpoints from the point where one of them is triggered inside the
kernel until a reschedule. This means many watchpoints at user level
can be silently skipped :-(

AFAICS both bugs remain in 2.4.0-test7.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com



-- 
-- Jim
James Cownie
jcownie@etnus.com
Etnus, Inc.
Phone +44 117 9071438
From mdeans@algonet.se Wed Sep 06 04:13:00 2000
From: "Bjorn Eriksson" <mdeans@algonet.se>
To: "Russ.Shaw" <russell@webaxs.net>, "Michael Sokolov" <msokolov@ivan.Harhan.ORG>
Cc: <binutils@sources.redhat.com>, <crossgcc@sources.redhat.com>, <gcc@gcc.gnu.org>, <gdb@sources.redhat.com>
Subject: comp.gnu.embedded (was: embedded An article about the Cygnus tree)
Date: Wed, 06 Sep 2000 04:13:00 -0000
Message-id: <000001c017f3$5c69c020$0800a8c0@win95.inteloop.se>
References: <39B57E79.EADD4317@webaxs.net>
X-SW-Source: 2000-09/msg00059.html
Content-length: 1007

> > > 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.
>
> 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.

 I hope you haven't missed linux-embedded@waste.org. I'd also like to see a
comp.gnu.embedded newsgroup but not for the reason you stated. I like to
think we're all trying to help out anyone who spends time and effort to
research his problem and write coherent questions.


//Björnen.

Re: gdb doesn't work very well with dynamic linked binaries

[Peter.Schauer]

>    The bug I mentioned previously is exactly that they're getting
>    cleared by the kernel and then not getting restored on return
>    to user space, leaving them wrong until the next reschedule :-(
> 
> I think I understand the problems now.  It basically means that one
> cannot reliably watch area's that are somehow used in system calls.
> 
> I suspect that Linux isn't the only kernel with this bug.  AFAICS
> FreeBSD also simply disables any (user-space) watchpoints triggered
> from within the kernel.  I don't know what the various x86 System V's
> (Solaris, SCO Open Server 5) do, but I wouldn't be surprised if it is
> broken there too.

AFAIK Solaris never provided access to the x86 debug registers.
Starting with Solaris 2.6, support for hardware watchpoints is provided
via procfs (protect pages which contain watchpoint areas, examine address
on pagefault, cause breakpoint if address is within watchpoint area).

Perhaps this scheme (which allows for an arbitrary number of watchpoints)
could be adopted by the Linux kernel.

Debug register access might be valuable for embedded targets, but the
generic x86 target should not assume availability of debug register access.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From gkarabin@pobox.com Sat Sep 09 16:16:00 2000
From: George Karabin <gkarabin@pobox.com>
To: gdb@sourceware.cygnus.com
Subject: Multi-Ice server?
Date: Sat, 09 Sep 2000 16:16:00 -0000
Message-id: <39BAC4C0.56EDC24@pobox.com>
X-SW-Source: 2000-09/msg00095.html
Content-length: 524

It's my understanding that gdb can interface to a Multi-Ice server
running on Windows by using the "multi-ice-gdb-server", which wraps
around the actual Multi-Ice server that ARM distributes.

Has anyone looked into developing a replacement for ARM's Multi-Ice
server, or talked to ARM about releasing the source for theirs? I'd
really like to have the option of doing all of my ARM development on
Linux, but the need to have a Windows box to interface to the Multi-Ice
box itself is both kludgy and a waste of resources.

Re: gdb doesn't work very well with dynamic linked binaries

[H . J . Lu]

On Tue, Sep 05, 2000 at 01:48:56AM -0400, Eli Zaretskii wrote:
> > 
> > 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 ;-).
> 

If you can generalize it for ia32, I will implement it for Linux/ia32.
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. It is just one of
those things which makes me to roll my own stuff. Hardware watchpoints
have been known to be broken on Linux/ia32 for a long time and nothing
has been done to it.


H.J.
From eliz@delorie.com Tue Sep 05 03:36: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: Tue, 05 Sep 2000 03:36:00 -0000
Message-id: <200009051035.GAA06054@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> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org>
X-SW-Source: 2000-09/msg00027.html
Content-length: 1581

>   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?

>   Hardware watchpoints
>   have been known to be broken on Linux/ia32 for a long time and nothing
>   has been done to it.

That's not 100% true: a few important patches related to watchpoints
went into mainstream sources (mainly in breakpoint.c) in preparation
for v5.0.  This is the infrastructure I was talking about in my
previous message; without those patches the watchpoint support in
go32-nat.c could not work reliably.  (IIRC, a major part of these
patches were resubmitted by me and approved by Michael Snyder as a
result of a discussion in which you participated.)
From gnalle@dirac.ruc.dk Tue Sep 05 03:56:00 2000
From: Niels L Ellegaard <gnalle@dirac.ruc.dk>
To: gdb@sourceware.cygnus.com
Subject: gdb + egcs: break __raise_exception
Date: Tue, 05 Sep 2000 03:56:00 -0000
Message-id: <7wr96zt9fu.fsf@dirac.ruc.dk>
X-SW-Source: 2000-09/msg00028.html
Content-length: 928

I am using gdb to debug a program compiled by egcs-2.91.66, and I
would like to do the following:

   To make the debugger catch all exceptions before any stack unwinding
   takes place, set a breakpoint on __raise_exception (see section
   Breakpoints, watchpoints, and exceptions).

I can easily break at other functions, but when I try to break at
__raise_exception I get the following problem:

   (gdb) break __raise_exception
   Function "__raise_exception" not defined.

I would be most greatful for any help.

btw::~> gdb -version
GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
....
This GDB was configured as "i486-pc-linux-gnu".

-- 
Niels L Ellegaard  http://dirac.ruc.dk/~gnalle/
SPECIAL OFFER! I proofread unsolicited commercial email sent to this
address at a rate of US $500.00 per incident!  Include billing address
in your message and save US $500.00 per hour off ordinary address
resolution and tracking charge!
From kettenis@wins.uva.nl Tue Sep 05 06:34: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 06:34:00 -0000
Message-id: <200009051333.e85DXsv12272@debye.wins.uva.nl>
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/msg00029.html
Content-length: 2232

   Date: Tue, 5 Sep 2000 06:35:52 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.com>

   >   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.

I looked into the the hardware watchpoint support some time ago, and
actually started coding, seperating the generic bits out of the go32
code.  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 also couldn't directly see how the hardware watchpoint supports
interacts with multiple threads, especially in presence of the nifty
way the go32 code maps multiple waitchpoints on a single debugging
register.

In principle I see no reason why x86 hardware waitchpoints couldn't be
implemented by i386-tdep.c though.

   >   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.

   I can do this Very Soon (tm) provided that I hear a GO from The Powers
   That Be.  Andrew?  Stan?  What say you?

   >   Hardware watchpoints
   >   have been known to be broken on Linux/ia32 for a long time and nothing
   >   has been done to it.

Apparently nobody cares enough.  It isn't at the top of my priority
list so if nobody else contributes the necessary code, it probably
won't happen in the near future.

Mark
From kettenis@wins.uva.nl Tue Sep 05 07:41:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gnalle@dirac.ruc.dk
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb + egcs: break __raise_exception
Date: Tue, 05 Sep 2000 07:41:00 -0000
Message-id: <200009051441.e85Efuh12357@debye.wins.uva.nl>
References: <7wr96zt9fu.fsf@dirac.ruc.dk>
X-SW-Source: 2000-09/msg00030.html
Content-length: 794

   From: Niels L Ellegaard <gnalle@dirac.ruc.dk>
   Date: 05 Sep 2000 12:33:25 +0200

   I am using gdb to debug a program compiled by egcs-2.91.66, and I
   would like to do the following:

      To make the debugger catch all exceptions before any stack unwinding
      takes place, set a breakpoint on __raise_exception (see section
      Breakpoints, watchpoints, and exceptions).

   I can easily break at other functions, but when I try to break at
   __raise_exception I get the following problem:

      (gdb) break __raise_exception
      Function "__raise_exception" not defined.

   I would be most greatful for any help.

GDB cannot find the symbol "__raise_exception" in the executable.  Did
you verify (for example with `nm') that the executable does contain
such a symbol?

Mark
From hjl@lucon.org Tue Sep 05 08:44:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: 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 08:44:00 -0000
Message-id: <20000905084429.B15547@lucon.org>
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/msg00031.html
Content-length: 1747

On Tue, Sep 05, 2000 at 06:35:52AM -0400, 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?

I will vote for fixing it in 5.1. I will do the Linux work since I
brought it up. It has been broken for too long. There is no excuse
not to fix it given that at least 2 people are willing to do it.

> 
> >   Hardware watchpoints
> >   have been known to be broken on Linux/ia32 for a long time and nothing
> >   has been done to it.
> 
> That's not 100% true: a few important patches related to watchpoints
> went into mainstream sources (mainly in breakpoint.c) in preparation

Sorry for the misunderstanding. Thanks for your work on breakpoints.
It is just that hardware watchpoints under Linux/ia32 are as broken
as before :-).


H.J.
From eliz@delorie.com Tue Sep 05 08:47:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
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 08:47:00 -0000
Message-id: <200009051546.LAA06234@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> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl>
X-SW-Source: 2000-09/msg00032.html
Content-length: 2140

> 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.

> 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.)

> 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.

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.

> Apparently nobody cares enough.  It isn't at the top of my priority
> list so if nobody else contributes the necessary code, it probably
> won't happen in the near future.

If v5.1 freeze date is far away, and if the current code in go32-nat.c
is good enough to be used by other x86 platforms, I might take the
silence as a sign of agreement, given the fact that making it happen
is easy... ;-)
From hjl@lucon.org Tue Sep 05 08:49:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: 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 08:49:00 -0000
Message-id: <20000905084923.C15547@lucon.org>
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>
X-SW-Source: 2000-09/msg00033.html
Content-length: 1070

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 can do this Very Soon (tm) provided that I hear a GO from The Powers
>    That Be.  Andrew?  Stan?  What say you?
> 
>    >   Hardware watchpoints
>    >   have been known to be broken on Linux/ia32 for a long time and nothing
>    >   has been done to it.
> 
> Apparently nobody cares enough.  It isn't at the top of my priority
> list so if nobody else contributes the necessary code, it probably
> won't happen in the near future.

It has to be fixed in 5.1, one way or the other. The worst case is
I will make my kludge available to the Linux community.


H.J.
From msokolov@ivan.Harhan.ORG Tue Sep 05 10:44: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: Tue, 05 Sep 2000 10:44:00 -0000
Message-id: <0009051743.AA01913@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00034.html
Content-length: 2896

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

> Still wrong.  The FSF never "closed their gcc project".  This *is* the gcc
> project.  Same people for the most part, same code base.

Not quite. Yes, politically it's the same project, has many of the same people,
and the core code is a version of the same thing. But this is not what my
article is about. My article is about the Cygnus tree, the top-level
architecture, and the fact that all these projects are now dependent on the
tree architecture and belong in the single unified repo. The old gcc which had
all the actual gcc code at the top directory level and no libiberty *is* dead.
The other, once forked, GCC that has the Cygnus configure script at the top
directory level is the only one remaining. That was my whole point.

> > BTW, what did EGCS stand for?
>
> eggs.

I've checked in this:

------- cygnus-tree-intro -------
*** /tmp/d01094	Tue Sep  5 11:28:02 2000
--- cygnus-tree-intro	Tue Sep  5 11:10:11 2000
***************
*** 42,52 ****
  its development, so Cygnus didn't take over its development by itself. First
  they synchronised their work on it (in their internal Cygnus tree) with the FSF
  maintainers. Then in August 1997 they created an open development project for
! it which they named EGCS (Extended GNU Compiler System). It was a public
! project and for a period of time, for better or worse, was in competition with
! FSF's gcc project. In spring 1999 FSF closed their gcc project and EGCS was
! renamed into GCC. At the same time GCC was changed to mean GNU Compiler
! Collection instead of GNU C Compiler.
  
  All these programs have been integrated into the Cygnus tree so completely that
  they no longer exist separately from it. Moreover, some of these programs are
--- 42,52 ----
  its development, so Cygnus didn't take over its development by itself. First
  they synchronised their work on it (in their internal Cygnus tree) with the FSF
  maintainers. Then in August 1997 they created an open development project for
! it which they named EGCS (eggs, just like the ones Americans eat for breakfast
! :-). It was a public project and for a period of time, for better or worse, was
! in competition with FSF's gcc project. In April 1999 FSF closed their gcc
! project and EGCS was renamed into GCC. At the same time GCC was changed to mean
! GNU Compiler Collection instead of GNU C Compiler.
  
  All these programs have been integrated into the Cygnus tree so completely that
  they no longer exist separately from it. Moreover, some of these programs are

--
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 msokolov@ivan.Harhan.ORG Tue Sep 05 10:54: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: Tue, 05 Sep 2000 10:54:00 -0000
Message-id: <0009051753.AA02054@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00035.html
Content-length: 1110

"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.

But what my article calls for is quite different. Here I'm concerned mostly
with the *core developers*. I'm calling for the /cvs/src and /cvs/gcc repos on
Sourceware to be merged and for creating a home for the Cygnus tree concerned
with its core development and maintenance, rather than "abuse" you are talking
about.

--
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 nickc@redhat.com Tue Sep 05 11:58:00 2000
From: Nick Clifton <nickc@redhat.com>
To: scottb@netwinder.org
Cc: gdb@sources.redhat.com, ac131313@cygnus.com
Subject: Re: src/ltcf-c.sh
Date: Tue, 05 Sep 2000 11:58:00 -0000
Message-id: <200009051858.LAA02214@elmo.cygnus.com>
X-SW-Source: 2000-09/msg00036.html
Content-length: 903

Hi Scott,

: The autobuild at netwinder.org fails with the following error:
: 
: /home/build-rpm/BUILD/gdb/opcodes/../ltconfig:
: /home/build-rpm/BUILD/gdb/opcodes/../ltcf-c.sh: No such file or directory
: configure: error: libtool configure failed
: Configure in /home/build-rpm/BUILD/obj-gdb-20000904/opcodes failed, exiting.
: Bad exit status from /var/tmp/rpm-tmp.88907 (%build)
: 
: The problem is a cvs checkout of gdb is not updating this file.  It isn't
: there so the build fails.  I had a look at the modules file, and it is
: included in the alias src-support, which is included in gdb-support which is
: used by the gdb module.  If I update my binutils tree, and my insight trees
: the file is not checked out, though I expect it to be.  If I check it out
: manually by cvs co ltcf-c.sh, it works.
: 
: Any ideas?

Strange.  It seems to work for us.  Maybe this is a CVS bug ?

Cheers
	Nick
From jbuck@racerx.synopsys.com Tue Sep 05 12:01: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: Tue, 05 Sep 2000 12:01:00 -0000
Message-id: <200009051859.LAA04233@racerx.synopsys.com>
References: <0009051743.AA01913@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00037.html
Content-length: 2141

> 
> Joe Buck <jbuck@racerx.synopsys.com> wrote:
> 
> > Still wrong.  The FSF never "closed their gcc project".  This *is* the gcc
> > project.  Same people for the most part, same code base.
> 
> Not quite. Yes, politically it's the same project, has many of the same people,
> and the core code is a version of the same thing. But this is not what my
> article is about. My article is about the Cygnus tree, the top-level
> architecture, and the fact that all these projects are now dependent on the
> tree architecture and belong in the single unified repo.

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".

Concept #1 is the software architecture that allows for a top-level
makefile with tools placed underneath that top level that can be built
all in one step.  Yes, this was invented by folks at Cygnus.  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*.  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.  Not at all: it just drops in.  The Cygnus folks had to do
it that way to work and play successfully with GNU maintainers that did
not use the structure.

Similarly, we noticed in the early days of egcs that the makeinfo sources
were a lot smaller than the .info files, so we decided to include the
source in the distribution (maybe not the greatest decision).  It was not
necessary to change texinfo/makeinfo to do this.

Because you make this mistake, you think that gcc underwent a larger
technical change than it did.  In fact, you appear to believe that this
was a revolution or something.  Surprise: it is no big deal.

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.

Re: gdb doesn't work very well with dynamic linked binaries

[Ulrich Drepper]

Daniel Berlin <dan@cgsoftware.com> writes:

> If they were the same ones he sent me,

They are

> 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.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
From msokolov@ivan.Harhan.ORG Mon Sep 04 14:21: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: An article about the Cygnus tree
Date: Mon, 04 Sep 2000 14:21:00 -0000
Message-id: <0009042120.AA26535@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00009.html
Content-length: 23571

Hi there,

In light of the question of merging the src and gcc repos recently raised again
in a thread on the GCC list about adding zlib to GCC, I've written an article
about the Cygnus tree. It appears below. I hope it will start a better
discussion about merging the repos and breaking the code of silence around the
Cygnus tree.

This article also appears on my FTP site in /pub/embedded/cygnus-tree-intro on
ivan.Harhan.ORG. Whenever I release a toolchain for one of the embedded systems
I'm working with based on the Cygnus tree, I have to explain to my users what
it is, given its obscurity. Now I can just refer them to my article.

Enjoy!

--
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)

Here is the article:

			An Introduction to the Cygnus Tree

				By Michael Sokolov
			International Free Computing Task Force

			@(#)cygnus-tree-intro	1.1	00/09/04


			1. What is the Cygnus tree?

"The GNU configure and build system" by Ian Lance Taylor gives the following
answer:

	The Cygnus tree is used for various packages including gdb, the GNU
	binutils, and egcs.  It is also, of course, used for Cygnus releases.
	It is the build system which was developed at Cygnus, using the Cygnus
	configure script.  It permits building many different packages with a
	single configure and make.  The configure scripts in the tree are being
	converted to autoconf, but the general build structure remains intact.

During the 1990s Cygnus Solutions (now part of Red Hat, Inc.) has created a
remarkable system that is usually called the Cygnus tree. They have taken many
GNU programs (which were all designed as completely self-contained stand-alone
packages), most importantly the ones used for software development (gcc, gas,
binutils, and gdb) and unified them into one source tree with a single top-
level configure script and a single top-level Makefile. This allows all these
packages to be configured, built, and installed together in one fell swoop.

Initially, the Cygnus tree existed inside Cygnus only and was distributed only
to their customers. At that point, most of the GNU programs were simply grafted
into the tree with no changes of much interest to people outside of Cygnus.
These programs existed and were completely public in their original GNU form,
and the Cygnus tree was just a fancy packaging option of not much interest to
people outside of Cygnus. Therefore, there was no pressure for a public Cygnus
tree.

However, as time went on, it turned out that Cygnus was the best and most
active contributor to some of the GNU programs involved. As a result, they have
taken over the maintenance of those programs and changed and enhanced them
significantly. These GNU programs were gcc, gas, binutils, and gdb. Cygnus took
over the maintenance of gas, binutils, and gdb back in early-mid 1990s, doing
development behind closed doors and making occasional public releases. They
were finally opened to the public in May 1999. gcc is bigger and has many more
people interested in its development, so Cygnus didn't take over its
development and do it behind closed doors. First they synchronised their work
on it (in their internal Cygnus tree) with the FSF maintainers. Then in late
1997 they created an open development project for it which they named EGCS. It
was run by Cygnus and competed with FSF's gcc project. Finally, in spring 1999
FSF closed their gcc project and EGCS was renamed into GCC.

All these programs have been integrated into the Cygnus tree so completely that
they no longer exist separately from it. Moreover, some of these programs are
not even single modules any more. The Cygnus tree consists of many
subdirectories called modules and some top-level glue. Initially, there was one
module for each GNU program grafted into the tree. Then, however, Cygnus added
some new modules, split some existing ones, and made some existing modules
dependent on some new ones. As a result, some of the modules that initially
(long ago) were grafted into the tree from stand-alone GNU packages can no
longer be pulled back out of the tree and used separately.

As Cygnus took over the maintenance of several GNU programs, they started
making new releases of them. However, these programs had already been converted
to work in the Cygnus tree only. How could they release them separately then?
The answer is that these releases are NOT like typical GNU packages that have
the program in the top-level directory of the distribution tarball. Instead,
these releases are actually pruned checkouts of the Cygnus tree, made to look
indistinguishable to the untrained eye from typical GNU packages. An important
property of the Cygnus tree is that it doesn't have to be complete. The top-
level configure script and Makefile check whether each directory they are about
to descend into is actually present, and if it isn't, it's silently skipped. As
a result, you can prune the Cygnus tree down to contain only the modules you
need, and then just those modules will be configured and built. Cygnus-made GNU
releases are all Cygnus tree checkouts pruned down to contain only the modules
needed by the GNU release in question.

GCC is still a single module in the Cygnus tree, but it now depends on the top
level and on libiberty, the miscellaneous support code module that virtually
every other module depends on. Current GCC releases consist of the top level,
libiberty, the actual gcc module, and several modules with target libraries for
different high-level languages that GCC now supports. Current Binutils releases
consist of a lot of modules. There is still a binutils module that loosely
corresponds to the old GNU binutils package, but GNU ld is now a separate
module. (gas has always been a separate module.) The binutils, gas, and ld
modules depend extensively on bfd and opcodes, two major host library modules
invented by Cygnus. Current GDB releases also consist of a lot of modules. gdb
itself is still a single module in the Cygnus tree, but it now depends
extensively on bfd and opcodes, same as Binutils, as well as some other Cygnus-
added modules that Binutils don't use. And of course on libiberty, which is
included in all current GCC, Binutils, and GDB releases.

In addition to the above GNU programs, the Cygnus tree contains many
interesting non-GNU modules developed by Cygnus, most of which have been opened
to the public. These include Newlib, Cygwin, a number of Tcl tools and GUI
libraries, an extensive testsuite framework, and CGEN.

	2. So where is this thing in terms of public CVS and mailing lists?

This is where we currently have a problem. When Cygnus tree-based EGCS/GCC,
Binutils, and GDB were first opened to the public, they were in the form of
pruned Cygnus tree checkouts. We ended up with three GNU projects each having
its own (stale, corresponding to a snapshot from the Cygnus tree at some point)
copy of the top-level files, libiberty, and most of the headers. With Binutils
and GDB it was even worse, as they had their own copies of bfd and opcodes,
both of which are actively maintained and rapidly changing modules.

This is OK for releases, but it's a problem for development. After all, the
whole point of release branches and release engineering is to produce stability
in a single software component, regardless of the staleness and deviation from
the mainline this almost always causes. Before Cygnus opened the development to
the public, they internally had a very sensible model: one master source tree
with one master copy of each module where all development is done, so all
developers are always on the same page, and specific bits of the tree are sent
off on release branches as releases are made. Each release will inevitably have
some oddities introduced into it by the release engineering process, and some
things may become less generic than they could be (for example, the top-level
configure and Makefile will still remind curious code readers of the other
modules in the tree, but because of the potentially incompatible changes on the
release branch, there may not be perfect interoperability with them). However,
developers always have one single master tree to work with, to fix major bugs
in, and to make major improvements to. It is perfectly synergistic and self-
consistent, at the price of less stability because it isn't release-engineered.

This means that releases have the property that some bits in them may be stale
or duplicated elsewhere, both of which are highly undesirable for developers.
The way releases should really work is by letting end users who are not
expected to do their own development and bugfixing have a stable release that
doesn't need any bugfixing. But as soon as a user does find a bug he/she wants
to fix him/herself, he/she should really put the release aside, get the master
copies of all components involved, fix any bugs there, and submit the fixes to
the respective maintainers. This is the Free Software way, and this is what
makes Free Software thrive.

However, this arrangement was hampered by EGCS/GCC, Binutils, and GDB starting
life as public GNU projects in the same branched form in which they exist in
releases. What they should have done was to create a public Cygnus tree, fully
explain to everyone what the Cygnus tree is, and have all development proceed
in it like it did inside Cygnus before. But instead each of EGCS, Binutils, and
GDB began life in its own CVS repository containing the same thing the FSF
release tarballs have in them. The renaming of EGCS back to GCC didn't change
anything.

Unfortunately, the GCC (former EGCS) maintainers seem to not have grasped yet
that this arrangement is troublesome and just plain wrong. (And they have been
living with it since the start of the EGCS project!) Fortunately, the Binutils
and GDB maintainers were much quicker to realise this. Almost immediately after
the opening of these projects it became clear that a single master copy of each
component is needed, instead of two teams working divergently on two branches
made off of a once unified Cygnus tree. Also at the same time parts of the
Cygnus tree other than GCC, Binutils, and GDB (i.e., the Cygnus-developed non-
GNU modules) were being opened to the public. Those aren't GNU projects and
virtually everyone doing significant work on them is from Cygnus. Those folks
are used to the Cygnus tree and know that doing it any other way is just plain
wrong. Therefore, it became clear that the Cygnus tree needed to be brought
back.

In February 2000, less than a year after the opening of Binutils and GDB, their
separate CVS repositories were liquidated. Instead, a new CVS repository was
created which was to be the public Cygnus tree. It is /cvs/src on
sources.redhat.com (formerly sourceware.cygnus.com), and from the start it was
designed as a real full Cygnus tree repository, rather than a repository for
just one project, which is what they did with all their public CVS repositories
before that. (You can check the CVS log on its modules file to convince
yourself.) The modules that make up Binutils and GDB were moved into it,
eliminating the separate Binutils and GDB repositories that existed before.
Immediately after that Newlib and Cygwin were imported from Cygnus' internal
tree (these are Cygnus-developed non-GNU tree modules), confirming without any
doubt that finally the public Cygnus tree was born.

After being born in February 2000, the public Cygnus tree in /cvs/src on the
sourceware machine matured quickly. It is now almost complete. Unfortunately,
there is still one omission. This omission and the need for users/developers to
compensate for it manually is the reason why I'm boring you here with history
lessons instead of just telling you where to get the public Cygnus tree and
what to do with it.

This omission is GCC. Ever since the start of EGCS in late 1997 it has lived in
its own CVS repository. Currently it is /cvs/gcc on the sourceware machine
(sources.redhat.com). Officially it's on gcc.gnu.org, but the dirty little
secret is that gcc.gnu.org is just a DNS record, it points to the very same
sourceware machine, same as sources.redhat.com. Everything else has now been
integrated into the /cvs/src repository, bringing back the Cygnus tree in all
its glory. However, there is also the /cvs/gcc repository duplicating a lot of
it. In effect, instead of one unified public Cygnus tree we, the non-Cygnus
folks who don't have access to their original internal tree, have two trees to
deal with: /cvs/gcc and /cvs/src. The former contains the gcc module and all
language library modules, the latter contains everything else. The two
duplicate all the top-level files and the libiberty module.

Most people working on this code have by now realised that it is really
designed to be in one Cygnus tree, and that's how they work on it. Our unspoken
convention is now to locally construct this tree from the two repositories,
work on it, and check the changes into the right repo(s). The parts that are in
only one of the repositories are simply taken from it and combined into one
tree. The trickier parts are the ones that are duplicated in the two repos.
These are the top-level files, the headers, and libiberty. /cvs/gcc's libiberty
is considered the master one, so that one is usually taken. However, most
commits to it are also simultaneously made to /cvs/src's copy, and the latter
is also periodically replaced with the former, so it usually works just as
well. The include directory in the Cygnus tree contains the public headers for
all modules. It currently exists in both repos. /cvs/src's copy contains the
headers for all modules and /cvs/gcc's copy contains only the headers for
libiberty. The latter follow the same rules as libiberty itself. Finally, there
are the top-level files. These must know about all the modules in tree. Most
people changing these files now keep checking each change into both repos.

The /cvs/src repo has one top-level directory in it also named src, and that
directory has the Cygnus tree in it (sans GCC). You can check it out in its
entirety with:

cvs -d :pserver:anoncvs@sources.redhat.com co src

This will take a lot of time and disk space. The /cvs/src repo also has a
modules file. Remember, the Cygnus tree has lots of modules in it, and most
people work only on those modules that interest them. The modules file in the
/cvs/src repo allows checking out partial Cygnus trees, and the comments in its
CVS log indicate that it is modeled after the modules file of Cygnus' internal
repo, meaning that this is how the modules file of a real Cygnus tree should
look like. It has CVS checkout modules defined for the most common Cygnus tree
module combinations that are normally checked out together. Since CVS checkout
module names exist in the same namespace as the top-level directories in the
repo, of which there is only one (src), there are no conflicts. (In particular,
there is no conflict between CVS checkout modules and the Cygnus tree modules,
the latter being one level below in the src directory.)

The /cvs/gcc repo has one top-level directory in it named egcs, and it has this
repo's version of the Cygnus tree in it. You can check it out in its entirety
with:

cvs -d :pserver:anoncvs@sources.redhat.com co egcs

The /cvs/gcc repo's modules file doesn't do much. It has an egcs-core CVS
checkout module defined that checks out the tree without the language front
ends and target libraries, but other than that, this repo is normally checked
out in its entirety.

As for mailing lists, currently most of the public projects in the Cygnus tree
have their own project-specific mailing lists, but there are no mailing lists
for the Cygnus tree overall, leaving the top-level files and many less popular
modules homeless.

				3. Our Current Solution

So what do we do about it? As I've just explained, we really want and need the
Cygnus tree, but there currently isn't a single public CVS repository for it.
The current solution is for people to construct full Cygnus trees on their
local machines from the two CVS repos and to keep track of these two repos in
development. Here is the procedure I use for constructing the full Cygnus tree
from the two repos:

1. Check out both repos (either in their entirety or only the parts you want).
You'll have two partial Cygnus trees in different directories.

2. Create a directory for the combined Cygnus tree.

3. Populate it with everything from the src repo except the include and
libiberty subdirectories.

4. Add gcc, libiberty, and the language target libraries from the gcc repo.

5. Create the include subdirectory and populate it by merging the include
subdirectories of the two repos. For files that are present in both, use the
gcc repo's version.

Explanation. This procedure is designed with the following two points in mind:

1. libiberty and its headers are taken from the gcc repo, which is considered
the master copy.

2. The procedure I just outlined uses the top-level files from the src repo.
The ones from the gcc repo could have been used instead. Most of the time both
will work equally well. I personally prefer to take them from the src repo
because it was specifically designed as the real full Cygnus tree repo.

				4. The Real Solution

The above procedure, with a few variations, is generally followed by most
developers working in the Cygnus tree. However, this doesn't make it any less
painful. It is just a nuisance for everyone to keep piecing the tree together
every time, then parsing back where to check in patches, and remembering to
keep the two repos in sync. There is absolutely no benefit to gain from the
current arrangement. It doesn't give GCC any more independence. GCC is now
critically dependent on the Cygnus tree (and has been so ever since the start
of EGCS), and by keeping their own copy of it the GCC maintainers are simply
closing their eyes to this. But the reality is that everyone still builds and
tests it together with the rest of the Cygnus tree (using the procedure from
the previous section), and the top-level files in the gcc repo are still kept
in sync with the ones in the src repo, manually and painfully. There is nothing
to lose by doing away with this and merging the repos, only a lot of
convenience and sanity to gain.

This is only one of the problems with the current arrangement. The other
problem is that there is no "home" for the Cygnus tree. There is no place where
people can learn what the Cygnus tree is and read all about it. There is no
mailing list to discuss it overall (as opposed to some particular module in
it). There is no clearly designed group responsible for the maintenance of the
top-level files.

In fact, it's even more than just not having a mailing list for the Cygnus tree
overall. There appears to be some sort of a code of silence around it. Many
people know what it is and do their development with it in mind, but there is
virtually no public mention of it, as if everyone is pretending that it doesn't
exist. This is actually why I had to write this article: to tell the people
what the Cygnus tree is. I have a number of projects that involve the Cygnus
tree, and when presenting them to the public, I found myself facing a strange
problem. I need to refer people to the Cygnus tree, but there is nothing to
refer them to! Their is no home (WWW page, FTP site, mailing list, or anything
at all) about the Cygnus tree that I can point people to. In fact, there is
nothing to even tell people what it is, aside from a very terse remark in Ian
Lance Taylor's "The GNU configure and build system", which while describing how
its configure scripts and Makefiles work, really fails to answer the question
of *what it is*.

As a developer highly interested in the Cygnus tree, I'm trying to do whatever
I can to help solve these problems. This article explaining what the Cygnus
tree is and what is its current situation is my first step. I will end it with
my proposal for what I believe is the right solution.

For the problem of two repos, the solution is to merge them. Given how the src
repo was intended from the start as the repo for the full Cygnus tree and how
it successfully does this now for everything except GCC, there is no need to do
anything with it. It is already exactly the way it should be. All that needs to
be done is to move the gcc and language library modules from the gcc repo to
the src one, replace libiberty and its headers in the src repo with the ones in
the gcc one, and put the gcc repo to rest.

Given how new modules have recently been added to the src repo with no fuss and
no problems, I don't think that the current inhabitants of the src repo would
object to welcoming a new member, or even that their consent would be required.
After all, they don't have to check out any modules other than the ones they
need, and the top-level configure script and Makefile already list everything
anyway. In fact, many src repo inhabitants will certainly like having the
master copy of libiberty in their repo, rather than a mirror that sometimes
gets stale. Thus the only ones who will have to be persuaded are the GCC
maintainers.

The question of merging the repos has come up more than once on the GCC mailing
lists. Some of the GCC maintainers have said that they liked the idea. However,
there seems to be some politics playing against it, apparently coming from FSF.
Thus it appears that the next battle is going to be between us, developers, and
the politicians. In order to fight and win this battle, we must actively push
our cause. This brings us to the second problem of not having a real home for
the Cygnus tree.

The solution for this problem is obvious: create one. This article is a start,
explaining publicly apparently for the first time what the Cygnus tree is and
trying to break the code of silence around it. Now we just need to make all
this better known to more people so that we can start a mailing list for the
Cygnus tree and decide what else do we need for a "home" for it. This
awareness-raising cause will probably have to be pursued on the GCC, Binutils,
and GDB mailing lists. This is because these are the parts of the Cygnus tree
where some people still live in the sandbox of separate GNU projects. Everyone
else, i.e., people working on the Cygnus-developed non-GNU modules like Newlib,
already come from the Cygnus tree background and would certainly be all for
bringing it back.

So, let's all try to do our best to enlighten the public about the Cygnus tree,
create a real home for it, and persuade the GCC maintainers to move to the src
repository!

				Appendix. References

"The GNU configure and build system" by Ian Lance Taylor is file configure.texi
in the etc subdirectory of the Cygnus tree. For those of you who prefer WWW,
the author has a WWW version on his page:

http://www.airs.com/ian/configure/

Once you know what the Cygnus tree is thanks to this article, Ian's superb
tutorial will tell you everything you need to know about its configure scripts
and Makefiles to master development in this tree.

libgloss/doc/porting.texi in the Cygnus tree gives a very good overview of how
the different pieces of the tree come together to support embedded systems and
how to port them to a new one.
From hjl@lucon.org Mon Sep 04 16:45:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Mon, 04 Sep 2000 16:45:00 -0000
Message-id: <20000904164458.A12270@lucon.org>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl>
X-SW-Source: 2000-09/msg00010.html
Content-length: 1563

On Mon, Sep 04, 2000 at 07:51:53PM +0200, Mark Kettenis wrote:
>    Date: Mon, 4 Sep 2000 08:49:34 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    On Mon, Sep 04, 2000 at 11:47:13AM +0100, Joern Rennecke wrote:
>    > > It is too bad that not many gcc developers using --enable-shared to
>    > > configure gcc under ia32. See
>    > 
>    > Well, on Linux, gdb fails to restart a cc1 / cc1plus executable that is
>    > statically linked, which makes debugging very tedious.
>    > So I always patch my Makefile to use static linking.
> 
>    That is a very annoying bug in gdb 5.0. When I set a breakpoint in
>    the shared library, I have to disable them before restart.
> 
> Getting this bug fixed is one of the release criteria for GDB 5.1.
> All I have now is a hack that works around the problems, see the GDB
> TODO file for more info.
> 

How about the hardware watchpoints on ia32? I mean

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.

Thanks.

H.J.
From geoffk@cygnus.com Mon Sep 04 16:54:00 2000
From: Geoff Keating <geoffk@cygnus.com>
To: 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: Mon, 04 Sep 2000 16:54:00 -0000
Message-id: <200009042353.QAA00709@localhost.cygnus.com>
References: <0009042120.AA26535@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00011.html
Content-length: 1009

> Date: Mon, 4 Sep 00 16:20:16 CDT
> From: msokolov@ivan.Harhan.ORG (Michael Sokolov)

> gcc is bigger and has many more people interested in its
> development, so Cygnus didn't take over its development and do it
> behind closed doors. First they synchronised their work on it (in
> their internal Cygnus tree) with the FSF maintainers. Then in late
> 1997 they created an open development project for it which they
> named EGCS. It was run by Cygnus and competed with FSF's gcc
> project. Finally, in spring 1999 FSF closed their gcc project and
> EGCS was renamed into GCC.

This bit is not correct.  EGCS was never 'run by' Cygnus.  It has
always been run by a steering committee on which Cygnus has been
careful to ensure that its employees were never a majority.

> Unfortunately, the GCC (former EGCS) maintainers seem to not have
> grasped yet that this arrangement is troublesome and just plain
> wrong.

Well, I for one would like to see a combined tree.

-- 
- Geoffrey Keating <geoffk@cygnus.com>
From msokolov@ivan.Harhan.ORG Mon Sep 04 17:32: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: Mon, 04 Sep 2000 17:32:00 -0000
Message-id: <0009050030.AA26952@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00012.html
Content-length: 2238

Geoff Keating <geoffk@cygnus.com> wrote:

> This bit is not correct.  EGCS was never 'run by' Cygnus.  It has
> always been run by a steering committee on which Cygnus has been
> careful to ensure that its employees were never a majority.

OK, I checked this in:

------- cygnus-tree-intro -------
*** /tmp/d26930	Mon Sep  4 19:22:03 2000
--- cygnus-tree-intro	Mon Sep  4 19:21:02 2000
***************
*** 45,52 ****
  development and do it behind closed doors. First they synchronised their work
  on it (in their internal Cygnus tree) with the FSF maintainers. Then in late
  1997 they created an open development project for it which they named EGCS. It
! was run by Cygnus and competed with FSF's gcc project. Finally, in spring 1999
! FSF closed their gcc project and EGCS was renamed into GCC.
  
  All these programs have been integrated into the Cygnus tree so completely that
  they no longer exist separately from it. Moreover, some of these programs are
--- 45,52 ----
  development and do it behind closed doors. First they synchronised their work
  on it (in their internal Cygnus tree) with the FSF maintainers. Then in late
  1997 they created an open development project for it which they named EGCS. It
! 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.
  
  All these programs have been integrated into the Cygnus tree so completely that
  they no longer exist separately from it. Moreover, some of these programs are

BTW, what did EGCS stand for?

> Well, I for one would like to see a combined tree.

That's why I wrote:

: Some of the GCC maintainers have said that they liked the idea. However,
: there seems to be some politics playing against it, apparently coming from
: FSF. Thus it appears that the next battle is going to be between us,
: developers, and the politicians.

--
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 jjenkins@jetstream.com Mon Sep 04 17:54:00 2000
From: Jeff Jenkins <jjenkins@jetstream.com>
To: Jeff Jenkins <jjenkins@jetstream.com>, "'Gdb (E-mail) '" <gdb@sourceware.cygnus.com>
Subject: RE: Real-Time signals & GDB
Date: Mon, 04 Sep 2000 17:54:00 -0000
Message-id: <27A2DAA6CAD9D311BF970050DACB2250013E571F@mail.jetstream.com>
X-SW-Source: 2000-09/msg00013.html
Content-length: 1015

 Sorry that I didn't include this information initally.  It was the second
time I posted a similar question.

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

When I send an RT signal to another thread in my process gdb halts and
complains that it received an unknown ? signal.  When I continue, it fails
to deliver the signal.  The signal I am typically sending is RT signal 39 or
40.  Depends on the thread.

I have tried using handle all to handle ALL threads...I want them delivered
to my process so that I may handle them.  I do have other threads in
sigwaitinfo() calls waiting on RT signal 39 & 40.  

-- jrj

-----Original Message-----
From: Jeff Jenkins
To: Gdb (E-mail)
Sent: 9/1/00 11:17 AM
Subject: Real-Time signals & GDB

Anyone here know how to get GDB to properly handle RT signals?  When I
queue a RT signal, GDB complains that it received an unknown signal and
fails to deliever it to the process. Is there something specific I need
to do such that GDB will handle RT signals?
 
Thanks!
 
-- jrj
From dje@watson.ibm.com Mon Sep 04 18:03: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 18:03:00 -0000
Message-id: <200009050102.VAA23408@mal-ach.watson.ibm.com>
References: <0009050030.AA26952@ivan.Harhan.ORG>
X-SW-Source: 2000-09/msg00014.html
Content-length: 542

	I do not understand why you incorrectly insist on using such
hostile and confrontational language in your description of EGCS.  EGCS
was a testbed for some new technology which needed a larger testing
audience than the GCC development environment of the time could provide.
Both the technology and the development method used by EGCS proved
effective, so EGCS and GCC merged back together, incorporating all of the
successes of EGCS.  This is not unlike the way gcc-2 was developed and
redesigned in the late 1980's and early 1990's.

David
From scottb@netwinder.org Mon Sep 04 18:04:00 2000
From: "Scott Bambrough" <scottb@netwinder.org>
To: <gdb@sources.redhat.com>
Cc: "Nick Clifton" <nickc@cygnus.com>, "Andrew Cagney" <ac131313@cygnus.com>
Subject: src/ltcf-c.sh
Date: Mon, 04 Sep 2000 18:04:00 -0000
Message-id: <00b201c016d5$2f8d2c00$LocalHost@netbackup>
X-SW-Source: 2000-09/msg00015.html
Content-length: 791

The autobuild at netwinder.org fails with the following error:

/home/build-rpm/BUILD/gdb/opcodes/../ltconfig:
/home/build-rpm/BUILD/gdb/opcodes/../ltcf-c.sh: No such file or directory
configure: error: libtool configure failed
Configure in /home/build-rpm/BUILD/obj-gdb-20000904/opcodes failed, exiting.
Bad exit status from /var/tmp/rpm-tmp.88907 (%build)

The problem is a cvs checkout of gdb is not updating this file.  It isn't
there so the build fails.  I had a look at the modules file, and it is
included in the alias src-support, which is included in gdb-support which is
used by the gdb module.  If I update my binutils tree, and my insight trees
the file is not checked out, though I expect it to be.  If I check it out
manually by cvs co ltcf-c.sh, it works.

Any ideas?

Scott