search for: sto_micromips

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,...

...turns out in practice the scan is rarely done because the result can be cached by whatever algorithm needs that info. -Nick On Nov 11, 2014, at 6:50 AM, Simon Atanasyan <simon at atanasyan.com> wrote: > I was too optimistic. It is possible to use the contentTypes field 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 > ...). Sometim...

...arely done because the result can be cached by whatever algorithm needs that info. > > -Nick > > > On Nov 11, 2014, at 6:50 AM, Simon Atanasyan <simon at atanasyan.com> wrote: > > I was too optimistic. It is possible to use the contentTypes field 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_M...

Hi, On MIPS st_other field in the ELF symbols table might contain some additional MIPS-specific flags besides visibility ones. These flags should be copied to the output linked file. If YAML => Native conversion is switched off, there is no problem. But in case of the conversion we lose st_other field values. So I need an advice how to keep this information. Is it a good idea to extend YAML