Re: Problems generating shared library for MIPS using binutils-2.13...

[Daniel Jacobowitz <dan@debian.org>]

On Tue, Nov 05, 2002 at 03:19:04PM +0000, Richard Sandiford wrote:
> "Steven J. Hill" <sjhill@realitydiluted.com> writes:
> > In the '_bfd_mips_elf_final_write_processing' function in 'bfd/elfxx-mips.c'
> > If I print out the EF_MIPS_ARCH flags for the input BFD descriptor. It
> > is properly set to 'MIPS2', but when the case statement in
> > '_bfd_mips_elf_final_write_processing' is traversed, it
> > uses the R3000/default case which means that the target CPU architecture
> > didn't get put into the BFD descriptor.
> 
> Is it related to this?
> 
>     <http://sources.redhat.com/ml/binutils/2002-10/msg00248.html>
> 
> (In the message body, I accidentally copied the code after
> the patch rather than before.  Sorry about that.)
> 
> Anyway, that patch won't solve your problem, but the issue
> seems to be the same: _bfd_mips_elf_merge_private_bfd_data()
> merges the EF_MIPS_ARCH and EF_MIPS_MACH bits, but
> _bfd_mips_elf_final_write_processing() overwrites them
> based on the BFD mach.
> 
> Personally, I think _bfd_mips_elf_final_write_processing()
> is doing the right thing.  Surely we ought to be able to
> set EF_MIPS_ARCH and EF_MIPS_MACH based on the value of
> bfd_get_mach?

Surely we can't...  Remember what EF_MIPS_ARCH says: it's actually what
we call ISA level elsewhere!  I just spent a day beating on this and
settled for untagged instead of correctly-tagged binaries; I was trying
to built SB-1 binaries (that's EF_MIPS_MACH of EF_MIPS_MACH_SB1) for a
32-bit userland (that's EF_MIPS_ARCH_2).  Not just E_MIPS_ABI_O32, but
actually -mips2 code.

We can't infer that from the result of bfd_get_mach, I don't think! 
You're moving in the wrong direction.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer