This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 05/23/2013 05:35 AM, Alan Modra wrote:
>
>> 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.

Yes, I was using 2.22 on my first attempt.

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

I applied the patch on a 2.23 and it worked fine for my case.

Thanks a lot !

Regards
-- 
Emmanuel Fleury

There is a theory which states that if ever anyone discovers exactly
what the Universe is for and why it is here, it will instantly disappear
and be replaced by something even more bizarrely inexplicable.

There is another theory which states that this has already happened.
  -- The Book theorizing (Douglas Adams)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]