search for: dynstr

...to the design of yaml2obj. This proposal introduces three ways to input a value for a dynamic entry. For a given dynamic tag, one or more of these methods of setting a value may be permitted. All of these cases are illustrated later with an example. 1. For dynamic entry strings that belong in .dynstr, the string itself can be used as the value for an entry. (ex. DT_SONAME, DT_NEEDED, DT_RPATH, and DT_RUNPATH) 2. A section name can be used in place of an address. In this case, the value of the dynamic entry is the sh_addr of the specified section. (ex. DT_STRTAB, DT_SYMTAB, DT_HASH, DT_RELA, a...

...LIGN(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 = .; - __dynstr_lma = __dynstr_vma + __text_lma - __text_vma; - .dynstr : AT(__dynstr_lma) { + .dynstr : AT(ADDR(.dynstr) + __vma_to_lma) { __dynstr_start = .; *(.dynstr) __dynstr_end = .; } __dynstr_len = __dynstr_end - __dynstr_start; - . = ALIGN(4); - - __gnu_hash_vma = .; - _...

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

...LIGN(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(__dynstr_lma = __dynstr_vma + __text_lma - __text_vma); - .dynstr : AT(__dynstr_lma) { - HIDDEN(__dynstr_start = .); - *(.dynstr) - HIDDEN(__dynstr_end = .); - } - HIDDEN(__dynstr_len = __dynstr_end - __dynstr_start); - - . = ALIGN(4); - - HIDDEN(__gnu_hash_vma = .); - HIDDEN(...

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

...0 .strtab > 4.2% 57.4Mi 0.0% 0 .debug_line > 1.7% 23.3Mi 12.5% 23.3Mi .eh_frame > 1.7% 23.0Mi 12.4% 23.0Mi .rodata > 1.3% 17.9Mi 0.0% 0 .symtab > 1.0% 13.0Mi 0.0% 0 .debug_ranges > 0.8% 10.6Mi 5.7% 10.6Mi .dynstr > > c) > > FILE SIZE VM SIZE > -------------- -------------- > 35.1% 293Mi 0.0% 0 .debug_info > 21.2% 177Mi 0.0% 0 .debug_str > 13.9% 115Mi 62.2% 115Mi .text > 10.9% 90.7Mi 0.0% 0 .strtab > 6.9%...

...ulting 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] Error 2...

What are the current limitations of using -O4 in llvm-gcc-4.2? As a first test, I compiled the molscript program first as -O3 and it works fine. However if i try to compile the same code as -O4, the build fails with... ar -cru clib.a args.o str_utils.o dynstring.o err.o indent.o vector3.o matrix3.o quaternion.o body3d.o extent3d.o io_utils.o colour.o key_value.o named_data.o double_hash.o hermite_curve.o element_lookup.o aa_lookup.o mol3d.o mol3d_init.o mol3d_io.o mol3d_utils.o mol3d_chain.o mol3d_secstruc.o sgi_image.o vrml.o ogl_utils.o ogl_body.o ogl...

...mory models for this architecture */ - /* 2 MB -- the normal starting point for text is 4 MB */ - . = 0x00200400; - .interp : { *(.interp) } - .reginfo : { *(.reginfo) } - .dynamic : { *(.dynamic) } - .hash : { *(.hash) } - .dynsym : { *(.dynsym) } - .dynstr : { *(.dynstr) } - .gnu.version : { *(.gnu.version) } - .gnu.version_d : { *(.gnu.version_d) } - .gnu.version_r : { *(.gnu.version_r) } - .rel.dyn : - { - *(.rel.init) - *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) - *(.rel.fini) - *(.rel.rodata .rel...

...d libraries. */ + . = SEGMENT_START("text-segment", 0x2000000000000000) + SIZEOF_HEADERS; + .interp : { *(.interp) } + .note.gnu.build-id : { *(.note.gnu.build-id) } + .hash : { *(.hash) } + .gnu.hash : { *(.gnu.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + .rel.dyn : + { + *(.rel.init) + *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) + *(.rel.fini) + *(.rel.rodata .rel...

...d libraries. */ + . = SEGMENT_START("text-segment", 0x2000000000000000) + SIZEOF_HEADERS; + .interp : { *(.interp) } + .note.gnu.build-id : { *(.note.gnu.build-id) } + .hash : { *(.hash) } + .gnu.hash : { *(.gnu.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + .rel.dyn : + { + *(.rel.init) + *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) + *(.rel.fini) + *(.rel.rodata .rel...

...owarth wrote: > What are the current limitations of using -O4 in > llvm-gcc-4.2? As a first test, I compiled the molscript > program first as -O3 and it works fine. However if i > try to compile the same code as -O4, the build fails with... > > ar -cru clib.a args.o str_utils.o dynstring.o err.o indent.o > vector3.o matrix3.o quaternion.o body3d.o extent3d.o io_utils.o > colour.o key_value.o named_data.o double_hash.o hermite_curve.o > element_lookup.o aa_lookup.o mol3d.o mol3d_init.o mol3d_io.o > mol3d_utils.o mol3d_chain.o mol3d_secstruc.o sgi_image.o vrml....

...o be made larger. With > > option 1, we may still have some leeway in how to order sections within > the > > merged RELRO segment. > > For huge executables (>2G or 3G), it may cause relocation overflows > between .text and .rodata if other large sections like .dynsym and .dynstr > are > placed in between. > > I do not worry too much about overflows potentially caused by moving > PT_GNU_RELRO around. PT_GNU_RELRO is usually less than 10% of the size of > the > RX PT_LOAD. > That's good to know! > > > This would be a somewhat tedious ch...

Hi, I noticed that klibc started crashing on 64-bit MIPS and in my quest to fix the bug I got a bit carried away and fixed a few other things as well. Here are various miscellaneous MIPS patches, although the first patch is the important one. Thanks, James *** BLURB HERE *** James Cowgill (5): mips64: compile with -mno-abicalls mips: use -Ttext-segment when linking shared library

...mory models for this architecture */ + /* 2 MB -- the normal starting point for text is 4 MB */ + . = 0x00200400; + .interp : { *(.interp) } + .reginfo : { *(.reginfo) } + .dynamic : { *(.dynamic) } + .hash : { *(.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + .rel.dyn : + { + *(.rel.init) + *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) + *(.rel.fini) + *(.rel.rodata .rel...

On Thu, Aug 29, 2019 at 3:10 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Hello Vic, > > To make sure I understand the proposal correctly, do you propose: > > Old: R RX RW(RELRO) RW > New: R(R+RELRO) RX RW; R includes the traditional R part and the > RELRO part > Runtime (before relocation resolving): RW RX RW > Runtime (after relocation resolving): R RX

...om dynamic tag that will cause the dynamic loader to first load the main partition and then the loadable partition at the correct relative address. == In more detail == Each loadable partition will require its own sections to support the dynamic loader and unwinder (namely: .ARM.exidx, .dynamic, .dynstr, .dynsym, .eh_frame_hdr, .gnu.hash, .gnu.version, .gnu.version_r, .hash, .interp, .rela.dyn, .relr.dyn), but will be able to share a GOT and PLT with the main partition. This means that all addresses associated with symbols will continue to be fixed. In order to cause the dynamic loader to reserve...

...mory models for this architecture */ + /* 2 MB -- the normal starting point for text is 4 MB */ + . = 0x00200400; + .interp : { *(.interp) } + .reginfo : { *(.reginfo) } + .dynamic : { *(.dynamic) } + .hash : { *(.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + .rel.dyn : + { + *(.rel.init) + *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) + *(.rel.fini) + *(.rel.rodata .rel...

...first load the main partition and then the loadable partition at >> the correct relative address. >> >> == In more detail == >> >> Each loadable partition will require its own sections to support the >> dynamic loader and unwinder (namely: .ARM.exidx, .dynamic, .dynstr, >> .dynsym, .eh_frame_hdr, .gnu.hash, .gnu.version, .gnu.version_r, .hash, >> .interp, .rela.dyn, .relr.dyn), but will be able to share a GOT and PLT >> with the main partition. This means that all addresses associated with >> symbols will continue to be fixed. >> &gt...

...C LOAD > READONLY DATA HAS_CONTENTS > ??? 0x00000298->0x00000a0c at 0x00000298: .gnu.hash ALLOC LOAD READONLY > DATA HAS_CONTENTS > ??? 0x00000a10->0x00004988 at 0x00000a10: .dynsym ALLOC LOAD READONLY > DATA HAS_CONTENTS > ??? 0x00004988->0x00007edc at 0x00004988: .dynstr ALLOC LOAD READONLY > DATA HAS_CONTENTS > ??? 0x00007edc->0x00008426 at 0x00007edc: .gnu.version ALLOC LOAD > READONLY DATA HAS_CONTENTS > ??? 0x00008428->0x00008478 at 0x00008428: .gnu.version_r ALLOC LOAD > READONLY DATA HAS_CONTENTS > ??? 0x00008478->0x00009cc0 a...