This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: HPPA multiarching plan
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