Re: libbfd: Guess the architecture of an executable file with libbfd

[Alan Modra <amodra at gmail dot com>]

On Wed, May 22, 2013 at 11:35:05PM +0200, Emmanuel Fleury wrote:
> On 05/22/2013 03:51 PM, Emmanuel Fleury wrote:
> > 
> > But, recently I stumbled into a problem when I am compiling the binutils
> > with `--enable-targets=all`. Once installed with `all`, I get a conflict
> > between two possible arm architectures. Strangely, when compiled only
> > with a few architectures (the Debian package select only a reasonable
> > subset of all targets but not wide enough for what I need), I get a
> > proper behavior.
> 
> By the way, the confusion seems to be between:
> 
> elf32-littlearm
>  (header little endian, data little endian)
>   arm
> elf32-littlearm-symbian
>  (header little endian, data little endian)
>   arm
> elf32-littlearm-vxworks
>  (header little endian, data little endian)
>   arm

Add elf32-littlearm-nacl to that list with current binutils.

I've been meaning to do something about this ever since I wrote
http://sourceware.org/ml/binutils/2013-01/msg00448.html.  The first
hunk in the following patch stops bfd choosing a generic ELF target
(like elf32-little) when another target is a better match
(eg. elf32-littlearm).  The last hunk effectively banishes "File
format is ambiguous" errors for ELF.  This might be a little
controversial, but if vxworks, symbian and nacl are confused by
using the more general machine specific ELF target then they really
should have specified OS_ABI or implemented target object_p, archive_p
and core_file_p functions.

	* format.c (bfd_check_format_matches): Don't match a target in
	targ_selvecs if some other target is a better match.  If
	targets implement match priority, fall back to the first of
	the best matches.

Index: bfd/format.c
===================================================================
RCS file: /cvs/src/src/bfd/format.c,v
retrieving revision 1.32
diff -u -p -r1.32 format.c
--- bfd/format.c	28 Jan 2013 07:58:16 -0000	1.32
+++ bfd/format.c	23 May 2013 02:14:17 -0000
@@ -376,6 +376,9 @@ bfd_check_format_matches (bfd *abfd, bfd
 	}
     }
 
+  /* We have more than one equally good match.  If any of the best
+     matches is a target in config.bfd targ_defvec or targ_selvecs,
+     choose it.  */
   if (match_count > 1)
     {
       const bfd_target * const *assoc = bfd_associated_vector;
@@ -385,7 +388,8 @@ bfd_check_format_matches (bfd *abfd, bfd
 	  int i = match_count;
 
 	  while (--i >= 0)
-	    if (matching_vector[i] == right_targ)
+	    if (matching_vector[i] == right_targ
+		&& right_targ->match_priority <= best_match)
 	      break;
 
 	  if (i >= 0)
@@ -396,6 +400,22 @@ bfd_check_format_matches (bfd *abfd, bfd
 	}
     }
 
+  /* We still have more than one equally good match, and at least some
+     of the targets support match priority.  Choose the first of the
+     best matches.  */
+  if (match_count > 1 && best_count != match_count)
+    {
+      int i;
+
+      for (i = 0; i < match_count; i++)
+	{
+	  right_targ = matching_vector[i];
+	  if (right_targ->match_priority <= best_match)
+	    break;
+	}
+      match_count = 1;
+    }
+
   /* There is way too much undoing of half-known state here.  We
      really shouldn't iterate on live bfd's.  Note that saving the
      whole bfd and restoring it would be even worse; the first thing

-- 
Alan Modra
Australia Development Lab, IBM