search for: sto_mips_mips16

Displaying 5 results from an estimated 5 matches for "sto_mips_mips16".

2014 Nov 11
6
[LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file
...ld for > handling STO_MICROMIPS and I have a working solution but the solution > is really ugly. This approach has at least two the following > shortcomings: > > 1. A MIPS ELF symbol can hold multiple STO_xxx flags stored in the > st_other field (STO_MIPS_PIC, STO_MIPS_MICROMIPS, STO_MIPS_MIPS16 > ...). Sometimes these flags can be even combined. If we use the > contentTypes field, we have to define a separate ContentType flag for > each such combination. So we get a combinatorics explosion. > > 2. If we handle MIPS specific ContentType flags together with other > flags,...
2014 Nov 06
2
[LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file
STO_MIPS16 and STO_MICROMIPS flags denote that the symbol use a different "compressed" instructions encoding. Both these flags can be combined with usual "visibility" flags. It looks like adding new flag into the contentTypes set might solve the problem. Thanks for the idea. I try to implement it. On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran <shankare at
2014 Nov 11
6
[LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file
..._MICROMIPS and I have a working solution but the solution > > is really ugly. This approach has at least two the following > > shortcomings: > > > > 1. A MIPS ELF symbol can hold multiple STO_xxx flags stored in the > > st_other field (STO_MIPS_PIC, STO_MIPS_MICROMIPS, STO_MIPS_MIPS16 > > ...). Sometimes these flags can be even combined. If we use the > > contentTypes field, we have to define a separate ContentType flag for > > each such combination. So we get a combinatorics explosion. > > > > 2. If we handle MIPS specific ContentType flags togethe...
2018 May 23
0
Proposal for address-significance tables for --icf=safe
On Tue, May 22, 2018 at 6:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF > only to sections which can be safely merged according to the guarantees > provided by the language. It works using a set of heuristics (symbol name > matching and relocation scanning).
2018 May 22
7
Proposal for address-significance tables for --icf=safe
Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan