Re: [PATCH/RFA] Generic OS ABI handling

[Richard Earnshaw <rearnsha@arm.com>]

thorpej@wasabisystems.com said:
> Okay, here we go.. This has the includes cleaned up as suggested.
> This patch also includes the changes for SH (already approved by
> Elena), ARM (Richard?  Does this patch look okay to you?), Alpha
> (maintainerless, but it looks okay to me :-), and MIPS (HI ANDREW :-)

Sorry Jason, I don't think this is correct.  I don't think that it will 
correctly handle the fact that existing GNU binutils tools for ARM set the 
ELFOSABI field to ELFOSABI_ARM for starters, or the fact that ARM's 
toolkit uses the top eight bits of the ELF EI_FLAGS field to set the ABI 
in use.  We either need to be able to extend the generic ELF sniffer or to 
supply an answer that overrides it.  Please take another look at the 
existing ARM/ELF sniffer code in arm-tdep.c.

Maybe a sniffer registration should be able to set a priority level (maybe 
just SPECIFIC/GENERIC) in a return field, then a SPECIFIC selection will 
always override a GENERIC selection.  A generic sniffer would always be 
registered as returning a GENERIC match, and specific system sniffers 
could override that.

Also, this comment

+      /* When elfosabi is ELFOSABI_NONE (0), this is supposed to indicate
+	 that we're on a SVR4 system.  However, some systems use note sections
+	 to record OS/ABI info, but leave e_ident[EI_OSABI] zero.  So we
+	 have to check the note sections, too.  */

Is not strictly correct (it's a derivative of a comment that I wrote 
before I fully understood the meaning of this field).

A more accurate comment might be:

When elfosabi is ELFOSABI_NONE (0), then the ELF structures in the file 
are conforming to the base specification for that machine (there are no 
OS-specific extensions).  In order to determine the real OS in use we must 
look for OS notes that have been added.

R.