[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: relocation entries for absolute symbols
From: |
Peter S. Mazinger |
Subject: |
Re: relocation entries for absolute symbols |
Date: |
Thu, 13 Jul 2006 10:45:34 +0200 (CEST) |
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)
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