* 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).