[parisc-linux] [patch] Remove magic constant from gas/tc-hppa.c

John David Anglin dave@hiauly1.hia.nrc.ca
Mon Oct 30 07:42:00 GMT 2006

> It looks like the best thing to do is to support the -march parameter,
> similar to gcc.  gcc supports:
> -march={1.0,1.1,2.0}
> Should I add 2.0w to this for 64bit?  Talking about it with Randolph on
> IRC, he pointed out that hppa2.0w-hp-hpux11.11 targets a 32 bit
> userspace on a wide kernel.

Right.  The convention is that the first hunk refers to the kernel
architecture.  Back in the old days, the tools only supported a 32-bit
userspace.  When the 64-bit tools were developed, a way to select the
64-bit userspace was needed.  hppa64 was chosen for 64-bit userspace.
So, config.guess now changes hppa2.0w to hppa64 if it detects ${CC}
is generating 64-bit code.

This was obviously the easy way forward and probably hppa64 should
never have been invented.  However, it was, so I think we are stuck
with it.  If merging archs can be done, then it will just become
a synonym for hppa2.0w.  The downside in doing this is that the
arch needs to be specified when packages are configured.

I think that adding -march={1.0, 1.1, 2.0, 2.0w} to the command
line options is reasonable.  This together with .level could be
used to select output format and arch.  I think .level overrides
the command line option (warning needed).  .level should appear
before any other directives.  If we need to become more specific
about the ABI, then an -mabi option could be added.

The tricky part is handling both som and elf64 for hpux, and elf32
and elf64 for linux.  It will take a fair bit of work to merge the
bfd stuff.  It may be difficult to do this in a clean manner given
that the elf and som targets are quite different.

I think the best plan would be to do the various merges before
adding the option to select the arch at runtime.

> HP/UX as supports the syntax:
> +DAarchitecture
> But I'd rather stick with something that feels more like the rest of the
> arches and toolchain.

The big problem in supporting multiple ABIs lies in GCC.  The som and
elf64 targets are essentially incompatible.  There are a number of macros
which change GCC's behavior depending on whether they are defined or not
defined.  We have a number of macros that need to be defined in one case
and not in the other.  Jeff Law used to say it wasn't worth the effort
to merge the two ports.  I think the same problem is present in binutils
and gdb.

The GMP package has an ABI configure option.  I don't really like it but
for performance reasons they want to use 64-bit registers with the 32-bit
som runtime and a wide kernel.  This works since the kernel saves the
full 64-bit context.  However, we don't try this in GCC since the upper
32-bits aren't preserved across calls.

HP compilers also have a +DDdata_model option to generate code for
the ILP32 and ILP64 data models.  This option overlaps to some extent
the +DA option.

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

More information about the Binutils mailing list