Re: [PATCH] Handle loading improper core files gracefully in the mips backend.

Pedro Alves
2016-01-12T19:08:26Z

On 01/12/2016 06:30 PM, Maciej W. Rozycki wrote:
> On Tue, 12 Jan 2016, Luis Machado wrote:
>> Pedro Alves wrote:
>
>>> I also wonder whether the bfd arch detection couldn't be always
>>> compiled in, at least for elf. Why does bfd fail to detect that this
>>> is an bfd_arch_i386 file in the first place?
>
> The mapping between `e_machine' and `bfd_architecture' is only provided
> by individual BFD ELF target backends, via the ELF_MACHINE_CODE and
> ELF_ARCH macros.

Thanks. In principle, it sounds to me that at least the
ELF_MACHINE_CODE -> bfd_architecture sniffing bits could be
factored out and always be present. But, that might not be practical.

>> Sounds like we have a couple issues. The mips backend not handling weird
>> abi/isa combinations and GDB not preventing clearly incompatible core files
>> from proceeding further into processing in the target's backend?
>
> I have given it some thought and came to a conclusion that we should at
> least try being consistent. Which means I think we should not try to
> handle files within the MIPS backend which would not be passed in the
> first place in an `--enable-targets=all' configuration. Rather than
> checking `e_machine' explicitly I'd be leaning towards using BFD to detect
> such a situation though, perhaps by using a condition like
>
> if (info.abfd != NULL
> && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour
> && bfd_get_arch (info.abfd) != bfd_arch_mips)
> return NULL;
>
> (maybe with an additional error message) though ultimately I think it
> would make sense to define different BFD architecture codes for file
> formats which by definition carry no architecture information and for ones
> that do but are not supported.

Agreed. Seems like that could be the job of bfd_arch_obscure -- it's used
as default/unhandled case in some formats that do have architecture
information. Though it isn't used throughout all bfd backends.

> Then for the formers we could continue
> selecting the target using the current algorithm and for the latters we'd
> just reject them as incompatible with the given backend -- all somewhere
> in generic code so that individual target backends do not have to repeat
> it all.
>
> As to ABI, ISA, etc. settings -- these are internal to the MIPS backend,
> so its the backend's job to sanitise them.

/me nods.

Thanks,
Pedro Alves