Proposal: obsolete target hppa*-hp-hpux10.*

Proposal: obsolete target hppa*-hp-hpux10.*

[Michael Elizabeth Chastain]

I propose to obsolete this target in gdb 6.1 and remove it in gdb 6.2:

  hppa*-hp-hpux10.*

This does not include hppa*-hp-hpux11.*, which has active development.

Reasons for removing this configuration:

  . gdb 6.0 does not build on this configuration.

    http://sources.redhat.com/gdb/bugs/1411
    Build of gdb-6.0 on hppa1.1-hp-hpux10.20 fails

      This is a different build failure than the build failures
      with hppa2.0w-hp-hpux11.11.

  . there is no development activity for this target

  . there is no QA activity for this target

  . HP's test drive cluster does not include an hp-ux 10.* machine

  . HP has discontinued and obsoleted hp-ux 10.*

    http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,5143,00.html
    frequently asked questions -- hp-ux

      2002-06-30   hp-ux 10.20 removed from corporate price list
      2003-06-30   hp-ux 10.20 product support no longer available from HP

Reasons for keeping this configuration:

  . Someone (me) is actively working on native hppa2.0w-hp-hpux11.11.

    If gdb works on hpux 11.11, the incremental effort for development
    and QA of hpux 10.20 is not as big.

  . There is at least one user (Dave A), which means that there are
    probably more users.

Philosophically, I see the issue as priorities.  It takes work to
maintain and QA gdb on hpux 10.20.  It takes work even if gdb on hpux
11.11 is already working.  I would rather spend my attention somewhere
else, and so would everybody else in the world, judging by the level of
activity.

Comments?

Michael C

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[John David Anglin]

>   . There is at least one user (Dave A), which means that there are
>     probably more users.
> 
> Philosophically, I see the issue as priorities.  It takes work to
> maintain and QA gdb on hpux 10.20.  It takes work even if gdb on hpux
> 11.11 is already working.  I would rather spend my attention somewhere
> else, and so would everybody else in the world, judging by the level of
> activity.

I'm willing to see if I can resolve the build problems under HP-UX 10.20.

As far as the code generated by GCC and the debug information, there is
almost no difference between HP-UX 10 and 11.  We have weak symbol support
and and a different way of running initializer, but that's it.  I don't
particularly care about HP compiler support.  There's still a fair number
of PA 1.1 workstations running.  They were really the peak in PA-RISC
technology and they have proved to be extremely reliable.  On the other
hand, I agree that there isn't much point in spending a lot of effort
on the machines.

The 10.20 machine that I use for GCC testing is mainly used for support
of a space experiment that probably will be supported by NASA and ESA
through to the end of 2007.  I'm not particularly interested in moving
the software and licenses to a newer machine.  So, I will probably try
to keep the machine operational until the end of the mission.  Anyway,
I probably will support 10.20 in GCC until 3.5 is released.

I think if Michael can improve gdb under HP-UX 11, we would also see
benefits under HP-UX 10.

Carlos O'Donell has made a New Years resolution to spend a good
portion of his time on gdb for hppa-linux.  He has done an excellent
job in improving glibc.  Matthew Wilcox has offered a bounty for a
gdb maintainer for hppa-linux:

<http://lists.parisc-linux.org/pipermail/parisc-linux/2004-January/022061.html>.

I managed to build gdb 6.0 under hppa-linux starting from the debian
patches.  It only took a couple of small patches.  My initial impression
is that it works better than 5.3, particularly with ada code.  I did
have a problem with an undefined dwarf2 DIE.

In summary, I'm hopeful that the gdb support for PA-RISC can be improved
in 2004.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[Andrew Cagney]

> I propose to obsolete this target in gdb 6.1 and remove it in gdb 6.2:
> 
>   hppa*-hp-hpux10.*

Ah, you've figured out my strategy: shake the tree, see what falls out 
:-) "go for it".

> This does not include hppa*-hp-hpux11.*, which has active development.
> 
> Reasons for removing this configuration:
> 
>   . gdb 6.0 does not build on this configuration.
> 
>     http://sources.redhat.com/gdb/bugs/1411
>     Build of gdb-6.0 on hppa1.1-hp-hpux10.20 fails
> 
>       This is a different build failure than the build failures
>       with hppa2.0w-hp-hpux11.11.
> 
>   . there is no development activity for this target
> 
>   . there is no QA activity for this target
> 
>   . HP's test drive cluster does not include an hp-ux 10.* machine
> 
>   . HP has discontinued and obsoleted hp-ux 10.*
> 
>     http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,5143,00.html
>     frequently asked questions -- hp-ux
> 
>       2002-06-30   hp-ux 10.20 removed from corporate price list
>       2003-06-30   hp-ux 10.20 product support no longer available from HP
> 
> Reasons for keeping this configuration:
> 
>   . Someone (me) is actively working on native hppa2.0w-hp-hpux11.11.

Can I guess that you're, at least in part, working on 11.11 because it 
is a stable PA RISC based platform and offers a path for getting 
GNU/Linux PA out of limbo?

>     If gdb works on hpux 11.11, the incremental effort for development
>     and QA of hpux 10.20 is not as big.

This isn't sufficient to justify requiring you spending your volunteer 
time on that system.  If someone is willing to step forward and help, 
that would be really appreciated.

>   . There is at least one user (Dave A), which means that there are
>     probably more users.
> 
> Philosophically, I see the issue as priorities.  It takes work to
> maintain and QA gdb on hpux 10.20.  It takes work even if gdb on hpux
> 11.11 is already working.  I would rather spend my attention somewhere
> else, and so would everybody else in the world, judging by the level of
> activity.

Yes.

Andrew

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[John David Anglin]

On Wed, Jan 07, 2004 at 09:50:31PM -0500, Michael Elizabeth Chastain wrote:
> I propose to obsolete this target in gdb 6.1 and remove it in gdb 6.2:
> 
>   hppa*-hp-hpux10.*
> 
> This does not include hppa*-hp-hpux11.*, which has active development.
> 
> Reasons for removing this configuration:
> 
>   . gdb 6.0 does not build on this configuration.

I downloaded yesterdays CVS source for gdb and built it under
hppa1.1-hp-hpux10.20.

I configured it as follows:

../src/configure --build=hppa1.1-hp-hpux10.20 --host=hppa1.1-hp-hpux10.20 --pref
ix=/usr/local --with-included-regex --disable-nls

Since I don't have an assignment for gdb, I'll just say that the only
change necessary was to delete "NUM_REGS" from line hpux-thread.c:221.
I suspect that there may be regmap issues with the 64-bit hpux port,
which has a different number of registers, but that's an HP-UX 11 issue.

I saw the following warnings from the gdb portion of the build:

gcc -c -g -O2  -D__HP_CURSES -Dvfork=fork  -I. -I../../src/gdb -I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/../include/opcode -I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../intl -I../../src/gdb/../intl  -DMI_OUT=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral  ../../src/gdb/valprint.c
../../src/gdb/valprint.c: In function `print_longest':
../../src/gdb/valprint.c:331: warning: format not a string literal, argument types not checked
../../src/gdb/valprint.c:340: warning: format not a string literal, argument types not checked
../../src/gdb/valprint.c:346: warning: format not a string literal, argument types not checked
../../src/gdb/valprint.c:349: warning: format not a string literal, argument types not checked
../../src/gdb/valprint.c:352: warning: format not a string literal, argument types not checked
../../src/gdb/valprint.c:355: warning: format not a string literal, argument types not checked
../../src/gdb/valprint.c:358: warning: format not a string literal, argument types not checked

gcc -c -g -O2  -D__HP_CURSES -Dvfork=fork  -I. -I../../src/gdb -I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/../include/opcode -I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../intl -I../../src/gdb/../intl  -DMI_OUT=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral  ../../src/gdb/printcmd.c
../../src/gdb/printcmd.c: In function `printf_command':
../../src/gdb/printcmd.c:1965: warning: format not a string literal, argument types not checked
../../src/gdb/printcmd.c:1971: warning: format not a string literal, argument types not checked
../../src/gdb/printcmd.c:1978: warning: format not a string literal, argument types not checked
../../src/gdb/printcmd.c:1988: warning: format not a string literal, argument types not checked

gcc -c -g -O2  -D__HP_CURSES -Dvfork=fork  -I. -I../../src/gdb -I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/../include/opcode -I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../intl -I../../src/gdb/../intl  -DMI_OUT=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral  ../../src/gdb/hppa-tdep.c
../../src/gdb/hppa-tdep.c: In function `hppa_frame_saved_pc':
../../src/gdb/hppa-tdep.c:1072: warning: implicit declaration of function `hppa32_hpux_frame_saved_pc_in_sigtramp'
../../src/gdb/hppa-tdep.c: In function `hppa_frame_chain':
../../src/gdb/hppa-tdep.c:1326: warning: implicit declaration of function `hppa32_hpux_frame_base_before_sigtramp'
../../src/gdb/hppa-tdep.c:1271: warning: `u' might be used uninitialized in this function
../../src/gdb/hppa-tdep.c: In function `pa_register_look_aside':
../../src/gdb/hppa-tdep.c:2834: warning: format not a string literal and no form at arguments
../../src/gdb/hppa-tdep.c: In function `hppa_frame_find_saved_regs':
../../src/gdb/hppa-tdep.c:4045: warning: implicit declaration of function `hppa32_hpux_frame_find_saved_regs_in_sigtramp'
../../src/gdb/hppa-tdep.c:4149: warning: integer constant is too large for "long " type

gcc -c -g -O2  -D__HP_CURSES -Dvfork=fork  -I. -I../../src/gdb -I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/../include/opcode -I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../intl -I../../src/gdb/../intl  -DMI_OUT=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral  ../../src/gdb/hppah-nat.c
../../src/gdb/hppah-nat.c: In function `store_inferior_registers':
../../src/gdb/hppah-nat.c:199: warning: format not a string literal and no format arguments
../../src/gdb/hppah-nat.c: In function `fetch_register':
../../src/gdb/hppah-nat.c:277: warning: format not a string literal and no format arguments

gcc -c -g -O2  -D__HP_CURSES -Dvfork=fork  -I. -I../../src/gdb -I../../src/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/../include/opcode -I../../src/gdb/../readline/.. -I../bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../intl -I../../src/gdb/../intl  -DMI_OUT=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith
   -Wuninitialized -Wformat-nonliteral  -I../../src/gdb/osf-share \
	  -I../../src/gdb/osf-share/HP800 -I/usr/include/dce \
	  ../../src/gdb/hpux-thread.c
../../src/gdb/hpux-thread.c: In function `hpux_thread_fetch_registers':
../../src/gdb/hpux-thread.c:294: warning: implicit declaration of function `memset'
../../src/gdb/hpux-thread.c: In function `hpux_thread_store_registers':
../../src/gdb/hpux-thread.c:363: warning: cast to pointer from integer of different size

Dave

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[Michael Elizabeth Chastain]

> All that HP/UX specific xfail stuff should be deleted unconditionally. 
> It's all wrong.  It's another HP merge bogon.  Time to again threaten to 
> remove the lot? :-)

I don't *know* that all of them are wrong.  Some of them may be genuine
bugs on hppa*-*-hpux*, either with the hp-ux compiler or with gcc
on that target.

Now that I can run the test suite and I can kill lots of them, though.
In fact, I'll go kill some more today.

  % grep -r 'setup_xfail.*hp' ... 

Michael C

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[Andrew Cagney]

> ac> Can I guess that you're, at least in part, working on 11.11 because it 
> ac> is a stable PA RISC based platform and offers a path for getting 
> ac> GNU/Linux PA out of limbo?
> 
> Stand back, I'm gonna vent ...
> 
> Well, no.
> 
> My original motivation was that there's a lot of code in the test suite
> which is HP-specific.  gdb.cp/local.exp has all these cases for HP
> compilers and I can't touch them.  Now I can touch them.  funcargs.exp
> had twenty-three instances of "if { $hp_cc_compiler } { setup_xfail
> hppa*-hp-hpux* }".  funcargs.exp now has zero instances of
> "$hp_cc_compiler".

Can I also vent? :-)

All that HP/UX specific xfail stuff should be deleted unconditionally. 
It's all wrong.  It's another HP merge bogon.  Time to again threaten to 
remove the lot? :-)

Andrew

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[John David Anglin]

> I don't care about hppa*-*-linux.  It's low priority for the future,
> too.  As I understand it, HP is phasing out hppa architecture in favor
> of ia64.  Their transition will take several more years and I do want to
> support hppa*-hp-hpux* for several more years.  But hppa boxes are going
> away.

Whether ia64 will survive longer than PA-RISC is hard to say.  HP
has a plan but plans can change.  I personally don't care about
HP's plans and they don't really affect my choice in supporting
PA-RISC.  It's reports like this that matter to me:

  > > Carlos, thank you for all the work you've put in over the last year
  > > and more.  We would be significantly worse off without your efforts.
  > > I'm sure many people who read this aren't aware just how much work you've
  > > put in to make PA/Linux as good as it is -- and that's a compliment.

  Same here; there are still a lot of issues with my C3000, but that does
  not mean it's not great; the machine runs and is stable, even with the
  USB and frame buffer issues.  Totally stable.  I am VERY PLEASED with
  the progress that has been made on HPPA linux; this machine is now one
  I depend on, because I know I can.

  Thanks for all the work.

Sorry for off topic response.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

PS: my i386 box isn't stable under a heavy load.

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[Michael Elizabeth Chastain]

ac> Can I guess that you're, at least in part, working on 11.11 because it 
ac> is a stable PA RISC based platform and offers a path for getting 
ac> GNU/Linux PA out of limbo?

Stand back, I'm gonna vent ...

Well, no.

My original motivation was that there's a lot of code in the test suite
which is HP-specific.  gdb.cp/local.exp has all these cases for HP
compilers and I can't touch them.  Now I can touch them.  funcargs.exp
had twenty-three instances of "if { $hp_cc_compiler } { setup_xfail
hppa*-hp-hpux* }".  funcargs.exp now has zero instances of
"$hp_cc_compiler".

Same for gdb itself.  You ran gcov and there were a lot of files not
covered.  The problem is particularly acute for the symtab readers.  As
I write this, I'm working on a gcov version (thanks Elena Z for her
message of 2003-01-06, which makes it really easy) so I can take care of
deprecation in hpread.c and somread.c.

I'd like to get on alphaev*-*-osf5.1 as well.  Anything with a vendor
compiler.  It's all about code coverage.

My long term plan is:

  . gdb includes a list of supported configurations
  . each supported configuration gets regression tested regularly
  . the test results get posted to gdb-testers@
  . somebody reviews the results before each release

(Also, after I started this work, I realized that it fits another,
more personal goal).

I don't care about hppa*-*-linux.  It's low priority for the future,
too.  As I understand it, HP is phasing out hppa architecture in favor
of ia64.  Their transition will take several more years and I do want to
support hppa*-hp-hpux* for several more years.  But hppa boxes are going
away.

Back in the early days of GNU software, there was a hand-me-down
mentality, or a bootstrap mentality if you prefer.  We took whatever
machines we could get, suffered with the vendor OS and the vendor shell,
and bootstrapped a partial GNU system on them.  Even our release process
still has a "sun4" buried in it.  (I thought that was funny a year ago
when I noticed it.  Now it's a release show-stopper).

But the Penguin is here.  My system is open source starting from the
first block that the BIOS reads from the hard disk.  So is yours,
probably.  And it's cheap.  And it's high quality.  If I want another
GNU system, it takes me 1-3 days to work and earn money and buy another
i686-pc-linux-gnu system.  It would take me much longer to configure a
working hppa*-*-linux system even if the hardware was *free*, because I
hear that there are bugs in hppa*-*-linux where gdb crashes the kernel,
and someone has to fix those bugs.

We are no longer in the days when machines cost two months of an
engineer's salary and the way to get a GNU system was to scrounge a
hand-me-down machine and port GNU to it.  Now the way to get a GNU
system is to spend a few day's salary and stick in a CD.

I can't choose other people's goals and priorities, but I think that
hppa*-*-linux is a hobby and will not help with world domination, and
the Debian hppa/linux distro is a waste of time.  It's many engineer
months for a system that O(10) or O(100) people will run and they are
short of engineer months for their other goals with Sarge.  But it's
their goals, their choice.  Just my opinion.

Contrast with C++.  Look what's written in C++: Mozilla, Open Office,
KDE, Cygwin.  Our prospects in the desktop war depend on C++ apps, and
gdb support for C++ is a weak link in the development chain.

And yes, I know that I'm personal-computer-centric.  That's my bias.
But even after that bias, I think that Linux in the workstation and
server market is a lot more interesting when the vendor actively sells
and supports it.

And maybe I'm completely wrong about this and HP actively supports
hppa*-*-linux, they give the developers all the internal docs that they
need, and sell a lot of hppa*-*-linux, the way IBM sells linux.

Michael C

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 86 bytes --]

> Can you mail logs or typescripts from the build process?

Build log attached.

Dave

[-- Attachment #2: build.log.gz --]
[-- Type: application/x-gunzip, Size: 14554 bytes --]

Re: Proposal: obsolete target hppa*-hp-hpux10.*

[Michael Elizabeth Chastain]

Hi Dave,

> I'm willing to see if I can resolve the build problems under HP-UX 10.20.

That would be good.

Can you mail logs or typescripts from the build process?
When I build, I do something like:

  configure > configure.log 2>&1
  make > make.log 2>&1
  make install > install.log 2>&1

If you could send me all the logs, that would help.

> As far as the code generated by GCC and the debug information, there is
> almost no difference between HP-UX 10 and 11.

Well, there are three things here:

. differences between hppa1.1 and hppa2.0w
. differences between hppa10.20 and hppa11.11
. ongoing QA effort

> I don't particularly care about HP compiler support.

Then we don't have to support it.  That's going to help, because
undoubtedly there were hp compiler bugs in the 10.20 compiler versions
that will have been fixed by hpux 11.11.

> I think if Michael can improve gdb under HP-UX 11, we would also see
> benefits under HP-UX 10.

Yeah.  It's not like I'm intentionally going to break anything.

> I managed to build gdb 6.0 under hppa-linux starting from the debian
> patches.  It only took a couple of small patches.

hppa-linux is still in limbo.  I'm expending zero effort on it so far.
It does have a couple of advantages: it's an open source OS so it's
more important to the FSF; it's got active OS developers; and there's
an hppa-linux system in the test drive cluster.

Michael C