Re: HPPA multiarching plan

[Joel Brobecker <brobecker@gnat.com>]

My many thanks to Daniel and Jason for their very prompt and helpful
answers!

> 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 :-).

I see what you mean. (and yes, hppa64 uses Elf64).

> So, I think you only need GDB_OSABI_HPUX.

Ok.

> 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.

That's absolutely brillant. I'll learn a bit more about this
generic sniffer, it looks really cool :).

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

Wildo, thanks for pointing this.

One little thing that still bothers (because I don't know yet how to
properly handle this) is: some of the gdbarch methods will be different
depending whether it is a pa64 or a pa32... Having 2 osabis was
convenient that way. I see we have NETBSD_AOUT and NETBSD_ELF, perhaps
it would still make sense to define 2 new osabis vis:
  - _HPUX_ELF
  - _HPUX_SOM          

Otherwise, what I could do is maintain a local variable in the
gdbarch_init routine, and set it depending on the object format...

-- 
Joel