This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Patch: Check input format against output
"H . J . Lu" <hjl@lucon.org> writes:
> > This kind of check would normally be handled in the
> > merge_private_bfd_data routine of the output BFD.
> >
>
> merge_private_bfd_data is defined as bfd_true for many ELF targets.
> If we put this check into merge_private_bfd_data, we may have to touch
> many ELF files.
True, but that doesn't mean it's the wrong thing to do. We have to
keep half an eye on the future, after all.
Perhaps there should be a generic elf merge_private_bfd_data routine,
which should be the default in elfxx-target.h, and which should be
called by other ELF files.
> lang_check calls bfd_arch_get_compatible:
>
> const bfd_arch_info_type *
> bfd_arch_get_compatible (abfd, bbfd)
> const bfd *abfd;
> const bfd *bbfd;
> {
> /* If either architecture is unknown, then all we can do is assume
> the user knows what he's doing. */
> if (abfd->arch_info->arch == bfd_arch_unknown)
> return bbfd->arch_info;
> if (bbfd->arch_info->arch == bfd_arch_unknown)
> return abfd->arch_info;
>
> /* Otherwise architecture-specific code has to decide. */
> return abfd->arch_info->compatible (abfd->arch_info, bbfd->arch_info);
> }
>
> If the arch for abfd is not configured in BFD, abfd->arch_info->arch
> will be bfd_arch_unknown.
I guess the problem here is that the bad file got recognized as the
generic ELF target, which is bfd_arch_unknown?
It seems to me that we can catch that case easily enough. Define a
link_input_bfd routine for elf32-gen.c and elf64-gen.c. Have that
routine roll over and die. We're not going to be able to link those
files, since we don't know how to process the relocs.
Ian