On Mon, Jun 26, 2006 at 03:20:53PM -0700, Ian Lance Taylor wrote: > Amit Gud <[EMAIL PROTECTED]> writes: > > > I'm compiling the GNU/Linux kernel as a shared library and I've found > > that relocation entries are created even for absolute symbols. Is > > there any work-around for this, or is it a known bug? > > That is correct behaviour if the symbol is globally visible. In a > shared library, by default, any symbol may be overridden by the main > executable. That means that a relocation entry is required. >
I am compiling my kernel with option --pic-executable to ld. As per ld man page, symbols defined in the executable can not be overriden. Still I see the relocation entries of type R_386_32 for absolute symbols. c0100018 00003e01 R_386_32 c0412000 __bss_start c010001d 00003601 R_386_32 c04d7768 __bss_stop c0100064 00004901 R_386_32 c04d8000 pg0 c0100848 00004501 R_386_32 c03dc040 jiffies If absolute symbols are not to be relocated then why is linker generating relocation entries. Then I used options "--pic-executable -Bsymbolic". In this case also linker generated relocation entries for absolute sysmbols. Only difference was that relocation type was R_386_RELATIVE and linker had already processed the relocations for absolute sysmbols. c0100018 00000008 R_386_RELATIVE Addr c0100018 belongs to absolute symbol referece (_bss_start) in code. In this case if absolute symbols relocation have already been processed and absolute symbols have no more to be relocated then why a R_386_RELATIVE entry is being generated. My basic goal is to build dynamically relocatable kernel. I thought that I can use the relocation information and relocate the kernel. But the relocation entries generated for absolute symbols as shown above spoil the whole approach. Is it a bug? or expected behaviour? Thanks Vivek _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
