Re: HPPA multiarching plan

Jason R Thorpe
2002-11-26T01:04:39Z

On Mon, Nov 25, 2002 at 04:48:57PM -0800, Joel Brobecker wrote:

> - Add 2 new OSABI enums: HPPA_HPUX and HPPA64_HPUX.
> (it seems important to me to keep the OS name in the enum, to
> differentiate with HPPA_LINUX for instance)

You should not need the processor name in the OSABI ("embedded ABIs"
are kind of a special case, which is why you see the processor name
in those). You also should not need the "64" .. I would guess that
would be differentiated based on the object file format (SOM [32] vs.
Elf32 vs. Elf64 -- assuming hppa64 binaries use the Elf64 format; I'm
not sure that they do, please educate me :-).

So, I think you only need GDB_OSABI_HPUX.

> - The sniffer would then guess the correct value based like so:
>
> 1. If object format is ELF
> -> OSABI = HPPA64_HPUX
>
> 2. If object format is SOM
> -> OSABI = HPPA_HPUX

I don't think you actually need a sniffer, either. Take a look at
alpha-tdep.c:alpha_gdbarch_init(). It uses the following algorithm:

* Lookup osabi.
* If osabi is unknown:
* If file is ECOFF, assume GDB_OSABI_OSF1.

So, I would say that you could use the following algorithm for
HPPA:

* Lookup osabi.
* If osabi is unknown:
* If file is SOM or ELF, assume GDB_OSABI_HPUX.

You should also add an HPUX case to osabi.c:generic_elf_osabi_sniffer(),
since there is an ELFOSABI constant for HPUX.

I think between the change to generic_elf_osabi_sniffer(), and the
proper smarts in your hppa_gdbarch_init() function, you can avoid having
to add an osabi sniffer.

> Later on, when we want to add support for hppa-linux, the sniffer will
> need to be refined. I assume hppa-linux uses ELF? In which case we
> will probably have to dig into the ELF header to search for the clue
> that will reveal either hpux or linux.

The existing sniffers will already work with Linux (and eventually
hppa-netbsd, as well), since Linux and NetBSD binaries already carry
distinguishing markings that are recognized by the existing generic
sniffer.

--
-- Jason R. Thorpe <thorpej@wasabisystems.com>