binutils 2.20.1+gcc 4.4.3 on mipsel question

[Kertész Csaba]

Hi,

> Just so I understand: is reloc.elf generated using -r?  If so, then yeah,

Yes, it is generated with -r.

> the offsets in the -r output don't necessarily correspond to those in
> the fully-linked binary.  (TBH, I'm surprised they were ever close
> enough to work, so perhaps I'm missing something.  But the number of
> features that cause the -r output to differ from the fully-linked
> output has been steadily increasing over the years.)

:(

> Have you considered linking normal.elf with -q (aka --emit-relocs)
> instead?  That tells the linker to preserve the original relocations.
> If you're worried about binary size, you can strip the (static)
> relocations later using objdump -S.
>
> I'm not sure this process is ever going to be completely reliable
> though.  You'll also need to compile with -fpie, -fPIE, -fpic or -fPIC,
> if you aren't already, otherwise GCC will use things like R_MIPS_HI16
> and R_MIPS_LO16 rather than R_MIPS_32.

Ok, I quickly tried these things out, but they did not fix my problems
in my first trials. Anyway, thanks for the detailed answer, I had the
fear that I was not enough accurate and clear in my previous email.

My major problem, that I do not know anything about the target device
implementation of loading the binaries, there is no Linux-like system
there, the ELF objects are loaded during the boot process and I can
see only very minimal error message on the console if the boot fails
because of an incorrect binary.

An other question, can I force the gcc compiler somehow to use
R_MIPS_32 all the time and forget about R_MIPS_26? I do not know how
well the target device can handle this type and I can see some after
every compilation.

Csaba