[PATCH] kdump: relocatable kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, 07 Jul 2006 15:35:18 +0200, Vivek Goyal wrote:
...
> I think --emit-relocs is just emitting relocations which have already
> been processed. In your approach you are just taking a clue where all
> relocations have been applied in this executable file and try to 
> relocate. As I said previously, you are effectively chaning the type of
> relocation.

1. The type of relocation is NOT changed after --emit-relocs (and it would
   still be a bug in ld(1), not in mkdump).
   The output from --emit-relocs still contains the symbol names and contains
   still valid R_386_32 relocations (you can shift each section to a different
   address and still update all the relocations properly).  The linking process
   just adjusted the addends (A) to the new linked base address of the
   executable.

2. I was speaking for mkdump which does not fiddle with any ELF and
   --emit-relocs is only a building stage for it - so it is a bit irrelevant.
   mkdump-2.0+ uses its own trivia raw binary relocation tables as described in
   the second comment "Output file layout" of:
   	http://mkdump.cvs.sourceforge.net/mkdump/linux/scripts/reltab.c?view=markup&pathrev=linux-2_6-minik


> For example, If you encounter a relocation type R_386_32, ideally
> it should be (S+A). Where S is symbol value and A is addend. But you
> have replaced symbol value(S) with a offset (The difference between
> the address where executable has been loaded and the address for which
> it has been compiled). Effectively turning the relocation into
> R_386_RELATIVE. IMHO, this kind of looks hackish.

Please see the point (1) above.


> While going through ld man page, I hit upon another interesting option.
> "--pic-executable". This is supposed to generate position independent
> executable which needs to be relocated like shared libraries. How
> about this using this option? I am yet to play a little bit with this.

I cannot comment on it as I still have no clue of your goals. I still do not
understand why to have ELF (so different format than bzImage) mini-kernel.
After the primary kernel starts to be ELF (the same format), I will be glad to
continue this discussion.



Regards,
Lace


[Index of Archives]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Linux Media]

  Powered by Linux