[parisc-linux] untested but building 64-bit toolchain, issues/questions

[parisc-linux] untested but building 64-bit toolchain, issues/questions

[David Huggins-Daines]

Hi,

I've checked in some bits to get binutils-2.10 to build for 64-bit
Linux/ELF targets.  I have not even attempted to test it yet, but it
doesn't seem to break my 32-bit stuff.  Wherever possible I tried to
reuse the existing 64-bit HP/UX stuff, however I had to do some kludgy
things to work around problems in the way the configuration is set up.

I am using 'hppa2.0w-*-linux-gnu*' as the target architecture string,
so to build a cross-binutils for this target, use the following
configure command:

../binutils-2.10/configure --enable-64-bit-bfd --target=hppa2.0w-linux

I've only tested this in Linux/i386 for the time being.

A couple of questions:

1) What is the proper GNU architecture string for 64-bit Linux on
   PA-RISC?  On #parisc we sort of decided on using
   'hppa1.1-*-linux-*' for 32-bit Linux and 'hppa2.0w-*-linux-*' for
   64-bit Linux.  However the existing configuration files use some
   other strange pattern like 'hppa*64*-*-*' to configure for 64-bit
   PA-RISC.  Seeing as hppa2.0w is 64-bit by definition I don't think
   this makes much sense.

2) A corollary to this problem is that the choice of a 32- or 64-bit
   target in gas is determined at configure time rather than at
   runtime.  Every other architecture allows you to specify the
   architecture revision, code model, and word size on the assembler
   command line (it's the compiler that gets configured differently),
   and it would be nice if we could too.  Can anyone think of a reason
   why we cannot do this?

3) Finally, we use the 'linux' emulation for the assembler instead of
   the 'hppa' or 'hppa64' ones.  I had to kludge in a separate
   'linuxhppa64' target in order to get TARGET_WORD_SIZE defined
   properly.  Can anyone think of a better way to do this?  I think
   that merging the 32 and 64-bit code as noted above would be the
   Right Thing to do.

Cheers.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[Jeffrey A Law]

  In message <87u2e4kye8.fsf@linuxcare.com>you write:
  > 1) What is the proper GNU architecture string for 64-bit Linux on
  >    PA-RISC?  On #parisc we sort of decided on using
  >    'hppa1.1-*-linux-*' for 32-bit Linux and 'hppa2.0w-*-linux-*' for
  >    64-bit Linux.  However the existing configuration files use some
  >    other strange pattern like 'hppa*64*-*-*' to configure for 64-bit
  >    PA-RISC.  Seeing as hppa2.0w is 64-bit by definition I don't think
  >    this makes much sense.
64bit is hppa64-*-*.

We do _not_ want to ever default the tools to 64bit due to the significant
code generation penalties that involves.

Thus we can not key 64bit generation on the strings returned by config.guess.

This was discussed on the gcc, gdb, binutils, and autoconf development 
lists.


  > 2) A corollary to this problem is that the choice of a 32- or 64-bit
  >    target in gas is determined at configure time rather than at
  >    runtime.  Every other architecture allows you to specify the
  >    architecture revision, code model, and word size on the assembler
  >    command line (it's the compiler that gets configured differently),
  >    and it would be nice if we could too.  Can anyone think of a reason
  >    why we cannot do this?
I'm not aware of a technical reason why this will not work in the assembler;
there are *major* problems trying to make this work with the compiler.  Feel
free to try and merge them.

jeff

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[David Huggins-Daines]

Jeffrey A Law <law@cygnus.com> writes:

> 64bit is hppa64-*-*.
> 
> We do _not_ want to ever default the tools to 64bit due to the significant
> code generation penalties that involves.
> 
> Thus we can not key 64bit generation on the strings returned by config.guess.

Yes, but I thought that 'hppa2.0w' means 64 bit by definition, so it
strikes me that the problem is with config.guess returning this.

> This was discussed on the gcc, gdb, binutils, and autoconf development 
> lists.

Can you provide a subject: line to search on or a URL?  I can't find
any definitive statements on the semantics of config.guess nor the
proper configuration for 64-bit PA-RISC in the archives.

> I'm not aware of a technical reason why this will not work in the assembler;
> there are *major* problems trying to make this work with the compiler.  Feel

Yes, I'm aware of that :) I was hoping to follow the Sparc model where
the compiler is configured to pass the appropriate flags to the
assembler.

> free to try and merge them.

It turns out this isn't a big priority at the moment since we'd prefer
not to break the existing HP/UX support, but if it turns out to be
easy I might.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[David Huggins-Daines]

David Huggins-Daines <dhd@linuxcare.com> writes:

> Jeffrey A Law <law@cygnus.com> writes:
> 
> > 64bit is hppa64-*-*.
> > 
> > We do _not_ want to ever default the tools to 64bit due to the significant
> > code generation penalties that involves.
> > 
> > Thus we can not key 64bit generation on the strings returned by config.guess.
> 
> Yes, but I thought that 'hppa2.0w' means 64 bit by definition, so it
> strikes me that the problem is with config.guess returning this.

Oh, and one more thing.  GCC thinks that hppa2.0w is a 64-bit target.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[Jeffrey A Law]

In message <873dlnl3f9.fsf@linuxcare.com>you write:
  > > Yes, but I thought that 'hppa2.0w' means 64 bit by definition, so it
  > > strikes me that the problem is with config.guess returning this.
  > 
  > Oh, and one more thing.  GCC thinks that hppa2.0w is a 64-bit target.
Err, no.  Go look at the official GCC, GDB, binutils repositories.

hppa2.0w is not considered a 64bit target by any of the tools.

jeff

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[David Huggins-Daines]

Jeffrey A Law <law@cygnus.com> writes:

> In message <873dlnl3f9.fsf@linuxcare.com>you write:
>   > > Yes, but I thought that 'hppa2.0w' means 64 bit by definition, so it
>   > > strikes me that the problem is with config.guess returning this.
>   > 
>   > Oh, and one more thing.  GCC thinks that hppa2.0w is a 64-bit target.
> Err, no.  Go look at the official GCC, GDB, binutils repositories.
> 
> hppa2.0w is not considered a 64bit target by any of the tools.

Urgh.  Understood.  This means that the gcc tree on
puffin.external.hp.com CVS is quite out of date, which is sort of what
I expected.  I'm looking at the possibility of merging it now.

On the subject of architecture strings:

I know Matthew Wilcox has been pushing for using 'parisc-*-linux-gnu'
and 'parisc64-*-linux-gnu' as the arch strings for 32 and 64 bit
targets, and standardising on a 'linux' dialect of assembly language
for both (basically 2.0 mnemonics).  What would the chances of this
being accepted by the binutils/gcc/autoconf maintainers be?  (should I
be asking this on another list? sorry...)

We need to standardise on these things ASAP, since we are starting to
build userspace, and we will be stuck with them very soon.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[Jeffrey A Law]

  In message <874s63p218.fsf@linuxcare.com>you write:
  > Urgh.  Understood.  This means that the gcc tree on
  > puffin.external.hp.com CVS is quite out of date, which is sort of what
  > I expected.  I'm looking at the possibility of merging it now.
Certainly possible.  Especially if you get a tree from the releases Cygnus
made to HP.  Lots has changed since then.

  > I know Matthew Wilcox has been pushing for using 'parisc-*-linux-gnu'
  > and 'parisc64-*-linux-gnu' as the arch strings for 32 and 64 bit
  > targets, and standardising on a 'linux' dialect of assembly language
  > for both (basically 2.0 mnemonics).  What would the chances of this
  > being accepted by the binutils/gcc/autoconf maintainers be?  (should I
  > be asking this on another list? sorry...)
  > 
  > We need to standardise on these things ASAP, since we are starting to
  > build userspace, and we will be stuck with them very soon.
I would strongly recommend hppax.y[w] and hppa64 since the GNU tools already
know about those names.  Otherwise you're going to spend a lot of time
unnecessarily hacking up configure scripts.

I believe there's a list (config@gnu.org)?  Where this kind of stuff is
usually discussed.
jeff

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[Jeffrey A Law]

  In message <87puorl517.fsf@linuxcare.com>you write:
  > Yes, but I thought that 'hppa2.0w' means 64 bit by definition, so it
  > strikes me that the problem is with config.guess returning this.
Yes/No.  It would have been more convenient in some ways if it didn't do
that -- however it has also been argued that not returning the "w" loses
information.  ie, when the "w" is included we have a system that is 
capable of running 64bit binaries -- not all hppa2.0 systems can run
64bit binaries.

  > > This was discussed on the gcc, gdb, binutils, and autoconf development 
  > > lists.
  > 
  > Can you provide a subject: line to search on or a URL? 
I don't remember offhand.

  > I can't find
  > any definitive statements on the semantics of config.guess nor the
  > proper configuration for 64-bit PA-RISC in the archives.
They're there :-)  

  > > I'm not aware of a technical reason why this will not work in the assembl
  > er;
  > > there are *major* problems trying to make this work with the compiler.  F
  > eel
  > 
  > Yes, I'm aware of that :) I was hoping to follow the Sparc model where
  > the compiler is configured to pass the appropriate flags to the
  > assembler.
The biggest problems you're going to run into are radically different ABIs
in the 32bit and 64bit worlds -- things like arguments growing in different
directions.

jeff

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[Grant Grundler]

Jeffrey A Law wrote:
> ie, when the "w" is included we have a system that is 
> capable of running 64bit binaries -- not all hppa2.0 systems can run
> 64bit binaries.

My brain isn't working that well today...I had the think about this for
a minute...let me make it obvious to others.

The limiting factor would be the OS.
Eg hppa2.0n-linux (or HPUX 10.20) on a system with PA2.0 CPU.

grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

Re: [parisc-linux] untested but building 64-bit toolchain, issues/questions

[Jeffrey A Law]

  In message <200007061901.MAA10121@milano.cup.hp.com>you write:
  > Jeffrey A Law wrote:
  > > ie, when the "w" is included we have a system that is 
  > > capable of running 64bit binaries -- not all hppa2.0 systems can run
  > > 64bit binaries.
  > 
  > My brain isn't working that well today...I had the think about this for
  > a minute...let me make it obvious to others.
  > 
  > The limiting factor would be the OS.
  > Eg hppa2.0n-linux (or HPUX 10.20) on a system with PA2.0 CPU.
Yup.  There are even versions of hpux11 that are not 64bit capable even
on PA2.0 hardware.  For example, unpatched hpux11.00 wouldn't run 64bit
code on a D/R 390.

jeff