Return-Path: paula Return-Path: Received: from spiff.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA04509; Tue, 14 Apr 92 19:04:49 PDT Date: Tue, 14 Apr 92 19:04:49 PDT From: paula (Paula Vancini) Message-Id: <9204150204.AA04509@cygnus.com> Received: by spiff.cygnus.com (4.1/SMI-4.1) id AA12488; Tue, 14 Apr 92 19:04:48 PDT To: engnews-distrib Cc: smlieu Subject: This month's ICE Reply-To: engnews@cygnus.com Organization: Cygnus Support, Palo Alto CA; Phone +1 415 322 3811 --------------------------------------------------------------------- INSIDE CYGNUS ENGINEERING April 1992 --------------------------------------------------------------------- Inside Cygnus Engineering (ICE) is published monthly for customers of Cygnus Support. Our objective is to provide a relevant but informal summary of news and ongoing activities. Please send all comments, suggestions, and subscription requests to engnews@cygnus.com. FEATURE: CYGNUS PROGRESSIVE RELEASES ------------------------------------ We made the first productized "progressive" release for Sun3 and Sun4 native tools last month. This is a prepackaged box which includes a tape of sources and prebuilt binaries, with documentation and a simple installation script. Some of the software programs included are gdb 4.4, gcc/g++ 1.96, libg++ 2.0, and send_pr, the new problem reporting program. Cygnus's Progressive Release is our mechanism to make the rapid evolution of and enhancements to the gnu tools available to a wide audience. How does it actually happen? Gnu development at Cygnus resides on our master source tree "devo" (as many of you know). For programs such as gdb or gas, where we are the official FSF maintainers, devo is the authoritative set of source code. For the other gnu programs, we make sure our merges with the FSF sources are frequent and consistent. The devo sources evolve from one day to the next, and fluctuate in stability and robustness. For a progressive release, we select a particularly stable set of interoperating gnu tools from devo. We build and test these on the designated native and/or cross platforms, and then package the sources, binaries, documentation, release notes, etc. like any commercial software product, for distribution to our customers. We started simply with two native toolchains, and will be adding more platforms regularly. We expect to make progressive releases every two to three months, and will be announcing them in Inside Cygnus Engineering. Here's what we are shooting for over the next six months: Approx. Date Platform -------------------------------------------------------------- May Native: DECstation, IBM RS6000, SGI-Iris June Target: 68k, i960, 29k June/July Native: Solaris 2.0 (sparc) September Native: SCO-Unix Host: HP700, DOS Target: i386/486 In general, we intend to provide a complete toolchain for each native or cross combination, and to make the same one available for all of the "supported platforms". This means that the entire collection of platforms will usually (but not always) be rebuilt with each progressive release. Occasionally a particular program will not be available on a given platform. For example, the May progressive will be available for the five native platforms. It will include gdb 4.5 and gcc 2.1. However, there is no gas, ld, or binutils for the DECstation, RS6000, or the SGI-Iris. Our Core and Leveraged customers will get every release for their supported platforms. The release notes will indicate what has changed from one release to another so that a customer may choose whether or not to install it. PRODUCTS AND RELEASES --------------------- 1. Gdb 4.5 The newest gdb, 4.5, has just been released to the net. New machines supported include IBM RS6000 running AIX and the SGI Irix-4.x. Here are some of the major new improvements: - Gdb now uses a new memory manager called mmalloc, based on gmalloc. It can greatly speed up the startup of GDB by using a pre-parsed symbol table in a mmalloc-managed heap. If memory-mapped files are available on your system through the 'mmap' system call, you can have gdb write the symbols from your program into a reusable file. - Support for MS-DOSe (extended) as a host for cross debugging has been added, although some problems remain to be fixed. - Reading MIPS ecoff symbol and cross debugging to MIPS are now supported on all hosts. MIPS Computer Systems made this possible by making two of their header files freely redistributable. - Many bug fixes were made. Major improvements occurred in g++, cross debugging of Sparc and MIPS targets from hosts whose byte order differs, and ECOFF symbol file reading. 2. Send_pr The first official release of send_pr, the Cygnus problem reporting program, was distributed last month, and some of you are actively using it. What happens when you send off the problem report (PR)? 1. When a send_pr report reaches Cygnus, a problem report with a unique identification number is opened. The responsible engineer for the software is notified. You get back an email message that includes the unique ID number and confirms that we have logged the report. The PR is in "open" state. 2. The responsible engineer analyzes the problem, determines how long it will take to solve it, and whether a workaround is possible. For critical or high priority PR's we send the analysis within the acknowledgment period to you. The PR is now in the "analyzed" state. This may be a very short step, since problem reports often are analyzed and a solution made available right away (see below). 3. When the solution is defined or implemented at Cygnus, it is sent to you for feedback. It may or may not be included in software that we ship, but the PR is not closed. This approach helps ensure that the problem is solved to your satisfaction. The PR is in the "feedback" state. 4. When you are satisfied with the solution and let us it, the problem report is closed. The PR moves to the "closed" state. 5. Occasionally there are problems where there is no ready solution, e.g., a c++ construct that requires clarification from the ANSI language committee. These PR's are put into the "suspended" state. To make this work, we need your help by: 1. Including a concise definition of the problem in the synopsis field of send_pr, so that we can make summary reports of software status readily available; and 2. Giving us feedback to close problem reports when the problem has been solved. Distributing send_pr is a start. We have a lot of plans for using this problem report management system (PRMS) to improve and provide additional services. Some ideas include providing summary reports of the status of our gnu software on request, response time auditing, and remote access by our customers. Another use is to help us develop a regression test suite covering previously reported problems. Let us know what else you would like to see. NEW AND ONGOING DEVELOPMENTS ---------------------------- We are implementing some of the following for certain platforms, so for the moment, they are not all tested or available for generic use. But with the progressive releases that we have begun, we hope to make these available to you quickly. 1. Using gcc/g++ for code coverage analysis Gcc/g++ can be built to generate code that in turn produces code execution coverage statistics. The raw data are on a per source file basis, and a separate program, gcov, can be run to generate source line count and percent coverage summary information over all the source files. 2. Solaris 2.0 gcc update A preliminary version of gcc for Solaris has been built. Position- independent code is still being implemented. BFD has been extended to handle writing of ELF files, though a few bugs remain to be worked out. Gas is also being improved to use BFD to write ELF files. Gdb has also been modified to support Solaris. At this time it can control and debug processes, but it is not capable of reading symbols. 3. G++ Re-engineering We haved worked out the changes needed in gcc to improve the interface between the generic compiler and the g++ parts with Richard Stallman. These changes will result in improved g++ stability as well as making ELF/DWARF debugging information possible for g++. They will also allow better compliance with the Draft Proposed ANSI Standard. SUPPORT ACTIVITIES ------------------ 1. Guide to Cygnus support services In addition to new developments, a significant part of our engineering resources is devoted to answering questions, fixing problems in the gnu software, and providing a range of support services to our customers. The send_pr software and PRMS is one of our efforts. We are planning a document entitled "Guide to Cygnus Support Services" to describe our services and processes; for example, the process that happens when you use send_pr to send us a bug report that was described above. Please let us know what other information you would like to see in this document. 2. Software Status Update Open problem reports as of April 6: 214 New reports since March 9: 110 Reports closed since March 9: 73 QUESTIONS FOR OUR CUSTOMERS --------------------------- As much as we would like to tell you about what's happening inside Cygnus engineering, we would also like to hear from you. This is a new section that we hope you will take a few minutes to think about, and reply to us at engnews@cygnus.com. 1. In what form would you like to get software distributions from Cygnus? [ ] QIC-24 [ ] QIC-150 [ ] Exabyte [ ] CD-ROM [ ] FTP [ ] uucp [ ] Other: ____________________________________ 2. How are we doing? Are you satisfied with what Cygnus is providing you? (Please feel free to elaborate.) [ ] Yes [ ] No [ ] Maybe 3. What did we forget to ask you? (Essay question for extra credit.) --------------------------------------------------------------------- Cygnus Support 814 University Avenue One Kendall Square Palo Alto, CA 94301 Cambridge, MA 02139 +1 415 322 3811 voice +1 617 494 1040 voice +1 415 322 3270 fax +1 617 494 1325 fax