search for: _global_offset_table_

When LLD builds a shared library for x86_64 it puts _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it as a GLOBAL symbol. If later this shared library participates in executable file linking and GNU BFD linked is used for that, this linker shows an error: /usr/bin/ld: a.out: hidden symbol `_GLOBAL_OFFSET_TABLE_' in /usr/lib/x86_64-linux-gnu/crt1.o...

...here, the reverse is true for both the GNU binutils and XPG4 versions of `nm' : -bash-3.2$ /usr/xpg4/bin/nm -p -u `find . -name libLLVMCore.a` | head ./Debug/lib/libLLVMCore.a[AsmWriter.o]: 0000000000 U __assert 0000000000 U __clzdi2 0000000000 U __udivdi3 0000000000 U __umoddi3 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 U _ZdaPv 0000000000 U _ZdlPv -bash-3.2$ /usr/bin/nm -p -u `find . -name libLLVMCore.a` | head ./Debug/lib/libLLVMCore.a[AsmWriter.o]: __assert __clzdi2 __udivdi3 __umoddi3 _GLOBAL_OFFSET_TABLE_ _ZdaPv _ZdlPv -bash-3.2$ /usr/bin/nm -p -g `find . -name libLL...

...using -g would seem redundant, The error message was as follows: "/usr/xpg4/bin/nm: -e or -g set, -u ignored". Actually it was the -u that's redundant - the -g was necessary for GenLibDeps.pl: $ nm -p -u libLLVMCore.a libLLVMCore.a[AsmWriter.o]: __asert atof _GLOBAL_OFFSET_TABLE_ isalnum ... etc ... $ nm -p -g libLLVMCore.a libLLVMCore.a[AsmWriter.o]: 0000000000 U __assert 0000000000 U atof 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 U isalnum The latter being what GenLibDeps.pl expects to see. All else being equal though, it might be better to change GenLib...

...2.o)' is incompatible with sparc:v9 output ld: sparc architecture of input file `/usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clz.o)' is incompatible with sparc:v9 output /usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clzdi2.o): In function `__clzdi2': (.text+0xc): undefined reference to `_GLOBAL_OFFSET_TABLE_' /usr/lib/gcc/sparc-linux-gnu/4.2.1/libgcc.a(_clzdi2.o): In function `__clzdi2': (.text+0x14): undefined reference to `_GLOBAL_OFFSET_TABLE_' make[3]: *** [usr/klibc/libc.so] Error 1 make[2]: *** [all] Error 2 make[1]: *** [klibc] Error 2 make[1]: Leaving directory `/build/klibc-1.5.6...

...ld: i386 architecture of input file `onexit.o' is incompatible with i386:x86-64 output ld: i386 architecture of input file `abort.o' is incompatible with i386:x86-64 output zlib/compress.o: In function `compress2': /tmp/syslinux-6.00/com32/lib/zlib/compress.c:28: undefined reference to `_GLOBAL_OFFSET_TABLE_' zlib/compress.o: In function `compress': /tmp/syslinux-6.00/com32/lib/zlib/compress.c:67: undefined reference to `_GLOBAL_OFFSET_TABLE_' zlib/crc32.o: In function `make_crc_table': /tmp/syslinux-6.00/com32/lib/zlib/crc32.c:109: undefined reference to `_GLOBAL_OFFSET_TABLE_' zli...

On Tue, 25 Jun, at 01:52:00PM, Helmut Hullen wrote: > Thanks - now it crashes later ... What crash are you seeing? > I don't have the ia64 files which are needed for a complete binary. But > maybe that's only my special problem. You shouldn't need ia64 files to build ia32 and x86-64 versions of gnu-efi or Syslinux. -- Matt Fleming, Intel Open Source Technology Center

...-Y [path] Used by the 32-bit compat libraries. GNU ld documents this as "add path to the default library search path." I don't understand exactly what this option does, versus -L. 4. unrecognized reloc 22 (R_X86_64_GOTTPOFF) Encountered in one of the libc tests. 5. --no-undefined vs _GLOBAL_OFFSET_TABLE_ A number of libraries are linked with --no-undefined. These fail wtih an error of the form: undefined symbol: _GLOBAL_OFFSET_TABLE_ in /<path>tmp/usr/lib/crtbeginS.o 6. emulation type "elf_i386_fbsd" This is used by the 32-bit library build, which fails with "Unknown emulation...

Peter, There was a mis-merge in the ia64 patch you put into 0.83. Olaf Hering pointed it out. The patch is attached. Olaf claims that he is still unable to compile for ia64 with is toolchain. He's getting the following error: <olh> libc.so(.got+0x0): multiple definition of `_GLOBAL_OFFSET_TABLE_' <olh> tests/getenvtest.o(.got.plt+0x0): first defined here <olh> make[2]: *** [tests/getenvtest.shared] Error 1 mh -- Martin Hicks Wild Open Source Inc. mort@wildopensource.com 613-266-2296 diff -uNr klibc-0.83.vanilla/klibc/arch/ia64/Makefile.inc klibc-0.83...

Hi, I would like to use a MCFixup to encode the distance in number of bytes from an instruction to the end of the .text section. Is there an existing MCFixup type I can use for this? If not, does anyone have any suggestions for how to add a new MCFixup type that will do this? Thanks, Tom

...asonably far with this but when doing the linking using the line: i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR I get lots of these type of messages: /my/path/to/mylibrary.cpp:43: undefined reference to `_GLOBAL_OFFSET_TABLE_' and other similar linker errors for virtually every object and command in the program. After some googling I have found that there may be problems with the libgcc.a library and its default -fPIC argument during compilation. Has anyone got this tutorial to work and if so how did they o...

...l %ecx, (%rax) popq %rbp retq Where are the GOT accesses? Where is the computation of the GOT address? Since it is more than 2GB away from the code, the ABI says to generate: // ABI document suggests: // // pushq %r15 // leaq 1f(%rip),%r11 // 1: // movabs $_GLOBAL_OFFSET_TABLE_,%r15 // leaq (%r11,%r15),%r15 // // gcc generates: // // .L2: // leaq .L2(%rip), %rax // movabsq $_GLOBAL_OFFSET_TABLE_-.L2, %r11 // addq %r11, %rax //

...xternal_function>" like: bl printf Because the ELF file in memory generated by MC JIT does not have the .plt section, but we need to have the following code to be emitted in it: .plt:00008290 STR LR, [SP,#-4]! .plt:00008294 LDR LR, =_GLOBAL_OFFSET_TABLE_ ; PIC mode .plt:00008298 NOP .plt:0000829C LDR PC, [LR,#8]! Also GOT section doesn't exists. To fix this we need to generate the valid entries in GOT and PLT sections We propose adding these sections and generating a thunk, same as in the usual com...

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather

+ Nick On 2/19/2015 9:00 AM, Shankar Easwaran wrote: > On 2/19/2015 3:58 AM, Denis Protivensky wrote: >> Joerg: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> Do you want to do that before or

...of specific symbols at that time. > > - Denis. None of the symbols we are looking up require the full resolver, and they are all special linker symbols. I propose two things. 1. Provide a hook as per what Shankar suggested for the resolver. User references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get created and possibly deadstripped here. The linking context owns the atom. 2. The ELFLinkingContext gains <Atom *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes to get the symbols. The hook in (1) would call this to create the atoms. This gives a single place where...

...-83,12 +83,20 @@ 0: \ add dest,%o7,dest; \ mov tmp, %o7 +#define SET(var,base,dest) \ + sethi %gdop_hix22(var), dest; \ + xor dest, %gdop_lox10(var), dest; \ + ldx [base + dest], dest, %gdop(var) #else #define PIC_PROLOGUE(dest,tmp) \ mov %o7,tmp; 3: call 4f; nop; 4: \ sethi %hi(_C_LABEL(_GLOBAL_OFFSET_TABLE_)-(3b-.)),dest; \ or dest,%lo(_C_LABEL(_GLOBAL_OFFSET_TABLE_)-(3b-.)),dest; \ add dest,%o7,dest; mov tmp,%o7 +#define SET(var,base,dest) \ + sethi %gdop_hix22(var), dest; \ + xor dest, %gdop_lox10(var), dest; \ + ld [base + dest], dest, %gdop(var) #endif /* @@ -106,7 +114,10 @@ #endif #els...

...-83,12 +83,20 @@ 0: \ add dest,%o7,dest; \ mov tmp, %o7 +#define SET(var,base,dest) \ + sethi %gdop_hix22(var), dest; \ + xor dest, %gdop_lox10(var), dest; \ + ldx [base + dest], dest, %gdop(var) #else #define PIC_PROLOGUE(dest,tmp) \ mov %o7,tmp; 3: call 4f; nop; 4: \ sethi %hi(_C_LABEL(_GLOBAL_OFFSET_TABLE_)-(3b-.)),dest; \ or dest,%lo(_C_LABEL(_GLOBAL_OFFSET_TABLE_)-(3b-.)),dest; \ add dest,%o7,dest; mov tmp,%o7 +#define SET(var,base,dest) \ + sethi %gdop_hix22(var), dest; \ + xor dest, %gdop_lox10(var), dest; \ + ld [base + dest], dest, %gdop(var) #endif /* @@ -106,7 +114,10 @@ #endif #els...

..._gcc-4.6-linaro_uClibc-0.9.33.2/usr/lib -L/mnt/data/Develop/Openwrt/trunk_git/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib ../../src/lib-dovecot/.libs/libdovecot.so -ldl -Wl,-rpath -Wl,/usr/lib/dovecot ../../src/lib-dovecot/.libs/libdovecot.so:(.got+0x0): multiple definition of `_GLOBAL_OFFSET_TABLE_' collect2: ld returned 1 exit status make[6]: *** [gdbhelper] Error 1 make[6]: Leaving directory `/mnt/data/Develop/Openwrt/trunk_git/build_dir/target-mips_r2_uClibc-0.9.33.2/dovecot-2.2.0/src/util' Making all in doveadm make[6]: Entering directory `/mnt/data/Develop/Openwrt/trunk_git/build...

...gt;sh_type = SHT_NOBITS; + mod->arch.core.got->sh_flags = SHF_ALLOC; + mod->arch.core.got->sh_addralign = L1_CACHE_BYTES; + mod->arch.core.got->sh_size = (gots + 1) * sizeof(u64); + mod->arch.core.got_num_entries = 0; + mod->arch.core.got_max_entries = gots; + + /* + * If a _GLOBAL_OFFSET_TABLE_ symbol exists, make it absolute for + * modules to correctly reference it. Similar to s390 implementation. + */ + strings = (void *) ehdr + sechdrs[symtab->sh_link].sh_offset; + for (i = 0; i < symtab->sh_size/sizeof(Elf_Sym); i++) { + if (syms[i].st_shndx != SHN_UNDEF) + continue; +...

...gt;> >> - Denis. > > None of the symbols we are looking up require the full resolver, and > they are all special linker symbols. I propose two things. > > 1. Provide a hook as per what Shankar suggested for the resolver. User > references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get > created and possibly deadstripped here. The linking context owns the > atom. > 2. The ELFLinkingContext gains <Atom > *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes > to get the symbols. The hook in (1) would call this to create the > atoms. &gt...