Re: bfd cleanups

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 31 Jan 2005, Ben Elliston wrote:

> Here's a whole raft of cleanups.  Again, please speak up if anything
> should be kept!  Tested with a binutils --enable-targets=all build.

Please keep the comment in cpu-cris.c.  I think the code also
serves a purpose, so please keep as a whole or suggest some
improvement in documentness "so that it doesn't just look like
disabled code".  Maybe add "This code is disabled but kept as a
warning" to the top of the comment?

BTW, is there a single word for e.g. a skull put on a pole or at
another prominent location (to serve as a scare against enemies
or territorial intruders or perhaps "just" for poison water)?

> Index: cpu-cris.c
> ===================================================================
> RCS file: /home/bje/src-cvs/src/bfd/cpu-cris.c,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 cpu-cris.c
> --- cpu-cris.c	4 Nov 2004 14:57:43 -0000	1.5
> +++ cpu-cris.c	31 Jan 2005 05:25:08 -0000
> @@ -45,22 +45,6 @@ get_compatible (a,b)
>    if (b->mach == bfd_mach_cris_v10_v32)
>      return a;
>
> -#if 0
> -  /* See ldlang.c:lang_check.  Quite illogically, incompatible arches
> -     (as signalled by this function) are only *warned* about, while with
> -     this function signalling compatible ones, we can have the
> -     cris_elf_merge_private_bfd_data function return an error.  This is
> -     undoubtedly a FIXME: in general.  Also, the
> -     command_line.warn_mismatch flag and the --no-warn-mismatch option
> -     are misnamed for the multitude of ports that signal compatibility:
> -     it is there an error, not a warning.  We work around it by
> -     pretending matching machs here.  */
> -
> -  /* Except for the compatible mach, machs must match.  */
> -  if (a->mach != b->mach)
> -    return NULL;
> -#endif
> -
>    return a;
>  }