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

[Pedro Alves <palves@redhat.com>]

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