* relocation entries for absolute symbols
@ 2006-06-26 22:21 Amit Gud
2006-06-27 7:29 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Amit Gud @ 2006-06-26 22:21 UTC (permalink / raw)
To: binutils; +Cc: bug-binutils, Vivek Goyal
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?
AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relocation entries for absolute symbols
2006-06-26 22:21 relocation entries for absolute symbols Amit Gud
@ 2006-06-27 7:29 ` Ian Lance Taylor
2006-07-13 2:45 ` Vivek Goyal
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2006-06-27 7:29 UTC (permalink / raw)
To: Amit Gud; +Cc: binutils, bug-binutils, Vivek Goyal
Amit Gud <agud@redhat.com> 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.
One fix would be to force the symbol to be hidden using an attribute
or a linker script.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relocation entries for absolute symbols
2006-06-27 7:29 ` Ian Lance Taylor
@ 2006-07-13 2:45 ` Vivek Goyal
2006-07-13 8:45 ` Peter S. Mazinger
0 siblings, 1 reply; 6+ messages in thread
From: Vivek Goyal @ 2006-07-13 2:45 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Amit Gud, binutils, bug-binutils
On Mon, Jun 26, 2006 at 03:20:53PM -0700, Ian Lance Taylor wrote:
> Amit Gud <agud@redhat.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relocation entries for absolute symbols
2006-07-13 2:45 ` Vivek Goyal
@ 2006-07-13 8:45 ` Peter S. Mazinger
2006-07-13 13:34 ` Vivek Goyal
0 siblings, 1 reply; 6+ messages in thread
From: Peter S. Mazinger @ 2006-07-13 8:45 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Ian Lance Taylor, Amit Gud, binutils, bug-binutils
On Wed, 12 Jul 2006, Vivek Goyal wrote:
> On Mon, Jun 26, 2006 at 03:20:53PM -0700, Ian Lance Taylor wrote:
> > Amit Gud <agud@redhat.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relocation entries for absolute symbols
2006-07-13 8:45 ` Peter S. Mazinger
@ 2006-07-13 13:34 ` Vivek Goyal
2006-07-19 9:12 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: Vivek Goyal @ 2006-07-13 13:34 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: Ian Lance Taylor, Amit Gud, binutils, bug-binutils
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 <agud@redhat.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relocation entries for absolute symbols
2006-07-13 13:34 ` Vivek Goyal
@ 2006-07-19 9:12 ` Alan Modra
0 siblings, 0 replies; 6+ messages in thread
From: Alan Modra @ 2006-07-19 9:12 UTC (permalink / raw)
To: Vivek Goyal
Cc: Peter S. Mazinger, Ian Lance Taylor, Amit Gud, binutils, bug-binutils
On Thu, Jul 13, 2006 at 09:33:25AM -0400, Vivek Goyal wrote:
> 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.
Yes, this is a rather sorry result of historical mistakes. Symbols such
as _GLOBAL_OFFSET_TABLE_ are required to be absolute for compatibility
with old dynamic loaders, but of course they really are not absolute.
They point into the shared lib, so need to be relocated. This is why
we generate relocations on absolute symbols.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-07-19 9:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-26 22:21 relocation entries for absolute symbols Amit Gud
2006-06-27 7:29 ` Ian Lance Taylor
2006-07-13 2:45 ` Vivek Goyal
2006-07-13 8:45 ` Peter S. Mazinger
2006-07-13 13:34 ` Vivek Goyal
2006-07-19 9:12 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).