bug-binutils
[Top][All Lists]
Advanced

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

Re: relocation entries for absolute symbols


From: Vivek Goyal
Subject: Re: relocation entries for absolute symbols
Date: Thu, 13 Jul 2006 09:33:25 -0400
User-agent: Mutt/1.5.11

On Thu, Jul 13, 2006 at 10:45:34AM +0200, Peter S. Mazinger wrote:
> On Wed, 12 Jul 2006, Vivek Goyal wrote:
> 
> > On Mon, Jun 26, 2006 at 03:20:53PM -0700, Ian Lance Taylor wrote:
> > > Amit Gud <address@hidden> 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. 
> 
> Wouldn't you also need -fPIE|-fpie in CFLAGS (that breaks the build 
> though)
> 

I do not want to generate position independent code and I am ok with text
relocations as unlike normal shared libraries, text segment of kernel
is not supposed to be shared. Hence not specifying -fPIE in CFLAGS.

I just want to generate relocation entries of type R_386_RELATIVE in fully
linked kernel so that at load time I can relocate it by some offset say X.

Currently kernel compiles and loads at physical address 1MB (i386, x86_64).
At load time I want to load it at a different physical address say 16MB.
While loading I shall process all the relocations (Ideally which should just
be of type R_386_RELATIVE, as there are no external symbol references and
I am not generating a position independent code).

Everything else seems to be ok if I link with option "-pie -Bsymbolic"
except the fact that relocations of type R_386_RELATIVE are being 
generated for absolute symbols.  

Thanks
Vivek

> Peter
> > 
> > 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 
> > 
> 
> -- 
> Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
> Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




reply via email to

[Prev in Thread] Current Thread [Next in Thread]