This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binutils 2.20.1+gcc 4.4.3 on mipsel question
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