search for: dynsym

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 is referenced by DSO Gold link...

...ctors)) __ctors_end = .; } - __dtors_vma = .; - __dtors_lma = __dtors_vma + __text_lma - __text_vma; - .dtors : AT(__dtors_lma) { + .dtors : AT(ADDR(.dtors) + __vma_to_lma) { __dtors_start = .; KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) __dtors_end = .; } - . = ALIGN(4); - - __dynsym_vma = .; - __dynsym_lma = __dynsym_vma + __text_lma - __text_vma; - .dynsym : AT(__dynsym_lma) { + .dynsym : AT(ADDR(.dynsym) + __vma_to_lma) { __dynsym_start = .; *(.dynsym) __dynsym_end = .; } __dynsym_len = __dynsym_end - __dynsym_start; - . = ALIGN(4); - - __dynstr_vma = .; - __d...

From: Sylvain Gault <sylvain.gault at gmail.com> TL;DR: The section aligment in linker scripts messed-up the memory mapping needed for the compression / decompression to work. The bug with gcc 5 is not trivial, I'll do my best to explain it here. Basically, there are two memory mappings of the code. One in "virtual memory", and one in "load memory". The one in

...supported by `StringRef::to_integer()`). (ex. DT_STRSZ, DT_SYMENT, DT_RELAENT, and others) Here's an example to illustrate this design: !ELF FileHeader: Class: ELFCLASS64 Data: ELFDATA2LSB Type: ET_DYN Machine: EM_X86_64 Sections: - Name: .dynsym Type: SHT_DYNSYM Address: 0x1000 - Name: .data Type: SHT_PROGBITS Flags: [ SHF_ALLOC, SHF_WRITE ] - Name: .dynamic Type: SHT_DYNAMIC Entries: - Tag: DT_SONAME Value: libsomething.so - Tag: DT_SYMTAB Value: .dynsym - Tag: DT_SYMENT...

...const unsigned long *reloc_start, const unsigned long *reloc_end) +{ +#if 1 + const unsigned long *reloc; + + for (reloc = reloc_start; reloc < reloc_end; ++reloc) { + unsigned long *ptr = (void *)((unsigned long)ehdr + *reloc); + + *ptr += new_base - old_base; + } +#else + unsigned i, ndynsym = 0, szdynsym = 0; + unsigned long dynsym = 0; + + BUG_ON(ehdr->e_ident[EI_MAG0] != ELFMAG0); + BUG_ON(ehdr->e_ident[EI_MAG1] != ELFMAG1); + BUG_ON(ehdr->e_ident[EI_MAG2] != ELFMAG2); + BUG_ON(ehdr->e_ident[EI_MAG3] != ELFMAG3); + BUG_ON(ehdr->e_ident[EI_CLASS] != ELFCLASS32); + BUG_...

...const unsigned long *reloc_start, const unsigned long *reloc_end) +{ +#if 1 + const unsigned long *reloc; + + for (reloc = reloc_start; reloc < reloc_end; ++reloc) { + unsigned long *ptr = (void *)((unsigned long)ehdr + *reloc); + + *ptr += new_base - old_base; + } +#else + unsigned i, ndynsym = 0, szdynsym = 0; + unsigned long dynsym = 0; + + BUG_ON(ehdr->e_ident[EI_MAG0] != ELFMAG0); + BUG_ON(ehdr->e_ident[EI_MAG1] != ELFMAG1); + BUG_ON(ehdr->e_ident[EI_MAG2] != ELFMAG2); + BUG_ON(ehdr->e_ident[EI_MAG3] != ELFMAG3); + BUG_ON(ehdr->e_ident[EI_CLASS] != ELFCLASS32); + BUG_...

...const unsigned long *reloc_start, const unsigned long *reloc_end) +{ +#if 1 + const unsigned long *reloc; + + for (reloc = reloc_start; reloc < reloc_end; ++reloc) { + unsigned long *ptr = (void *)((unsigned long)ehdr + *reloc); + + *ptr += new_base - old_base; + } +#else + unsigned i, ndynsym = 0, szdynsym = 0; + unsigned long dynsym = 0; + + BUG_ON(ehdr->e_ident[EI_MAG0] != ELFMAG0); + BUG_ON(ehdr->e_ident[EI_MAG1] != ELFMAG1); + BUG_ON(ehdr->e_ident[EI_MAG2] != ELFMAG2); + BUG_ON(ehdr->e_ident[EI_MAG3] != ELFMAG3); + BUG_ON(ehdr->e_ident[EI_CLASS] != ELFCLASS32); + BUG_...

...arked up with a string naming the partition, either at the source level with an attribute on the function or global variable, or by passing a flag to the compiler (this string becomes the partition's soname). These symbols will act as the GC roots for the partition and will be exported from its dynsym. Assuming that there is a single partition, let's call this set of symbols S2, while all other GC roots (e.g. non-marked-up exported symbols, sections in .init_array) we call S1. Any sections reachable from S1 are allocated to the main partition, while sections reachable only from S2 but not fr...

...rtition, >> either at the source level with an attribute on the function or global >> variable, or by passing a flag to the compiler (this string becomes the >> partition's soname). These symbols will act as the GC roots for the >> partition and will be exported from its dynsym. Assuming that there is a >> single partition, let's call this set of symbols S2, while all other GC >> roots (e.g. non-marked-up exported symbols, sections in .init_array) we >> call S1. Any sections reachable from S1 are allocated to the main >> partition, while sectio...

...DDEN(__ctors_end = .); - } - - HIDDEN(__dtors_vma = .); - HIDDEN(__dtors_lma = __dtors_vma + __text_lma - __text_vma); - .dtors : AT(__dtors_lma) { - HIDDEN(__dtors_start = .); - KEEP (*(SORT(.fini_array*))) - KEEP (*(SORT(.dtors*))) - HIDDEN(__dtors_end = .); - } - - . = ALIGN(4); - - HIDDEN(__dynsym_vma = .); - HIDDEN(__dynsym_lma = __dynsym_vma + __text_lma - __text_vma); - .dynsym : AT(__dynsym_lma) { - HIDDEN(__dynsym_start = .); - *(.dynsym) - HIDDEN(__dynsym_end = .); - } - HIDDEN(__dynsym_len = __dynsym_end - __dynsym_start); - - . = ALIGN(4); - - HIDDEN(__dynstr_vma = .); - HIDDEN(__...

On Sun, 30 Apr 2006, Aristid Breitkreuz wrote: > I am, as said in the subject, new to this list. I have not actually used > LLVM, I tried with an older version but failed. Recently I noticed that > 1.7 came out and looked at the release notes. And there was something > that stroke me: llvm-g++ adheres to the IA64 ABI but _not for > exceptions_. I was not able to find information why

...do they exist? Would --- a/mk/efi.mk +++ b/mk/efi.mk @@ -58,10 +58,6 @@ $(LIBEFI): %.o: %.S $(LIBEFI) $(CC) $(SFLAGS) -c -o $@ $< -.PRECIOUS: %.o -%.o: %.c $(LIBEFI) - $(CC) $(CFLAGS) -c -o $@ $< - #%.efi: %.so # $(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel \ # -j .rela -j .reloc --target=$(FORMAT) $*.so $@ make sense? Groeten Geert Stappers -- Leven en laten leven

Hello, I am, as said in the subject, new to this list. I have not actually used LLVM, I tried with an older version but failed. Recently I noticed that 1.7 came out and looked at the release notes. And there was something that stroke me: llvm-g++ adheres to the IA64 ABI but _not for exceptions_. I was not able to find information why this is so and why it is necessary, so I hope you don't

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

...ows me to gather all the LLVM "-stats" output. On top of this I see that the LNT cmake test-suite also dumps code-size statistics when running, that look as follows: size: 10848 size..bss: 48 size..comment: 218 size..ctors: 16 size..data: 4 size..dtors: 16 size..dynamic: 416 size..dynsym: 168 size..eh_frame: 172 size..eh_frame_hdr: 44 I can find all these statistics in a file called: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/outputTd2xPU.json but they do not appear in: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/report.json and in fact do...

...in; defaulting to 0000000040001000 hppa64-linux-gnu-ld: usr/klibc/libc.so: Not enough room for program headers (allocated 5, need 6) Section to Segment mapping: Segment Sections... 00: PHDR: 01: INTERP: .interp 02: LOAD: .interp .dynamic .hash .dynsym .dynstr 03: LOAD: .text .rodata .PARISC.unwind .eh_frame 04: LOAD: .data.rel.ro .data .opd .dlt .bss 05: DYNAMIC: .dynamic hppa64-linux-gnu-ld: final link failed: Bad value make[2]: *** [usr/klibc/libc.so] Error 1 make[1]: *** [all] Error 2 make: *** [klibc]...

Hello, all experts. When I use pid provider, my Dscript with -F option output the codepath with flowindent as you know, e.g. -> main -> f1 -> f2 however I realized that the exec file I used at that time was stripped. Does anyone know the reason why I could see the function names? Thanks in advance. -- This message posted from opensolaris.org

...ng naming the partition, > either at the source level with an attribute on the function or global > variable, or by passing a flag to the compiler (this string becomes the > partition's soname). These symbols will act as the GC roots for the > partition and will be exported from its dynsym. Assuming that there is a > single partition, let's call this set of symbols S2, while all other GC > roots (e.g. non-marked-up exported symbols, sections in .init_array) we > call S1. Any sections reachable from S1 are allocated to the main > partition, while sections reachable onl...

...============= : >LDFLAGS="-Bshareable -T ./linker_script" >clang -fPIC -c test.c >ld.lld $LDFLAGS test.o -o test.so >objdump -tT test.so Making __start_* __stop_* STV_PROTECTED is a deliberate choice. See https://reviews.llvm.org/D44566 Such symbols can still be exported to .dynsym (can be looked up from another shared object with dlopen) but prevent accidental symbol preemption.. > >On 6/2/20, 12:00 AM, "llvm-dev on behalf of Moshtaghi, Alireza via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: > >...

...ich allows me to gather all the LLVM "-stats" output. On top of this I see that the LNT cmake test-suite also dumps code-size statistics when running, that look as follows: size: 10848 size..bss: 48 size..comment: 218 size..ctors: 16 size..data: 4 size..dtors: 16 size..dynamic: 416 size..dynsym: 168 size..eh_frame: 172 size..eh_frame_hdr: 44 I can find all these statistics in a file called: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/outputTd2xPU.json but they do not appear in: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/report.json and in fact do no...