Re: build/1411: Build of gdb-6.0 on hppa1.1-hp-hpux10.20 fails

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

The following reply was made to PR build/1411; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
Cc: gdb-gnats@sources.redhat.com
Subject: Re: build/1411: Build of gdb-6.0 on hppa1.1-hp-hpux10.20 fails
Date: Sun, 14 Dec 2003 15:07:04 -0500 (EST)

 > My first question: what are c200, a500, and c3750?  I don't know that
 > terminology.
 
 The C200 is a 200 MHz workstation with an early PA8000 process.  It runs
 a 64-bit kernel and supports 32 and 64-bit apps.
 
 The A500 is the predecessor to the rp2470 (same box).  The one I have
 is a two processor 550 MHz.  It uses the PA8500 chip.  The rp2470 is
 also two processor.  The open source group has one running linux and
 its availble for open source development.  I, Alan Modra and others
 have accounts on it.  It's a 650 MHz cpu using the PA8700.  For the
 most part there no difference between an A500 and rp2470.  However,
 there is some difference in the memory subsystem.  SMP linux works
 on the A500 but not on the rp2470.  This has been an issue for over
 a year and HP has been reluctant to provide processor specific
 technical documentation for these models.
 
 The c3750 is a 875 MHz workstation using the PA8700 processor.
 There's also a dual processor version.  The 875 MHz chip is the
 fastest PA-RISC chip currently available.
 
 The PA8800 chip should be coming fairly soon.  There will be a 4
 processor workstation.  Processor speeds will be in excess of a
 GHz.  Grant Grundler says that it has a better I/O subsystem than
 itanium and that it will outperform comparable itanium systems.
 This might present a quandry to HP as their long term goal is to
 phase out pa-risc in favor of ia64.
 
 The instruction set on all these machines is identical.  The differences
 lie in the I/O and memory subsystems.  There might be differences in
 the pipelines used in the various PA8000 chips but HP hasn't made that
 information available.
 
 > I've been using the HP test drive cluster.  That gives me hpux 11.11 on
 > rp2470 (whatever that is) -- it's a pa-risc 2.0.  And they've also got
 > a hppa64-unknown-linux-gnu system which I haven't used yet.
 
 Then, you probably don't need access to my machines.
 
 > To run the test suite yourself, you would have to:
 
 If you send your script, I will see about setting it up.
 
 > It's a QA function more than a development function.
 >  
 > > The Open Source Group at HP has a supply of older systems that they
 > > are willing to give to PA-RISC developpers.
 > 
 > I would rather that they attach more systems to the test drive cluster.
 
 Yes, that's definitely easier although Grant has always done some
 preliminary setup on the machines that he has sent me.
 
 > > http://gcc.gnu.org/ml/gcc-testresults/2003-11/msg00100.html
 > 
 > See, that's what I'm looking for, regularly on gdb-testers.
 >  
 > One problem is that we have such a backlog because hpux 10.20 hasn't
 > been tested in several years and has already bit-rotted to the point
 > where gdb 6.0 won't build.  It's going to take many hours of attention
 > to fix this.  You have to decide if you want to put some hours into
 > this.
 
 I'm currently using 5.0 under hpux 10.20.  It's definitely true that
 the code has been rotting.  The old Utah versions were probably about
 the best.  My impression is that HP got ideas to enhance gdb and added
 a lot of of poorly integrated features that contributed to the rot.
 
 My desire for newer versions is mainly to get better support for
 debugging C++ and languages other than C.
 
 Some of the problems that I see in using gdb are:
 
 1) Poor frame recognition in stack traces.  Sometimes it's not possible
    to do a backtrace.
 
 2) Problems recognizing complex symbols.
 
 3) Problems following forks.
 
 4) Crashes and getting confused to the point that I have to quit a session.
 
 5) p function () segfaults under hppa-linux.  This problem has been fixed
    a couple of times but it seems to keep coming back.
 
 6) There seem to be some dwarf2 problems on hppa64.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)