PA64 configure issues

PA64 configure issues

[Jeffrey A Law]

I have an issue that affects a variety of projects that we need to hash
through.


Newer HP machines have the capability of running both 32bit (PA32) and
64bit (PA64) binaries.

PA32 and PA64 are radically different in a number of ways which make
supporting both with a single toolchain very difficult/impossible.

In general, most developers do not need PA64 capabilities, in fact, using
PA64 generally results in programs that are larger and slower than PA32
programs.  My current thoughts are to have the GNU tools default to PA32
and require special options or configure names to enable PA64 capabilities.

Right now on a PA64 capable machine config.guess will return something like

hppa2.0w-hp-hpux11.00
       ^
       +------  This indicates the machine has the capability to run PA64
                code.

One idea is to have  config.guess never indicate if the machine is PA64
capable.  ie, in the above example config.guess would return

hppa2.0-hp-hpux11.00

That would allow all the existing configury bits to default to PA32 and
the user could expicitly ask for PA64 by using the target triplet with the
"w" indicator.

Other option would be to make the 64bit tools have a triplet like
hppa64-hp-hpux11.00 or something like that.  It wouldn't require any
changes to config.guess to get the desired behavior.

I'm willing to do either (or anything else that sounds reasonable).  The only
trick is we have to do something that is consistent across gcc, binutils, gdb
and autoconf.

jeff

Re: PA64 configure issues

[Geoff Keating]

> Date: Tue, 25 Apr 2000 10:23:42 -0600
> From: Jeffrey A Law <law@cygnus.com>

> In general, most developers do not need PA64 capabilities, in fact, using
> PA64 generally results in programs that are larger and slower than PA32
> programs.  My current thoughts are to have the GNU tools default to PA32
> and require special options or configure names to enable PA64 capabilities.

This is the approach we use on ppc.  The exact same constraints
exist---ppc64 binaries are less compatible, and may not be faster.  So
the toolchains default to 32-bit binaries, and switch to doing 64-bit
with the option '-maix64'.

> Right now on a PA64 capable machine config.guess will return something like
> 
> hppa2.0w-hp-hpux11.00
>        ^
>        +------  This indicates the machine has the capability to run PA64
>                 code.

It turns out to be surprisingly useful to be able to build 64-bit
binaries on a 32-bit machine.  Partly this is because AIX can build
shared libraries that contain both 32-bit and 64-bit code, but also
because the 32-bit machines turn out to be faster for compiling on
(the compiler is a 32-bit binary, of course :-).

So on aix/ppc, the toolchain can always build 64-bit binaries when the OS
support for it is there (on AIX 4.3 and higher).

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: PA64 configure issues

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> PA32 and PA64 are radically different in a number of ways which make
Jeff> supporting both with a single toolchain very difficult/impossible.

	Geoff gave the background on 64-bit AIX support which can support
both modes with a single toolchain, defaulting to 32-bit mode.  This also
happens to be the way that the AIX product compilers operate, so the two
are consistent.

	The above line in your original message jumps out at me.  Are you
saying that you must build an entirely separate compiler for PA64?  Also,
you did not mention how HP's commercial toolchain operates/defaults.

	I would agree that defaulting to 32-bit mode, even on 64-bit
hardware, is the best choice when the hardware can support both modes.  If
the user needs to configure and build a completely separate toolchain for
64-bit mode, that is much more cumbersome than the AIX toolchain.  If HP's
toolchain defaults differently, I think that you need to consider
user-interface compatibility as well.

	I cannot tell if you are asking about which compilation mode to
choose as a default or which compiler to build as a default on a 64-bit
capable system (if that indeed is the case).

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

Re: PA64 configure issues

[Jeffrey A Law]

  In message < 200004251814.OAA28140@mal-ach.watson.ibm.com >you write:
  > 	Geoff gave the background on 64-bit AIX support which can support
  > both modes with a single toolchain, defaulting to 32-bit mode.  This also
  > happens to be the way that the AIX product compilers operate, so the two
  > are consistent.
Good.

  > 	The above line in your original message jumps out at me.  Are you
  > saying that you must build an entirely separate compiler for PA64?  Also,
  > you did not mention how HP's commercial toolchain operates/defaults.
Yes, we have to build a separate toolchain.  Among other things PA32 and PA64
use completely different object file formats (SOM & ELF respectively) one
supports gnu-ld (PA64) the other will never support gnu-ld (PA32).  There's
other issues, but those are the two biggest.

HP's tools work by having a front-end which invisibly fires up the appropriate
32bit or 64bit tool based on runtime flags.  

  > 	I would agree that defaulting to 32-bit mode, even on 64-bit
  > hardware, is the best choice when the hardware can support both modes. 
OK.

  > If
  > the user needs to configure and build a completely separate toolchain for
  > 64-bit mode, that is much more cumbersome than the AIX toolchain.
Yup.  And that's the root of the problem I'm trying to resolve.

  > If HP's
  > toolchain defaults differently, I think that you need to consider
  > user-interface compatibility as well.
I don't think we're going to have that kind of compatibility.  At least not
at this stage.


jeff

Re: PA64 configure issues

[Alexandre Oliva]

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

On Apr 25, 2000, Jeffrey A Law <law@cygnus.com> wrote:

> Other option would be to make the 64bit tools have a triplet like
> hppa64-hp-hpux11.00 or something like that.  It wouldn't require any
> changes to config.guess to get the desired behavior.

I like the idea of matching hppa*64-*-hpux* to select 64bit support.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: PA64 configure issues

[Jeffrey A Law]

  In message < or4s8pdhue.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
  > On Apr 25, 2000, Jeffrey A Law <law@cygnus.com> wrote:
  > 
  > > Other option would be to make the 64bit tools have a triplet like
  > > hppa64-hp-hpux11.00 or something like that.  It wouldn't require any
  > > changes to config.guess to get the desired behavior.
  > 
  > I like the idea of matching hppa*64-*-hpux* to select 64bit support.
Since nobody else chimed in.  I'll go ahead and do something like this
since it doesn't require changing config.guess to not report useful
information (narrow vs wide).

My only concern is configure scripts that aren't using wildcards correctly,
but I guess we'll find those soon enough :-)

Thanks for the input,
jeff

Re: PA64 configure issues

[Alexandre Oliva]

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

On Apr 27, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>   In message < or4s8pdhue.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
>> On Apr 25, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>> I like the idea of matching hppa*64-*-hpux* to select 64bit support.

> My only concern is configure scripts that aren't using wildcards
> correctly, but I guess we'll find those soon enough :-)

I think the most common case of match hppa*-*-hpux* will still work
for most applications, since it probably would not make that much
difference.  And, since presumably you'll take care of the tool-chain,
you'll have taken care of the most likely spots.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: PA64 configure issues

[Jeffrey A Law]

  In message < or7ldja0h7.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
> I think the most common case of match hppa*-*-hpux* will still work
  > for most applications, since it probably would not make that much
  > difference.  And, since presumably you'll take care of the tool-chain,
  > you'll have taken care of the most likely spots.
I'm not worried about the ones with hppa* -- I've already identified those;
it's those which do stuff like hppa?.? that I worry about.

jeff

Re: PA64 configure issues

[Alexandre Oliva]

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

On Apr 27, 2000, Jeffrey A Law <law@cygnus.com> wrote:

> I'm not worried about the ones with hppa* -- I've already identified those;
> it's those which do stuff like hppa?.? that I worry about.

Well, those are already broken, since this doesn't match hppa-*-hpux*.
And they don't match the trailing `w' either, so it's ok if they don't
match an additional trailing `64'.  I wouldn't worry about them.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: PA64 configure issues

[Jeffrey A Law]

  In message < orpurb8k6p.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
  > On Apr 27, 2000, Jeffrey A Law <law@cygnus.com> wrote:
  > 
  > > I'm not worried about the ones with hppa* -- I've already identified thos
  > e;
  > > it's those which do stuff like hppa?.? that I worry about.
  > 
  > Well, those are already broken, since this doesn't match hppa-*-hpux*.
  > And they don't match the trailing `w' either, so it's ok if they don't
  > match an additional trailing `64'.  I wouldn't worry about them.
hppa without a version number is not valid in a configuration string.  The
fact that gcc and maybe other accept it is lame and broken.

jeff