search for: r_info

...4)&got[i]; + } + + return ret + rela->r_addend; +} + +#define cmp_3way(a,b) ((a) < (b) ? -1 : (a) > (b)) + +static int cmp_rela(const void *a, const void *b) +{ + const Elf64_Rela *x = a, *y = b; + int i; + + /* sort by type, symbol index and addend */ + i = cmp_3way(ELF64_R_TYPE(x->r_info), ELF64_R_TYPE(y->r_info)); + if (i == 0) + i = cmp_3way(ELF64_R_SYM(x->r_info), ELF64_R_SYM(y->r_info)); + if (i == 0) + i = cmp_3way(x->r_addend, y->r_addend); + return i; +} + +static bool duplicate_rel(const Elf64_Rela *rela, int num) +{ + /* + * Entries are sorted by type, sy...

...at it should be treated as an alternative generic format handled recognized and handled in the ELF class objects above the target specific level. Most architectures have the following 64 bit relocation record format: typedef struct { Elf64_Addr r_offset; /* Address of reference */ Elf64_Xword r_info; /* Symbol index and type of relocation */ } Elf64_Rel; typedef struct { Elf64_Addr r_offset; Elf64_Xword r_info; Elf64_Sxword r_addend; } Elf64_Rela; Whereas N64 has the following format: typedef struct { Elf64_Addr r_offset; /* Address of reference */ Elf64_Word r_sym; /* Symb...

This patch series adds support for network buffering in the Remus codebase in libxl. Changes in V3: [1/5] Fix redundant checks in configure scripts (based on Ian Campbell''s suggestions) [2/5] Introduce locking in the script, during IFB setup. Add xenstore paths used by netbuf scripts to xenstore-paths.markdown [3/5] Hotplug scripts setup/teardown invocations are now

Hi, I need an advice on implementation of a very specific kind of relocations used by MIPS N64 ABI. As usual the main problem is how to pass target specific data over Native/YAML conversion barrier. In this ABI relocation record r_info field in fact consists of five subfields: * r_sym - symbol index * r_ssym - special symbol * r_type3 - third relocation type * r_type2 - second relocation type * r_type - first relocation type Up to three these relocations applied one by one. The first relocation uses an addendum from the relo...

...gt;> Hi, >> >> I need an advice on implementation of a very specific kind of relocations >> used by MIPS N64 ABI. As usual the main problem is how to pass target >> specific >> data over Native/YAML conversion barrier. >> >> In this ABI relocation record r_info field in fact consists of five >> subfields: >> * r_sym - symbol index >> * r_ssym - special symbol >> * r_type3 - third relocation type >> * r_type2 - second relocation type >> * r_type - first relocation type >> >> Up to three these relocations...

...on Atanasyan wrote: > > > Hi, > > I need an advice on implementation of a very specific kind of relocations > used by MIPS N64 ABI. As usual the main problem is how to pass target > specific > data over Native/YAML conversion barrier. > > In this ABI relocation record r_info field in fact consists of five > subfields: > * r_sym - symbol index > * r_ssym - special symbol > * r_type3 - third relocation type > * r_type2 - second relocation type > * r_type - first relocation type > > Up to three these relocations applied one by one. The first re...

...implementation of a very specific kind of > relocations > >>> used by MIPS N64 ABI. As usual the main problem is how to pass target > >>> specific > >>> data over Native/YAML conversion barrier. > >>> > >>> In this ABI relocation record r_info field in fact consists of five > >>> subfields: > >>> * r_sym - symbol index > >>> * r_ssym - special symbol > >>> * r_type3 - third relocation type > >>> * r_type2 - second relocation type > >>> * r_type - first relocation...

...;>> >>> I need an advice on implementation of a very specific kind of relocations >>> used by MIPS N64 ABI. As usual the main problem is how to pass target specific >>> data over Native/YAML conversion barrier. >>> >>> In this ABI relocation record r_info field in fact consists of five subfields: >>> * r_sym - symbol index >>> * r_ssym - special symbol >>> * r_type3 - third relocation type >>> * r_type2 - second relocation type >>> * r_type - first relocation type >>> >>> Up to three...

...ocations > >> >>> used by MIPS N64 ABI. As usual the main problem is how to pass > target > >> >>> specific > >> >>> data over Native/YAML conversion barrier. > >> >>> > >> >>> In this ABI relocation record r_info field in fact consists of five > >> >>> subfields: > >> >>> * r_sym - symbol index > >> >>> * r_ssym - special symbol > >> >>> * r_type3 - third relocation type > >> >>> * r_type2 - second relocation type &...

...nd case but for other oob computed pointers too. e.g. > > static int a[8]; > static int *p = a - 5; > ... > p[10] = 1; > > should work (even if it's not valid in c it can be valid as > a c extension or written in asm, so ELF should support it). > > e.g. the r_info field in the RELATIVE reloc can index the > MTEGLOBTAB and use the object bounds from there for ldg > (and if r_info==0 means untagged this falls back to normal > RELATIVE reloc processing), but i don't yet know what is > the best solution here. > > i think tls needs some thou...

...t; >>> used by MIPS N64 ABI. As usual the main problem is how to pass >> target >> >> >>> specific >> >> >>> data over Native/YAML conversion barrier. >> >> >>> >> >> >>> In this ABI relocation record r_info field in fact consists of five >> >> >>> subfields: >> >> >>> * r_sym - symbol index >> >> >>> * r_ssym - special symbol >> >> >>> * r_type3 - third relocation type >> >> >>> * r_type2 - seco...

...9;t like about the format that was being used (I do for sure). It is entirely possible that if we get our thoughts together we can build a better format. Having said that, an object file format has a tremendous cost. Just look at the pain that is maintaining support for mips' interpretation of r_info. We have to be sure there is a genuine advantage to it before adding a new object format to the world. To know that I think we need to push the current formats to see how far they go. As an analogy, imagine if people working on BFD had decided that ELF linking was too slow or missing features and...

...ntation of a very specific kind of >> relocations >>>>> used by MIPS N64 ABI. As usual the main problem is how to pass target >> specific >>>>> data over Native/YAML conversion barrier. >>>>> >>>>> In this ABI relocation record r_info field in fact consists of five >> subfields: >>>>> * r_sym - symbol index >>>>> * r_ssym - special symbol >>>>> * r_type3 - third relocation type >>>>> * r_type2 - second relocation type >>>>> * r_type - first relo...

...t was being used (I do for sure). > It is entirely possible that if we get our thoughts together we can > build a better format. > > Having said that, an object file format has a tremendous cost. Just > look at the pain that is maintaining support for mips' interpretation > of r_info. We have to be sure there is a genuine advantage to it > before adding a new object format to the world. To know that I think > we need to push the current formats to see how far they go. > > As an analogy, imagine if people working on BFD had decided that ELF > linking was too slow...

Hi folks, ARM v8.5 introduces the Memory Tagging Extension (MTE), a hardware that allows for detection of memory safety bugs (buffer overflows, use-after-free, etc) with low overhead. So far, MTE support is implemented in the Scudo hardened allocator (compiler-rt/lib/scudo/standalone) for heap, and stack allocation is implemented in LLVM/Clang behind -fsanitize=memtag

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

On May 4, 2015, at 1:16 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > It has been said in this thread before, but I fail to see how the atom > model is an actual improvement over the fine grained section model. It > seems to be artifically restricted for no good reasons. Sections come with a huge amount of bloat and overhead that atoms do not. >> Lets stop