On 7/6/06, Jan Kratochvil <[EMAIL PROTECTED]> wrote:
> On Thu, 06 Jul 2006 04:32:26 +0200, Magnus Damm wrote:
> ...
> > > Not sure which approach is better but got a question. By definition, are
> > > executable files supposed to be relocatable?
>
> No. Unless you provide --emit-relocs.

Right.

> > > Or we are just trying to do some hack by treating an R_386_32 type
> > > relocation as R_386_RELATIVE effectively.
>
> I did not dead with R_386_RELATIVE, only with R_386_32 and R_386_PC32.
> The kernel build with mkdump patches would fail on R_386_RELATIVE:
>         
> http://mkdump.cvs.sourceforge.net/mkdump/linux/scripts/reltab.c?view=markup&pathrev=linux-2_6-minik
>         else RELOC_ASSERT("howto->name unknown"==NULL);
>
> ...
> > Isn't the difference between R_386_32 and R_386_RELATIVE that the
> > latter is a PC-relative addressing mode?
>
> Such difference is between R_386_32 and R_386_PC32. R_386_RELATIVE is intended
> for shared libraries only.
>         http://x86.ddj.com/ftp/manuals/tools/elf.pdf

Yeah, I was mixing them up. I meant "R_386_32 and R_386_PC32".

> > The addressing mode and the
> > relocation type is setup by the compiler I think, and it is only up to
> > me to follow it to make sure the address is calculated correctly...
>
> Just the relocation type was incorrect in the 2.6.9 days so Eric W. Biederman
> fixed it while I rather ignored it (and guessed it by the symbol address
> instead).

Exactly!

> > > Thinking aloud, How about compiling the kernel as shared library and then
> > > performing the relocations in user space at load time instead of runtime.
>
> This was irrelevant for mkdump as finally it created "bzImage" in its non-ELF
> binary form as it always have been (with relocations handld internally during
> its internal bootstrapping).
>
> As kdump was messing with ELF and new kernel file format it is on you whether
> you will use "-shared" or "--emit-relocs".  "-shared" looks too dangerous to 
> me
> as it starts messing with GOTs, PLTs etc.
>         http://people.redhat.com/drepper/dsohowto.pdf
>
> Still it may be possible to reach the same goals even with "-shared", maybe 
> the
> relocation types will be different (R_386_32->R_386_RELATIVE ?), their 
> handling
> will be still the same, though.

Thanks for the documentation pointers, very handy! Not sure which way
to go with regards to --shared vs --emit-relocs. I think my current
solution is good enough for now.

Have a nice weekend!

/ magnus
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot

Reply via email to