untested but building 64-bit toolchain, issues/questions
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.
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.
In message <[email protected]>you write:
Quoted 7 lines
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.
Quoted 7 lines
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
Quoted 6 lines · Jeffrey A Law
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.
Quoted 11 lines · David Huggins-Daines
Quoted 6 lines · Jeffrey A Law
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.
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.
In message <[email protected]>you write:
Quoted 4 lines
Quoted 2 lines
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
Quoted 8 lines · Jeffrey A Law
In message <[email protected]>you write:
Quoted 4 lines
Quoted 2 lines
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.
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.
In message <[email protected]>you write:
Quoted 3 lines
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.
Quoted 9 lines
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 ([email protected])? Where this kind of stuff is usually discussed.
jeff
In message <[email protected]>you write:
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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 :-)
Quoted 8 lines
Quoted 1 line
I'm not aware of a technical reason why this will not work in the assembl
er;
Quoted 1 line
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
Quoted 3 lines · Jeffrey A Law
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
In message <[email protected]>you write:
Quoted 10 lines
Quoted 3 lines · Jeffrey A Law
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