HPPA multiarching plan

HPPA multiarching plan

[Joel Brobecker]

[This plan assumes that the ports to bsd/osf/pro are either obsoleted, or
taken care of by somebody else]

today I have tried to get a bigger picture of what to do to get the hppa
ports (partially) multi-arched. The targets that I will be converting
are:
	hppa*64*-*-hpux11*
	hppa*-*-hpux*
	hppa*-*-hiux*

I am assuming hiux is just a synonym of hpux?

The first thing I wasn't sure was to build an os_abi sniffer. So far,
given the short lists of targets, I suggest the following:

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

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

What do you think?

-- 
Joel

Re: HPPA multiarching plan

[Daniel Jacobowitz]

On Mon, Nov 25, 2002 at 04:48:57PM -0800, Joel Brobecker wrote:
> [This plan assumes that the ports to bsd/osf/pro are either obsoleted, or
> taken care of by somebody else]
> 
> today I have tried to get a bigger picture of what to do to get the hppa
> ports (partially) multi-arched. The targets that I will be converting
> are:
> 	hppa*64*-*-hpux11*
> 	hppa*-*-hpux*
> 	hppa*-*-hiux*
> 
> I am assuming hiux is just a synonym of hpux?
> 
> The first thing I wasn't sure was to build an os_abi sniffer. So far,
> given the short lists of targets, I suggest the following:
> 
>   - 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)
> 
>   - 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
>       
>     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.
> 
> What do you think?

Well, I'm not up on all the details of the osabi code, but by analogy
with what is there that doesn't seem right.  None of them have the
_platform_ in the OS ABI.  I'd think it should just be HPUX.

I'm not sure if we'd need to have something separate for hppa64-hpux. 
Probably not, and select based on hppa vs hppa64, both with osabi of
HPUX.  Assuming that they have the same bfd_architecture, that is...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: HPPA multiarching plan

[Jason R Thorpe]

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>

Re: HPPA multiarching plan

[Joel Brobecker]

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

Re: HPPA multiarching plan

[Jason R Thorpe]

On Mon, Nov 25, 2002 at 05:24:54PM -0800, Joel Brobecker wrote:

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

We're glad to help :-)

 > 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          

Actually, yah, having an HPUX_ELF and and HPUX_SOM probably makes
sense, because e.g. shared library handling will be different.  (i.e.
you would want different osabi_init routines for each format, each
of which possibly calling a common one to do some common HPUX setup.)

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

Well.. for things which are purely "pa32 vs pa64" and having nothing
to do with the osabi per se, then you can determine this from info
in the BFD structure.

For things which are osabi-specific, the osabi_init routine for
that osabi will fill in the bits of the gdbarch/gdbarch_tdep structures.
Take a look at e.g. alphanbsd-tdep.c:alphanbsd_init_abi() (the osabi
init routine for Alpha with GDB_OSABI_NETBSD_ELF) and
alphanbsd-tdep.c:_initialize_alphanbsd_tdep() (which registers that osabi
init routine).

BTW, one thing that you're going to run into while doing this is
that the shared library support in GDB isn't really multarch'd.  That
will have to be addressed in order for you to build a GDB which supports
both hppa+SOM and hppa64+Elf64.

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

Re: HPPA multiarching plan

[Andrew Cagney]

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

Assuming that HPPA64 and HPPA are different ABIs (true?), then they 
should be identified using separate OSABI designations.  That way, the 
ABI code is independant of the underlying object file format (ELF or SOM 
or ....).

This is more in line with MIPS with n32, o32, o64 and 64.

Andrew

Re: HPPA multiarching plan

[Jason R Thorpe]

On Tue, Nov 26, 2002 at 10:26:43AM -0500, Andrew Cagney wrote:

 > Assuming that HPPA64 and HPPA are different ABIs (true?), then they 
 > should be identified using separate OSABI designations.  That way, the 
 > ABI code is independant of the underlying object file format (ELF or SOM 
 > or ....).
 > 
 > This is more in line with MIPS with n32, o32, o64 and 64.

Err.. but different ABIs at that level aren't really the same as
different OSABIs, though, right?

I.e. Linux/mips and NetBSD/mips both use o32 (same ABI) but different
OSABIs.  Similarly, NetBSD/mips could support both the o32 and n32 ABIs
(well, once the n32 tools work :-), but they'd still use the same OSABI
because apart from the low-level, things like shared library handling,
signals, etc. are the same.

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